From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id JotGAziKqGg2rAkAWB0awg (envelope-from ) for ; Fri, 22 Aug 2025 11:18:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1755875895; bh=aSPZVrtWTMbFW2PQ8Id+leK0qlmmR3Ny14IHKnMV4PI=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=vIFs5OcxB2R+JpAhXijcufDxqZs1vG87uGHNhqecUssiOCVFVdU2h7oJCA9jPZlm4 tKSgK+wyzb2E0HBQlIeZ02UdOglB0qErD3y4BTO8oFnmuyVoEhjQ9POAPzhoX/3K4u OlgVSZGYupg3n6ZKfllx/PWv/6PmJbSo207rzTjs= Received: by simark.ca (Postfix, from userid 112) id F17511E023; Fri, 22 Aug 2025 11:18:15 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=F/GMhmb/; dkim-atps=neutral Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 47F801E023 for ; Fri, 22 Aug 2025 11:18:15 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CB4083852764 for ; Fri, 22 Aug 2025 15:18:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CB4083852764 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=F/GMhmb/ Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id BAB3F3858D32 for ; Fri, 22 Aug 2025 15:17:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BAB3F3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BAB3F3858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1755875859; cv=none; b=lyAdM09X3x+Zsuo8p8bQyRWaxAQH4lzOwsXNusMu5x+Z2bdbBSnabtUn1Nh66Ax6hkkgq414PudDYjp2s3X8Li6U9lcgN+/Kc1DDju1Mpn/N7AM08R5A3qvWcoErLPXYPMEYKZ/maDurQ9pgH5FpL3Ih6e8H1XApQYWWd+HajPk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1755875859; c=relaxed/simple; bh=aSPZVrtWTMbFW2PQ8Id+leK0qlmmR3Ny14IHKnMV4PI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=BS2nKLlfVSjKuKCzcNx+UbqKcn61D7n5HXsdQtdXqXy4m4XG+2rPex3rDg984cTB/vkP2q0wsjM0CqTCQHYMtVeEnxw/jU7MxfDNk0mkeb8EDDrSilwKmwPOgNMpcpgkmrHKL3WAsamCCV8tXVDDp8MqXsvAC8D3Z8MKEQSl4YU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BAB3F3858D32 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1755875859; bh=aSPZVrtWTMbFW2PQ8Id+leK0qlmmR3Ny14IHKnMV4PI=; h=Date:Subject:To:References:From:In-Reply-To:From; b=F/GMhmb/XxOJZcECdTm0yXRwPPj/F6fIoG+fDMNCqUVSB+NVbxBY7hbHHeLF21uka 4Qv2uLkt0o3IQh9cAvqbeaRaXqLmy3T5caK4+DHsJBfR+cUoqgJAKNE0CzV05Ieu2l wl6Q7KVuXv1dvPjxDZMPL3kpKbxIIqmI6/Bre9iM= Received: by simark.ca (Postfix) id 313811E023; Fri, 22 Aug 2025 11:17:39 -0400 (EDT) Message-ID: <55f47c0b-2153-47a0-a25f-df8ebb7f46ac@simark.ca> Date: Fri, 22 Aug 2025 11:17:37 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/5] [gdb/symtab] Improve invalid range check in create_addrmap_from_gdb_index To: Tom de Vries , gdb-patches@sourceware.org References: <20250821133114.24091-1-tdevries@suse.de> <20250821133114.24091-5-tdevries@suse.de> Content-Language: fr From: Simon Marchi In-Reply-To: <20250821133114.24091-5-tdevries@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 On 8/21/25 9:31 AM, Tom de Vries wrote: > When running test-case gdb.tui/tui-missing-src.exp with target board > gold-gdb-index (and likewise fission and fission-dwp) on aarch64-linux, I run > into: > ... > FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 () > ... > > Looking at the gold-gdb-index case, the problem is caused by the address table > of the .gdb_index section: > ... > Address table: > 000000000040066c 0000000000400694 0 > 000000000040053f 0000000000400563 1 > ... > > The address range for f2 is [0x400694, 0x4006b8), but the address table says > it's [0x40053f, 0x400563). > > The address 0x40053f is not even in a section: > ... > [Nr] Name Type Address Off Size ES Flg Lk Inf Al > ... > [12] .plt PROGBITS 00000000004004b8 0004b8 000050 10 AX 0 0 8 > [13] .text PROGBITS 0000000000400540 000540 000178 00 AX 0 0 64 > ... > but part of the hole [0x400508, 0x400540) in between .plt and .text. > > Detect this in the invalid range check in create_addrmap_from_gdb_index. > > Tested on aarch64-linux. > --- > gdb/dwarf2/read-gdb-index.c | 25 ++++++++++++++++++++++--- > 1 file changed, 22 insertions(+), 3 deletions(-) > > diff --git a/gdb/dwarf2/read-gdb-index.c b/gdb/dwarf2/read-gdb-index.c > index 79d19a3abaa..df20b20e081 100644 > --- a/gdb/dwarf2/read-gdb-index.c > +++ b/gdb/dwarf2/read-gdb-index.c > @@ -1420,14 +1420,33 @@ create_addrmap_from_gdb_index (dwarf2_per_objfile *per_objfile, > cu_index = extract_unsigned_integer (iter, 4, BFD_ENDIAN_LITTLE); > iter += 4; > > - if (lo >= hi) > + bool valid_range_p = lo < hi; > + bool valid_index_p = cu_index < index->units.size (); For readability, I would prefer kepeing each check independent. There will be less conditionals below. To avoid duplicating the warning, you can use a lambda or free function: if (lo >= hi) return invalid_range (); with, for instance: auto invalid_range = [&] () { complaint (_(".gdb_index address table has invalid range (%s - %s)"), hex_string (lo), hex_string (hi)); return false; }; > + > + /* Variable hi is the exclusive upper bound, get the inclusive one. */ > + CORE_ADDR hi_m1 = (valid_range_p > + ? hi - 1 > + : 0); > + > + if (valid_range_p) > + { > + CORE_ADDR relocated_lo > + = per_objfile->relocate (unrelocated_addr (lo)); > + CORE_ADDR relocated_hi_m1 > + = per_objfile->relocate (unrelocated_addr (hi_m1)); > + struct obj_section *lo_sect = find_pc_section (relocated_lo); > + struct obj_section *hi_sect = find_pc_section (relocated_hi_m1); > + valid_range_p = lo_sect != nullptr && hi_sect != nullptr; It only concerns MIPS, so perhaps not super important (I guess MIPS programs tend to be not too big), but per_objfile->relocate can be somewhat heavy, as mips_adjust_dwarf2_addr does one minimal symbol lookup for each address. It might not be a problem in practice, but it would seem much more logical to me if this work was done completely in the unrelocated domain. It's an analysis that can be done with the object file in isolation, independent of whether or where it's loaded in the inferior. Simon