From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Qi7vEz70V2nNyyUAWB0awg (envelope-from ) for ; Fri, 02 Jan 2026 11:37:18 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=W1YMBWNo; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 441961E0B6; Fri, 02 Jan 2026 11:37:18 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 7388D1E08D for ; Fri, 02 Jan 2026 11:37:17 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 012664BA2E05 for ; Fri, 2 Jan 2026 16:37:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 012664BA2E05 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=W1YMBWNo Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 45F304BA2E06 for ; Fri, 2 Jan 2026 16:36:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 45F304BA2E06 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 45F304BA2E06 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767371809; cv=none; b=iijukJBsd9QUawmTU0I1MBC5/NME3+X6MkjvMZE4w7L60GMosHeR+OErp1vZ9R7wqIwdaiwe9ro/f4QukVFiEWFGo42aysMnPz1Kw9rfl15DADsPMss1OI9iNzwQ88BzGfu8/HTDrOhBN1jxpdMm/5AQSWfHnqW8Xb/oaGuocg4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767371809; c=relaxed/simple; bh=lksPHxWqkVOjkUrSOsytsfZBBwcqo1dNPI64bdFUgRs=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=hEBDZkIP7kynZbRN/0oE7aqB9C4Fn8boOkROEMGbkojz6o7Ch/UQdbBRLiHRkB6/9jx2F7IygbwFv8I1GE5YdUI6e/knycldN89ryZV45g5nqtKZROp99wemetOpdWErMpULgO90Ei64xtC4T+vjQJ5E1Bc0nvyHRR+1RRn8EG0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 45F304BA2E06 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767371808; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fMKanBy/t+mlMfinWlHxwUtL7fzaiN1s3WTIV28hlEg=; b=W1YMBWNoi0mZJmoT5E6kmOv0KD35BZPAlnx4Wd/6D3yLb46b583kReaLWp4+xov0Wrrjfx fOC7f2dNie0EnibRyJSY9MalsF3ewInfd/ZLEfDSUAhT5rJ2qezB+nwmvjXISV2DmquqgR 8zTDIqPRbXOBQnXqmd+IWNoJ0+cIeu8= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-107--joAlNbcOUaBkQieq-HUvw-1; Fri, 02 Jan 2026 11:36:47 -0500 X-MC-Unique: -joAlNbcOUaBkQieq-HUvw-1 X-Mimecast-MFC-AGG-ID: -joAlNbcOUaBkQieq-HUvw_1767371806 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-4325b81081aso6777386f8f.3 for ; Fri, 02 Jan 2026 08:36:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767371806; x=1767976606; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fMKanBy/t+mlMfinWlHxwUtL7fzaiN1s3WTIV28hlEg=; b=d90JvwfYL/zwdoqxtN6ZqTXdp/8fMy8VnQeNHluBm2uSwsBaTjwxMVKyODVe7dFDWV i+6N95mcesIcbtiYHRjDBWaCT/RhEto3f4rqErj0k9l2b+XLVfdAUsv666nvYSCypbqe XCGpgDko5wzmD/oWsmqgCM29l/N1wnuqI82V9CcGWx9dDnNW1K83ZyittdeNrrruqLo5 pcEPAJuVOjLIYQClDi1t4cv57OFESHaOpyn0lDF+wJHwTlIjnchHlGUg+1kAvtAiMp3K 7dH4kqnprn8DveXMSN9Ftbhrx+qh/7mpLo39LV+hK2UO+JVHTiMLR+G1O+hgoVgtWc6A shqw== X-Gm-Message-State: AOJu0YyrDqjEAU74q/E++i1bbNjsdH7+HcKsc7Tjaz8nisXvfiEA+sOQ M+vKsw6Z+81APl0Kw1A88q2WZQZcB6FZr6XeXkZsAezsSvG3JzIlkiGaJHDYRAaZ5srMYEHbIz4 ksVysN3XtXpaU5bSRzpAHJo1t0fAc4xgHsbrbnMhZnDzrkvIaOJMbBSLf+cwIcZQQ6nYbuAo= X-Gm-Gg: AY/fxX7l3xO0+fiURiitV9liGYlL6Qg2V4QQ0jjXvtkeBtj0/DU3pMSCzNrKMQsgAor D1jftnwqx5a82nE3HV0+gsbt9R40KBmn7E/a8r0mYwh147wP50wdzV3PtYL/uWYDwRoiOkVcxLF CFI6W/3IeXc3B6Cz1kZ0d5oFFxdBwS2qJmdtLWowf+ZYTefb769tbO9XYKh2X0r8OGhS8Ok+kcO 2+FtyCOc3JjvB4tigs4wjs6D2Kz/amPAxL/NByJqmztobUgatXKh/jz0CHkrCxD14HWpGaWyTzV r6CXBXgO5ZIoLX1uQ46mwnWs5Itnz+MY4KhGww75SH7Ko/EjJ/rZ/lle0beb023rJYg7ee49fKi VtWAa X-Received: by 2002:a05:6000:1844:b0:430:fa58:a03d with SMTP id ffacd0b85a97d-4324e70ef05mr47741222f8f.63.1767371805937; Fri, 02 Jan 2026 08:36:45 -0800 (PST) X-Google-Smtp-Source: AGHT+IF96LciIBhKzsq6TxbFSOFqHN7yubPaqJRy9GzWamtQQ2P6O60yYSRoUsZf9RHOwwLNoRv2cg== X-Received: by 2002:a05:6000:1844:b0:430:fa58:a03d with SMTP id ffacd0b85a97d-4324e70ef05mr47741200f8f.63.1767371805368; Fri, 02 Jan 2026 08:36:45 -0800 (PST) Received: from localhost ([31.111.84.207]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4324ea1b36fsm84966203f8f.5.2026.01.02.08.36.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Jan 2026 08:36:44 -0800 (PST) From: Andrew Burgess To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCHv3 5/7] gdb: create address map after parsing all DIE In-Reply-To: <87ikg09cnl.fsf@tromey.com> References: <87ikg09cnl.fsf@tromey.com> Date: Fri, 02 Jan 2026 16:36:43 +0000 Message-ID: <87o6ncyns4.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: n-oON8hrBKJ5H6t-HvL3BDTQp9LD47_oaAypyWjBEh8_1767371806 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hi Tom, Thanks for taking a look at these patches. I wanted to follow up on some of your thoughts... Tom Tromey writes: >>>>>> "Andrew" == Andrew Burgess writes: > > Andrew> Continuing the work done in the last two commits, this commit defers > Andrew> building the addrmap for a blockvector until after all the DIE have > Andrew> been read, and the line table processed. > > Andrew> The benefit of this is that any changes to a block's ranges done > Andrew> during line table processing (see the next commit) will be reflected > Andrew> in the blockvector's addrmap. > > Andrew> The alternative to this is to build the addrmap as we initially see > Andrew> each block, but then adjust the addrmap if we later decide to modify a > Andrew> block. I think defering the addrmap creation is cleaner, and is less > Andrew> work overall. > > Andrew> The addrmap requires that we add the most inner blocks first. I > Andrew> achieve this by walking the blockvector backward, as we always add > Andrew> parent blocks before their more inner child blocks. > > I wonder if this is guaranteed to be correct. Like, does gdb cope > properly if a compiler happens to emit multiple lexical scopes that each > have non-contiguous ranges, and then where the ranges happen to overlap. I had a play with some examples using DW_TAG_lexical_block to see how things change. If things are laid out in what I'd consider a "sane" way, with nested blocks being nested within the DWARF, then you'll end up with the same block structure before and after this patch, e.g.: DW_TAG_lexical_block { ... } { DW_TAG_variable { DW_AT_name "var_a" ... } DW_TAG_lexical_block { ... } { DW_TAG_variable { DW_AT_name "var_b" ... } } } In this example the block containing 'var_a' is added to the blockvector before the block holding 'var_b', so when we walk the blockvector backwards, we see the 'var_b' block first, and everything is fine. If we change the test to be structured like this instead: DW_TAG_lexical_block { ... } { DW_TAG_variable { DW_AT_name "var_a" .... } } DW_TAG_lexical_block { ... } { DW_TAG_variable { DW_AT_name "var_b" ... } } Now the two lexical blocks are siblings, but if we make the second block overlap the first then this patch does cause problems. Current GDB will see the 'var_a' block first and add this to the map, then when GDB sees the 'var_b' block, only the addresses not claimed by the 'var_a' block will be allocated to the second lexical block. With this patch blocks are now processed in reverse order, so we see the 'var_b' block first and assign addresses to this, then any unassigned addresses are assigned to the 'var_a' block. This DOES change GDB's behaviour. > However I think your patch probably does not make gdb worse in this > regard. This is what I think. In the sibling block case it's not clear what the expected behaviour would actually be? In current GDB you'll only see 'var_b' at those addresses not covered by the 'var_a' block. While in patched GDB the situation is reveresed, it's 'var_a' that's missing in some cases. In both cases there are addresses where we can only see one of the variables. But it isn't 100% clear too me if this is really fixable at all with our current block hierarchy approach. Is this sibling case the type of case you were thinking of? Or have I got the wrong end of the stick here? > > Andrew> @@ -410,8 +410,6 @@ buildsym_compunit::record_block_range (struct block *block, > Andrew> if (start != block->start () > Andrew> || end_inclusive + 1 != block->end ()) > Andrew> m_pending_addrmap_interesting = true; > Andrew> - > Andrew> - m_pending_addrmap.set_empty (start, end_inclusive, block); > Andrew> } > > I think the comment before this method and the comment in the method > both need to be updated, as this doesn't actually record the range any > more. Yeah. But reading this code again I think I can drop record_block_range completely now. Blocks are basically interesting if they are non-contiguous, and buildsym_compunit::make_blockvector, which is the only place that checks m_pending_addrmap_interesting already has this code: /* Count the length of the list of blocks. */ for (next = m_pending_blocks, i = 0; next; next = next->next, i++) { } Where we could check for any non-contiguous blocks. This would mean GDB starts using the map instead of the vector for the case where a block uses DW_AT_ranges, but only has a single range. This shouldn't be a user visible change, but I guess would increase memory use a little. Still, I expect this would not be a common case as most compilers seem to optimise to low/high pc attributes for contiguous blocks. > I wonder why buildsym even tries to see if the pending addrmap might be > interesting. It seems to me that a fixed addrmap is basically the same > data structure as the blockvector: it maps addresses to blocks and uses > a binary search to find the correct entry. Sure, but I wonder if this is a memory use thing? The addrmap must use more memory than the vector, so maybe for large programs this would be a noticable hit. > > So I'm wondering if, in the longer term -- you definitely don't need to > to this here -- if we should just switch to a single representation. > > Furthermore I was wondering if it makes sense for blocks to even track > their ranges. That is, for a block with multiple ranges, could we just > have multiple entries in the blockvector and get rid of block::m_ranges? There are a few places where we use the block's ranges for useful work, these would all need to be rewritten to get the same information from the blockvector (really the addrmap within the blockvector). > > FWIW I've been looking into this area a bit while experimenting with > lazy CU expansion. There I think I want to make it so blockvectors are > always expandable, so no fixed addrmap at least -- and mutable addrmaps > have some issues with updating, so probably moving to just having a > vector. Wouldn't that cause problems for non-contiguous blocks? Isn't that the problem that the addrmap was added to solve? I'm going to look at updating to remove record_block_range completely, and test that. But I'd love to hear back about the lexical block testing I did. thanks, Andrew > > Anyway this seems fine with the comment cleanup. > Approved-By: Tom Tromey > > Tom