From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2Xu3IDUvXGko2S0AWB0awg (envelope-from ) for ; Mon, 05 Jan 2026 16:37:57 -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=ftwViZK4; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 752FE1E0B6; Mon, 05 Jan 2026 16:37:57 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.1 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_SBL_CSS,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no 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 D9FF51E08D for ; Mon, 05 Jan 2026 16:37:56 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 51AC74BA2E1E for ; Mon, 5 Jan 2026 21:37:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 51AC74BA2E1E 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=ftwViZK4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 75E874BA2E04 for ; Mon, 5 Jan 2026 21:37:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 75E874BA2E04 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 75E874BA2E04 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767649049; cv=none; b=iPbGcoU8w8I0rnVeEV2OmezGZh/WF6QmB1CSPn7StK0grmKwDkf/vNLB7kbT2Xl+XdjyH04aaWyiiYs043CVods5dFkRqXez4TFNgAuPOe7mUJMm6OVbDW1+3VDDEAPFZvtV5zMphOH04iAJ1w3VzBPDHM3YimmJDIM08k71SXk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767649049; c=relaxed/simple; bh=s7tROvPcR2I12GoOAqv9KIPXScMf9RTDr6nn/fvpA9o=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=vHJ/dAiOo/NKLSv4GDpGqBuHaqAbFJOmg64Ui3peMr//YuYUq2DgZjk6SdH7nFBThVlfmscykQwFH6FbzgVHxPyT1O4THwvQn85gwmtx44awo+4YJZJPfHd4EHrOY/22LMBL4Ah2oD3QAOvsqWWsYhxbkd7OrDNxdRde79nKjMo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 75E874BA2E04 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767649049; 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=mLPXuTrFa8hn6sBQNhFvX6Hd0gN/IlDP4kYJNkkDvec=; b=ftwViZK4T23xqCtEsY0MSFhQzKDj+raHZJmF0VOn5M0lulSf6ChgOw6gfy6xdjD77fhVeK UuHwXcftToLf7fu1aSJZJEIGvBrlrWd2VghtO3uBwFsIet8TLrn1OJA7uJeRppuNAXLaj1 /3EofK5I2qYhiQG0PqX3cB2a9n0Zimg= 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-294-reT_tzsWNvOlEX89Zd5TLA-1; Mon, 05 Jan 2026 16:37:27 -0500 X-MC-Unique: reT_tzsWNvOlEX89Zd5TLA-1 X-Mimecast-MFC-AGG-ID: reT_tzsWNvOlEX89Zd5TLA_1767649046 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-4325aa61c6bso142239f8f.0 for ; Mon, 05 Jan 2026 13:37:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767649046; x=1768253846; 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=mLPXuTrFa8hn6sBQNhFvX6Hd0gN/IlDP4kYJNkkDvec=; b=cq1J/Z1+KscN/R/P/AKn0GCvQHywFpGHGRGooxYsmFyHMQ0e1faWJ5W+Mxex7MpQi8 l1HPELtBQJnDauBJHvIB/ggP9LR3SN5WV6+xxKWkDuxaJLJejLIjWSCT1kXRIQWZpHkR zwPYuYynab32QoVzshqNqMlOPqiODqjUkge/jHPhZMC5e1IJGh97MpqFWCzlyruTwnqc 9MRQ69CRqhs3FSF3IGD3qjQPxQnQdPood/vvx1QYR8WPwdWYQDGTTnbjwQqVA9Hic69R a5kqIis+/8M9WBIpQUwlLNFDMz4cWySomOgpi/g5xLfnqFlscLDBsg9HRBvbAUm2OR8L xWCw== X-Forwarded-Encrypted: i=1; AJvYcCX4fWjyXga580p3e7hdj2kUatYKH2oeuLRo5kzLdno/nahlTCqf5dyLek0sT6aa1z4/jgSrQHs8AagIeA==@sourceware.org X-Gm-Message-State: AOJu0YzKc6UIcJ44WqgagEDCtmPQgc29tIRHCZGnyhvJ3ovQtL7TG8av yOd4K5IUb05+5gPM9j3XJ9VxLHuyDGEjKyQkKWflsQLHO0sY6/Rl8EHygcvmX17dS9k9MxDAWxx pe82QPp0pkl2U2agYM9LSgfpPUHTMSPLJDC4ZXrzPBw15nsZqMyodSvCIQiQ+skt4blcJihQ= X-Gm-Gg: AY/fxX4cgwaSOfOQHUACAW42YhSKhSnzRfs1wYeqaQfD54EwAB7N6keSUGy1H7NZ8fF Ozkjik+AjgAEf33RZ18vkYy+sP2stzaZRB9eWl+o6gQRLVQrENY3X5VAhutSv4hgvFd6o/ER6RR EEqLtJRjTISL6iK9s77HouisyBKDLB0xgfsNS6Mesuii5xPBezYUDZBPozYI+elcDrHs468Z6Eb bfu5qxec5J7w6MOFJq1riu0NRIAUsNpJt8/Zdhfg0GiYzElE2GZeFzTAPzl1z55kGkZey9HeRd7 J1QY1AETuarGEcP/UPJSK3aF+mde8c6+/Eeo7EAH8XIzTH/Kgyrr+iYlczzaUZKw07sCkyM1FxJ rv7bB0T08ny9YbPHjmoly/qSTNitd X-Received: by 2002:a05:6000:40ce:b0:430:f2ee:b220 with SMTP id ffacd0b85a97d-432bca38a87mr1426024f8f.19.1767649046196; Mon, 05 Jan 2026 13:37:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IFZPyVzCIlnr//r24OAo4cdql4CTYrAMgdMXO3ypwN4NL2gbfhtjOIvmHoK/IizRLIbs4MHIw== X-Received: by 2002:a05:6000:40ce:b0:430:f2ee:b220 with SMTP id ffacd0b85a97d-432bca38a87mr1426011f8f.19.1767649045813; Mon, 05 Jan 2026 13:37:25 -0800 (PST) Received: from localhost (84.81.93.209.dyn.plus.net. [209.93.81.84]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5df91fsm691339f8f.23.2026.01.05.13.37.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 13:37:25 -0800 (PST) From: Andrew Burgess To: Tom Tromey Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCHv3 5/7] gdb: create address map after parsing all DIE In-Reply-To: <878qebvnce.fsf@tromey.com> References: <87ikg09cnl.fsf@tromey.com> <87o6ncyns4.fsf@redhat.com> <878qebvnce.fsf@tromey.com> Date: Mon, 05 Jan 2026 21:37:24 +0000 Message-ID: <87v7hfwxkb.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 8NCam4GuGcUWjPMo7vszijO8K83K7cCOZZRryEYj2dY_1767649046 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 Tom Tromey writes: >>>>>> "Andrew" == Andrew Burgess writes: > > 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. > > [...] > Andrew> Now the two lexical blocks are siblings, but if we make the second block > Andrew> overlap the first then this patch does cause problems. > [...] > Andrew> This DOES change GDB's behaviour. > > Andrew> Is this sibling case the type of case you were thinking of? Or have I > Andrew> got the wrong end of the stick here? > > I think your analysis is in line with what I was thinking. > > My main concern is whether incorrect input can make gdb crash by > violating some addrmap invariant; and then also if sufficiently weird > but nominally valid input can make gdb do the wrong thing. I'm not too worried about addrmap crashing; I'm just adding things in a slightly different order so if there is some weird overlap, addrmap will just build a different address to block mapping, but this shouldn't cause crashes from addrmap. And ideally shouldn't be crashing the rest of GDB either, we'll just end up with a different block (possibly, and again, this is only in the case of some weird overlap). At least, my experience while working on this was less, oops I've built the wrong addrmap and now GDB crashed, and more, I've built the wrong addrmap, and now GDB doesn't know where it is stopped, or the local variables are no longer visible. Which brings us to your second worry. This patch, for sure changes the order in which blocks are added into the addrmap. More nested blocks are added before their parents, so if we don't have overlapping siblings, then this should result in the same mapping. But I cannot guarantee that there's not some weird compiler out there that does emit such cases. But we don't have tests for such cases yet, and I saw no comments discussing such things, so I'm hoping that's not a thing. If we do have overlapping siblings then I don't think current GDB will work; at least, locals from one of the siblings will not be visible in the overlap region. This patch might change which sibling though. When I originally wrote this patch I did try to retain the original order in which blocks are added to the addrmap, and I looked at this again today. The problem is the particular ordering we use when building the pending block list (see record_pending_block), as well as pending block sorting (see end_compunit_symtab_get_static_block). The conclusion I've come to is that if the original block order is critical, or if we just don't want to move away from this ordering, then we'd need to add another data structure to track the desired order. I didn't do this for two reasons (1) saving space and time, and (2) so long as the bottom up invariant remained, I figured the other changes should be harmless. You did give an approve for the original patch; I still need to update the comments as you suggested, but is there anything else you'd like me to investigate to help address your concerns? Otherwise my hope would be to merge this and address any issues if/when they arise down the line. Thanks, Andrew