From patchwork Mon Dec 29 16:15:14 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 127200 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id BA5594BA2E07 for ; Mon, 29 Dec 2025 16:16:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BA5594BA2E07 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=UdItJrSx X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org 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 66D984BA2E26 for ; Mon, 29 Dec 2025 16:15:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 66D984BA2E26 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 66D984BA2E26 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=1767024932; cv=none; b=BoSiQDK9YYViC0Y9Pl+B/YnNPXpESrNi1cpbkA0/MGeNEq/EdfINFBUBv7ShTZ0Na8sBmzWadzMCy9EXRRijuM/2gQWucvbmu4FVBBUKQpeN4N+/7x/c74Bgqj7HOG+pAFHlkfaLgpIUyn88N7EfZNh0DoTEs+INxmonwikeQ/A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767024932; c=relaxed/simple; bh=DAIA0iiG0DsyacQOBWsRbEIqWMjJ1GWLg4pUj0ZvBwo=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=a+Jvodj5vZ9jvPNcvUIFD9NLhdkda3pZMtUSS8/0A+jc9ScgduNlkfiCfa/a/b4uxWaxQPeDGF7DIBF8vC+8dqlx1NdSb/ipdsgiYQ2uxNymE7Yqd0TzjlkEjUV9sa88+Nqfpw0IOCRf6x3/jExdMMS1frfnngAQb4Uxm+GMfMw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 66D984BA2E26 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767024932; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=e51DLY0I5y9mO3Lo0vJGptLWTXreYDHxQTCPf0owC58=; b=UdItJrSx1zPttcheTTRhxHrbvNPngSXo3Kq11E6VzsVyJzwcZx19HwkVcqaWhQDTb3iOIt XZpULFfamBZOf3/3uTpsxX5APSOthwH1wfx2G7C/p5EBBJDn/klDUJi9ALEKtgfUwayvnd FvgzoFyPV18P+1Q43pi/uCCvHVz0Wak= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-689-ck-DQP0WOdSkJhalq034OQ-1; Mon, 29 Dec 2025 11:15:30 -0500 X-MC-Unique: ck-DQP0WOdSkJhalq034OQ-1 X-Mimecast-MFC-AGG-ID: ck-DQP0WOdSkJhalq034OQ_1767024929 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4779edba8f3so68067845e9.3 for ; Mon, 29 Dec 2025 08:15:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767024929; x=1767629729; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=e51DLY0I5y9mO3Lo0vJGptLWTXreYDHxQTCPf0owC58=; b=lC8KXukgBEz5ZUSR2IZbOzq/yK7d4ZB8dwqadJ+e+JzYkJk0DjJ1wnYEdKW9I0oMIr 5dusajMljFfFnVZzznOdV1UA/nzL5yT2k9emYwInsMoTE9g3UgxMsVLClyHKpzaPVFdA 1o8hVteYYycY3jRwRAcomer2zWA+wZuIXHpVJYRaQltK3rEDStxlIWUpJ24gdi4U2iS8 r33BgyNadsY2zd10xYAYIH1yVOQyxdyk2yVUqqtfpQfP/+4Vz+M/daTBc5IvatiKo4/7 V+OWIB2gN1XQSlWrt241Mz345y/NAxr4R/Ea3aZlieYBCDnU6cUFeCaiCteA9OiINAlx 6ggQ== X-Gm-Message-State: AOJu0YyFr5NyeN0cO7+B/4qzeVRLQczucKmpbfMHrCZMisABOxmVOoi6 sV4q+Ge21sIFqvgJDBOVKmzr3tjoGICPLP6kcxjR8ZYhimHOKHMEC9yNPZzEqU3JJMzduRD5iP0 dZnsI25A8EVK7trntk8LPsJjSRpQ6PiON5Mk6KXpciyrt4yjuSYej1LXIym5uctwj5z4WBA110M qtxzdJGTiQdsmq5E2O7svvJrG/bUGMa8bQGF60/7HZ7qS9i0I= X-Gm-Gg: AY/fxX4m9N3NE+++8cNZhYVLXqS4CaZgbD53GlEM/ZFrw3OP0BVUzNZEh+Bf+i/5Jwk 0+RVfhKFKSTpKAPIJkCWTuwF6YdoO8UIGscBlVhqX/UhwUZTmkVRuJ4UU7eTAOYlE5XHFBgY0ZU +UmpjBhY+F/GL/Rn96uwodeEIodfLysLwWK+q00qACYbu0evufspz1euXHX3zwAEz9RyC28es8C ZjBy3lql+xL13fpCPClzkXF7Twz1SRwqjCf4/uvvv24J4AfE5KgMHLgr4MT034HIU7gHt4T2DwT waihjkQJ3VvvvgBO1jaw2B28Euyk4pvIDpg3CrzeZsf7oaqldpxHWY8/ik6tUOuuROijU2Z9GFc 87BEfJiJ2ToHRHZvlMMaUD/LfApgq4PInQQ== X-Received: by 2002:a05:600c:154b:b0:477:55c9:c3ea with SMTP id 5b1f17b1804b1-47d1958e7b9mr377851935e9.35.1767024928715; Mon, 29 Dec 2025 08:15:28 -0800 (PST) X-Google-Smtp-Source: AGHT+IF6aWg0L+iwxnZ36tgLncJDki+oqY1wK5g3xhiK6mTH312/d8L0CWj5yZZz0G0ReCV35Plyog== X-Received: by 2002:a05:600c:154b:b0:477:55c9:c3ea with SMTP id 5b1f17b1804b1-47d1958e7b9mr377851605e9.35.1767024928184; Mon, 29 Dec 2025 08:15:28 -0800 (PST) Received: from localhost (92.40.168.223.threembb.co.uk. [92.40.168.223]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d1936d220sm593914915e9.8.2025.12.29.08.15.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Dec 2025 08:15:27 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv4 1/7] gdb/dwarf: remove line_header parameter from dwarf2_decode_lines Date: Mon, 29 Dec 2025 16:15:14 +0000 Message-Id: X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: AzkXz2_SHOgy2_6vgzzdbKhoLMamGA-B5T5I4lyJVBY_1767024929 X-Mimecast-Originator: redhat.com content-type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_BLOCKED, RCVD_IN_MSPIKE_H2, RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on sourceware.org 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~patchwork=sourceware.org@sourceware.org The function declaration for dwarf2_decode_lines is: void dwarf_decode_lines (struct line_header *lh, struct dwarf2_cu *cu, unrelocated_addr lowpc, bool decode_mapping) However, it is always the case that: lh == cu->line_header I propose that we simplify the dwarf_decode_lines signature by removing the line_header parameter. The same is true for dwarf_decode_lines_1, which is only called from dwarf_decode_lines. I'm proposing this change because I was looking through the DWARF code, trying to understand how symtabs are created, and this extra complexity just makes things harder to understand: what is the relationship between the line_header (LH) and dwarf2_cu (CU) parameters? When would we ever want to process a line_header other than the one attached to CU? (answer: never, and we don't). This simplification makes things easier to understand (IMHO). There should be no user visible changes after this commit. --- gdb/dwarf2/line-program.c | 15 ++++++++------- gdb/dwarf2/line-program.h | 10 ++-------- gdb/dwarf2/read.c | 2 +- 3 files changed, 11 insertions(+), 16 deletions(-) diff --git a/gdb/dwarf2/line-program.c b/gdb/dwarf2/line-program.c index c30f70dd11a..75c4a060a09 100644 --- a/gdb/dwarf2/line-program.c +++ b/gdb/dwarf2/line-program.c @@ -481,12 +481,12 @@ lnp_state_machine::check_line_address (struct dwarf2_cu *cu, } /* Subroutine of dwarf_decode_lines to simplify it. - Process the line number information in LH. */ + Process the line number information in CU::line_header. */ static void -dwarf_decode_lines_1 (struct line_header *lh, struct dwarf2_cu *cu, - unrelocated_addr lowpc) +dwarf_decode_lines_1 (struct dwarf2_cu *cu, unrelocated_addr lowpc) { + struct line_header *lh = cu->line_header; const gdb_byte *line_ptr, *extended_end; const gdb_byte *line_end; unsigned int bytes_read, extended_len; @@ -694,11 +694,11 @@ dwarf_decode_lines_1 (struct line_header *lh, struct dwarf2_cu *cu, /* See dwarf2/line-program.h. */ void -dwarf_decode_lines (struct line_header *lh, struct dwarf2_cu *cu, - unrelocated_addr lowpc, bool decode_mapping) +dwarf_decode_lines (struct dwarf2_cu *cu, unrelocated_addr lowpc, + bool decode_mapping) { if (decode_mapping) - dwarf_decode_lines_1 (lh, cu, lowpc); + dwarf_decode_lines_1 (cu, lowpc); /* Make sure a symtab is created for every file, even files which contain only variables (i.e. no code with associated @@ -706,7 +706,8 @@ dwarf_decode_lines (struct line_header *lh, struct dwarf2_cu *cu, buildsym_compunit *builder = cu->get_builder (); struct compunit_symtab *cust = builder->get_compunit_symtab (); - for (auto &fe : lh->file_names ()) + struct line_header *lh = cu->line_header; + for (file_entry &fe : lh->file_names ()) { dwarf2_start_subfile (cu, fe, *lh); subfile *sf = builder->get_current_subfile (); diff --git a/gdb/dwarf2/line-program.h b/gdb/dwarf2/line-program.h index 824f18f9613..522dd994fc8 100644 --- a/gdb/dwarf2/line-program.h +++ b/gdb/dwarf2/line-program.h @@ -20,12 +20,7 @@ #ifndef GDB_DWARF2_LINE_PROGRAM_H #define GDB_DWARF2_LINE_PROGRAM_H -/* Decode the Line Number Program (LNP) for the given line_header - structure and CU. The actual information extracted and the type - of structures created from the LNP depends on the value of PST. - - FND holds the CU file name and directory, if known. - It is used for relative paths in the line table. +/* Decode the Line Number Program (LNP) for CU::line_header. NOTE: It is important that psymtabs have the same file name (via strcmp) as the corresponding symtab. Since the directory is not @@ -40,8 +35,7 @@ for its PC<->lines mapping information. Otherwise only the filename table is read in. */ -extern void dwarf_decode_lines (struct line_header *lh, - struct dwarf2_cu *cu, +extern void dwarf_decode_lines (struct dwarf2_cu *cu, unrelocated_addr lowpc, bool decode_mapping); #endif /* GDB_DWARF2_LINE_PROGRAM_H */ diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 4e2644ba959..a783cee7337 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -6099,7 +6099,7 @@ handle_DW_AT_stmt_list (struct die_info *die, struct dwarf2_cu *cu, then there won't be any interesting code in the CU, but a check later on (in lnp_state_machine::check_line_address) will fail to properly exclude an entry that was removed via --gc-sections. */ - dwarf_decode_lines (cu->line_header, cu, lowpc, decode_mapping && have_code); + dwarf_decode_lines (cu, lowpc, decode_mapping && have_code); } /* Process DW_TAG_compile_unit or DW_TAG_partial_unit. */ From patchwork Mon Dec 29 16:15:15 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 127205 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id D49024BA2E1D for ; Mon, 29 Dec 2025 16:19:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D49024BA2E1D 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=F+dBaAed X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org 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 9EE3B4BA2E2E for ; Mon, 29 Dec 2025 16:15:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9EE3B4BA2E2E 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 9EE3B4BA2E2E 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=1767024943; cv=none; b=foD5Xh5UnJcSbJANuXzZEg+pMgw5wadfwdJAYeIhLkYRUQAa1/fjWdjMGH9OoKsbS+9NmmwHHr4oqAZVG3WsECoI8623/37HKpwXuH7/8BC3TmMworHCnOEHHGY+nrlNfwz5W5V0sMIPxYQylTGCxOB8thv/0znZ3yhwQGFDy2U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767024943; c=relaxed/simple; bh=gdtbDrO/lvv4FtpFBYmTE3bVOFZl869FeqVMfVO3GbY=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=YBYRvX2Bk2+aHlhF8s8KOOzFwATpkeHRrL6G9HSzKbxfbd+NUSqWRCusqZXxnZt4bqZ3kwJWvw2q4XKPNDx6L9i0cUktRjZgIs/TDwtyi28jgU+3C2Pry99Ab3w0jdQkNykr4iWNSZ9yWsUDKee7jP1C6xQKhigWpL2GohKHZpI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9EE3B4BA2E2E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767024938; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ywirmlkR7R1pznjA0JGiUTnTCfHpX/PHLbAquu7ceMQ=; b=F+dBaAed7uklD3IP5X6PlLS+99JKlOXJdhMGXsMcSim27tYSfIDGYnPqVtL1/w/znhATyK 9ufoJoiYoYNKdJllEogEQ1KbdBY41c9YcfOV3rEl7+gno0/O6Kop1/Yhk+VgsNtXu4QSQs WI5G6lFPoQ68Y2d7L/1tZa4nSf0l6ow= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-348-avmYl6bsNqeLbyidCqOv1g-1; Mon, 29 Dec 2025 11:15:36 -0500 X-MC-Unique: avmYl6bsNqeLbyidCqOv1g-1 X-Mimecast-MFC-AGG-ID: avmYl6bsNqeLbyidCqOv1g_1767024936 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-430fdc1fff8so4488709f8f.3 for ; Mon, 29 Dec 2025 08:15:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767024935; x=1767629735; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ywirmlkR7R1pznjA0JGiUTnTCfHpX/PHLbAquu7ceMQ=; b=iWTcPYFymYzdDvfg3PQd1bneYHyTbnTPHMnkpLuchwi/lgiL69ZvtPv5xrRggLBaaV kZ+W82Bawa6N56v0EQgq/d6o1X/2eEnEGDuRbK2L+i7wBmB0lz9ttY9tlYV2KYt33iiA 0o/uNGpAXMvksRKA5lCTy8r4WwiogxIFrtbuAycoIaykCU9DNKrpObsYaNg4GBUMoJnU M7DKzxZAiCZK1sp7vt0EaCChdsBugxHp7GQPJIuThE4b/axKxEaK5wH4a6tuyxfCl4EE PIY6oHt3tBBSp0Zu8PhAlOrWhl71qlF1wf3ufUIf9P2zr3taggEA+wYL1CY8fC45krYw mwpA== X-Gm-Message-State: AOJu0YwanAwJK+plQHfOAF1uScgSzzmwyJluUNHvRV/E7iHWLXLJh5rX IAdtEE+X9mhOcZX/Klj/FwLSPLm/uPlHcJn+q0DsbLE7+axDzrTi4Zc5uq8G1LwQwcAMORcqAyn T3gWlKtXZXGeRQHWIK01VFvF86/42fxRDpCowvFwf6BahOYPNCL8rI5p6T1W9j+23giyKdN/JGz yvSfp6eBUXYxfbgNaa8BJprhNlpJnxPRTEF2rWlMcd7jHn4hE= X-Gm-Gg: AY/fxX6lA8UCCNLwIgcSy/V/iUW34mSkzeW0HiFAnFYbvu/xNbalyT+nkjV1nJCn78G vV9RMUg5E/ewQAC/hPLmBMxilyAxIJ7oKxdz6oJqdbumsddE2Yz1aW5MfDK+hGWZlCmoq+cAX02 vJxAw9eu+6Xmjg+wSpLupZbuRQmXsAR1/WwNCDcKzy4sXZjsN0l2UTva9pvfiamts3bfXN52x7A 6zG1X78jvOIjrFvb6Dcman1NB9zlI7Xi0if3LqrkSDFFWf+9jLiNk+jTNX1V8loSj93Rt7Z7Dgi 8xqfXjRsehet9MuTA19R35ztaLCdm6is3F8aAiIZXTo7ZHXEPAlYazxfEOG/X+CV+iGIhLa2nfI B0jw8PimrrBqJ3Nk6mI4mJy8zHtrwIhzxQg== X-Received: by 2002:a05:6000:24c8:b0:431:808:2d58 with SMTP id ffacd0b85a97d-4324e50d219mr37248292f8f.51.1767024930309; Mon, 29 Dec 2025 08:15:30 -0800 (PST) X-Google-Smtp-Source: AGHT+IGGUpNDBmc+vVdqYnio6Hyp5S+GLMwljjZBux1oM+f974zjrFdf4GRZySKDxTCBwYgF8LM6xw== X-Received: by 2002:a05:6000:24c8:b0:431:808:2d58 with SMTP id ffacd0b85a97d-4324e50d219mr37248258f8f.51.1767024929795; Mon, 29 Dec 2025 08:15:29 -0800 (PST) Received: from localhost (92.40.168.223.threembb.co.uk. [92.40.168.223]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4324ea1af20sm59852393f8f.2.2025.12.29.08.15.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Dec 2025 08:15:29 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv4 2/7] gdb/dwarf: remove m_line_header from lnp_state_machine class Date: Mon, 29 Dec 2025 16:15:15 +0000 Message-Id: X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Kjposy6srf2WEWFzRkkzW3gJQY_bUyekFTv5aeJuaO0_1767024936 X-Mimecast-Originator: redhat.com content-type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_BLOCKED, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on sourceware.org 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~patchwork=sourceware.org@sourceware.org Following on from the previous commit, this commit remove m_line_header from the lnp_state_machine class. The lnp_state_machine class already holds m_cu, a dwarf2_cu, and the m_line_header was always just m_cu->line_header, so instead of holding both of these separately, lets just hold m_cu, and access the line header through that. There should be no user visible changes after this commit. --- gdb/dwarf2/line-program.c | 46 ++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 25 deletions(-) diff --git a/gdb/dwarf2/line-program.c b/gdb/dwarf2/line-program.c index 75c4a060a09..14cc6c5a81e 100644 --- a/gdb/dwarf2/line-program.c +++ b/gdb/dwarf2/line-program.c @@ -46,13 +46,13 @@ class lnp_state_machine public: /* Initialize a machine state for the start of a line number program. */ - lnp_state_machine (struct dwarf2_cu *cu, gdbarch *arch, line_header *lh); + lnp_state_machine (struct dwarf2_cu *cu, gdbarch *arch); file_entry *current_file () { /* lh->file_names is 0-based, but the file name numbers in the statement program are 1-based. */ - return m_line_header->file_name_at (m_file); + return m_cu->line_header->file_name_at (m_file); } /* Record the line in the state machine. END_SEQUENCE is true if @@ -161,9 +161,6 @@ class lnp_state_machine gdbarch *m_gdbarch; - /* The line number header. */ - line_header *m_line_header; - /* These are part of the standard DWARF line number state machine, and initialized according to the DWARF spec. */ @@ -206,29 +203,29 @@ void lnp_state_machine::handle_advance_pc (CORE_ADDR adjust) { CORE_ADDR addr_adj = (((m_op_index + adjust) - / m_line_header->maximum_ops_per_instruction) - * m_line_header->minimum_instruction_length); + / m_cu->line_header->maximum_ops_per_instruction) + * m_cu->line_header->minimum_instruction_length); addr_adj = gdbarch_adjust_dwarf2_line (m_gdbarch, addr_adj, true); m_address = (unrelocated_addr) ((CORE_ADDR) m_address + addr_adj); m_op_index = ((m_op_index + adjust) - % m_line_header->maximum_ops_per_instruction); + % m_cu->line_header->maximum_ops_per_instruction); } void lnp_state_machine::handle_special_opcode (unsigned char op_code) { - unsigned char adj_opcode = op_code - m_line_header->opcode_base; - unsigned char adj_opcode_d = adj_opcode / m_line_header->line_range; - unsigned char adj_opcode_r = adj_opcode % m_line_header->line_range; + unsigned char adj_opcode = op_code - m_cu->line_header->opcode_base; + unsigned char adj_opcode_d = adj_opcode / m_cu->line_header->line_range; + unsigned char adj_opcode_r = adj_opcode % m_cu->line_header->line_range; CORE_ADDR addr_adj = (((m_op_index + adj_opcode_d) - / m_line_header->maximum_ops_per_instruction) - * m_line_header->minimum_instruction_length); + / m_cu->line_header->maximum_ops_per_instruction) + * m_cu->line_header->minimum_instruction_length); addr_adj = gdbarch_adjust_dwarf2_line (m_gdbarch, addr_adj, true); m_address = (unrelocated_addr) ((CORE_ADDR) m_address + addr_adj); m_op_index = ((m_op_index + adj_opcode_d) - % m_line_header->maximum_ops_per_instruction); + % m_cu->line_header->maximum_ops_per_instruction); - int line_delta = m_line_header->line_base + adj_opcode_r; + int line_delta = m_cu->line_header->line_base + adj_opcode_r; advance_line (line_delta); record_line (false); m_discriminator = 0; @@ -247,7 +244,7 @@ lnp_state_machine::handle_set_file (file_name_index file) else { m_line_has_non_zero_discriminator = m_discriminator != 0; - dwarf2_start_subfile (m_cu, *fe, *m_line_header); + dwarf2_start_subfile (m_cu, *fe, *m_cu->line_header); } } @@ -255,17 +252,17 @@ void lnp_state_machine::handle_const_add_pc () { CORE_ADDR adjust - = (255 - m_line_header->opcode_base) / m_line_header->line_range; + = (255 - m_cu->line_header->opcode_base) / m_cu->line_header->line_range; CORE_ADDR addr_adj = (((m_op_index + adjust) - / m_line_header->maximum_ops_per_instruction) - * m_line_header->minimum_instruction_length); + / m_cu->line_header->maximum_ops_per_instruction) + * m_cu->line_header->minimum_instruction_length); addr_adj = gdbarch_adjust_dwarf2_line (m_gdbarch, addr_adj, true); m_address = (unrelocated_addr) ((CORE_ADDR) m_address + addr_adj); m_op_index = ((m_op_index + adjust) - % m_line_header->maximum_ops_per_instruction); + % m_cu->line_header->maximum_ops_per_instruction); } /* Return true if we should add LINE to the line number table. @@ -432,19 +429,18 @@ lnp_state_machine::record_line (bool end_sequence) m_stmt_at_address |= (m_flags & LEF_IS_STMT) != 0; } -lnp_state_machine::lnp_state_machine (struct dwarf2_cu *cu, gdbarch *arch, - line_header *lh) +lnp_state_machine::lnp_state_machine (struct dwarf2_cu *cu, gdbarch *arch) : m_cu (cu), m_builder (cu->get_builder ()), m_gdbarch (arch), - m_line_header (lh), /* Call `gdbarch_adjust_dwarf2_line' on the initial 0 address as if there was a line entry for it so that the backend has a chance to adjust it and also record it in case it needs it. This is currently used by MIPS code, cf. `mips_adjust_dwarf2_line'. */ m_address ((unrelocated_addr) gdbarch_adjust_dwarf2_line (arch, 0, 0)), - m_flags (lh->default_is_stmt ? LEF_IS_STMT : (linetable_entry_flags) 0), + m_flags (m_cu->line_header->default_is_stmt + ? LEF_IS_STMT : (linetable_entry_flags) 0), m_last_address (m_address) { } @@ -503,7 +499,7 @@ dwarf_decode_lines_1 (struct dwarf2_cu *cu, unrelocated_addr lowpc) { /* The DWARF line number program state machine. Reset the state machine at the start of each sequence. */ - lnp_state_machine state_machine (cu, gdbarch, lh); + lnp_state_machine state_machine (cu, gdbarch); bool end_sequence = false; /* Start a subfile for the current file of the state From patchwork Mon Dec 29 16:15:16 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 127201 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 6A2054BA2E29 for ; Mon, 29 Dec 2025 16:17:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6A2054BA2E29 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=eDxGOu7F X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org 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 45ADC4BA2E26 for ; Mon, 29 Dec 2025 16:15:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 45ADC4BA2E26 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 45ADC4BA2E26 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=1767024935; cv=none; b=ebmdh303HGuPDHHQwcMLNYz3rMFKVkZ6SK7qw5sWRrPFePGwfi4DlIRMSaG5eLe9Hc0dRq1GhXlBZRpeyRlWQYLYWHeYlcln/66FxwO0bxHsxpf6LNBIbbu/OtVIt1P8ybrnbXFMZsUCeadmald8+mRSX499MzmWex4NIXMtRKM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767024935; c=relaxed/simple; bh=3IIliR3jsWc+N1N3uym9MNvveS81NAFD56ApYxdyl4Y=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=TTmBVp75V9mdIRN8k9qBckwmUHhVh6yCKmomqFjprtudHK6iMU2EV3QPIH3vamG/7Z+4YewwS2d/gO4u10+OWWtJ78HWe2FsR7ANcXNZA92PmhqjEftWVck0SkdOi+LrMKlMS+5yleXU2HVOJoZrigJb/B661w94RFxKjC3xTLM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 45ADC4BA2E26 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767024934; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4KQ4vDBzwhawb4JP0d1nGPqSktcxOZQCEXpSncncing=; b=eDxGOu7Fpmjgj/9pTKHVdRP6SvdlvIiNY0jZX+rv0c/IVkYOxdl0my/lES98FE3Vnq9425 M/rgyRpozMWqAiZN6Sr2iUadJyALJrDDXOTpNxMONmqy/GJZHmzaM3TDZ+9zWxm2ytcbCM GK3TPGp/gI85VSGCDZK78sHQCAf9lwI= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-128-U5g5jLS3NwagUTiOKlW1Qw-1; Mon, 29 Dec 2025 11:15:33 -0500 X-MC-Unique: U5g5jLS3NwagUTiOKlW1Qw-1 X-Mimecast-MFC-AGG-ID: U5g5jLS3NwagUTiOKlW1Qw_1767024932 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-4325cc15176so4210145f8f.1 for ; Mon, 29 Dec 2025 08:15:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767024932; x=1767629732; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=4KQ4vDBzwhawb4JP0d1nGPqSktcxOZQCEXpSncncing=; b=qyC4h9XLCbkqWtqprb+aIuDNojU2oJmmahk+WOVSG8/r4NbXBtqgARdKiKLMOIU3TK z1I4Ka+s8Ik1RovuNXAQzGV1TiAYmruLYgcMAKWCzfKn94sfElvgU/yQxZJYfBKaYHDP Y+5Y0y37Ye14ZFGiu6td7qdmnWA0j9jKgzGKeZtffZBjQsvutj7czmE7q/UGcgTqaUQy YdglLqb5hIS1WaWXQw8Hu8nr50aRby5qTBTzATO1wCdrpZvTBR7Urf9GYdhY+a084LWD WSH97jIiWQ/vhW7AuO6b7hQYi/h1OvTBCr+os9n02+2Up0QNkD4qysP/62vib5EfO2Lu RN5g== X-Gm-Message-State: AOJu0Yxhk6K81RTUAFV9w9jH3t6ELv3EKunS00A3yeAK7GnJk0/4phCn +hfaQR0QGUnlXiW4skK1/JRAXifPI75ui062rXjP9sLPDdjmXFq2Zyid+lHOKDSgWg2YdH1Trje GXlDP/R5i6UtWvufLSGmO3aC+zE8bW0BbuvCKSdxdEr+dXt1mKH26HmWNedfG9kyuyfEyLdGW3a upN9PRULkybKnnt4GInDUsbdkrsVqnFJrSmflTVjrpnw+5np4= X-Gm-Gg: AY/fxX7gWFc5kipC5IKHtDGZyB23PMBsqTA3OCUGcwEohaWg3eEEtCyPf7Iei/V75zL 6Zm5tka7KpyohVHNlFtmkGuEnhbk3K4Fxzb+TKd9foPyuamaOjQqadj6g/7B5Sm1wJ5fUKDAk2G 8PoqNymQ7HeAddr8LAbCGjsErpBLtFgoor9unYRi9YthX7ZPaaW4pqlKr5eCbJq6pluFmb/qXI4 ITBbUfIuXyghFKK95nkSbAQYmwEnQBMo4LhTKojZRZUlseugziMopP97IRIuyYsrKMM4/MVv2B4 ZPIzaLnJebzvYhzjeKUX3myTpWkzhqBltQR5/xV6ML5UW42LfzjfTGY/Pfdg19iQh0dVEYA4DTW 5Jb1YQs1hRNWeBkkJVYVF7LQQ8VpHZDkyHw== X-Received: by 2002:a05:6000:1865:b0:42f:b9f6:f118 with SMTP id ffacd0b85a97d-4324e4cc03bmr42288906f8f.15.1767024931750; Mon, 29 Dec 2025 08:15:31 -0800 (PST) X-Google-Smtp-Source: AGHT+IFgJYzihkoSh2oEUfLGd1GQQMMI3APAnUhvS1nustEIkWM8sWRtNaHDjG465x9t8puz7sZIxA== X-Received: by 2002:a05:6000:1865:b0:42f:b9f6:f118 with SMTP id ffacd0b85a97d-4324e4cc03bmr42288865f8f.15.1767024931236; Mon, 29 Dec 2025 08:15:31 -0800 (PST) Received: from localhost (92.40.168.223.threembb.co.uk. [92.40.168.223]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4324eab2a94sm63722746f8f.43.2025.12.29.08.15.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Dec 2025 08:15:30 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv4 3/7] gdb/dwarf: remove the line_header argument from dwarf2_start_subfile Date: Mon, 29 Dec 2025 16:15:16 +0000 Message-Id: <84d20d9d8b20f6136f65904ef27dfbdda8bdb1ac.1767024363.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 921xsev7gtaw_bF6FsnkbCkUXcBcbApCVhGiUg5KFKk_1767024932 X-Mimecast-Originator: redhat.com content-type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_BLOCKED, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on sourceware.org 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~patchwork=sourceware.org@sourceware.org As with the previous two commits, this commit removes the line_header argument from dwarf2_start_subfile. This function already takes a dwarf2_cu argument, and the line_header passed in is always the line header pointed to by the dwarf2_cu argument, so lets just access the line header through the dwarf2_cu. As dwarf2_start_subfile relies on the dwarf2_cu always being non-NULL, I've converted the dwarf2_cu argument from a pointer to a reference. The alternative was adding an assert within dwarf2_start_subfile that the pointer was not NULL. There should be no user visible changes after this commit. --- gdb/dwarf2/line-program.c | 9 ++++----- gdb/dwarf2/read.c | 11 +++++------ gdb/dwarf2/read.h | 8 +++----- 3 files changed, 12 insertions(+), 16 deletions(-) diff --git a/gdb/dwarf2/line-program.c b/gdb/dwarf2/line-program.c index 14cc6c5a81e..46da4bf5a42 100644 --- a/gdb/dwarf2/line-program.c +++ b/gdb/dwarf2/line-program.c @@ -244,7 +244,7 @@ lnp_state_machine::handle_set_file (file_name_index file) else { m_line_has_non_zero_discriminator = m_discriminator != 0; - dwarf2_start_subfile (m_cu, *fe, *m_cu->line_header); + dwarf2_start_subfile (*m_cu, *fe); } } @@ -507,7 +507,7 @@ dwarf_decode_lines_1 (struct dwarf2_cu *cu, unrelocated_addr lowpc) const file_entry *fe = state_machine.current_file (); if (fe != NULL) - dwarf2_start_subfile (cu, *fe, *lh); + dwarf2_start_subfile (*cu, *fe); /* Decode the table. */ while (line_ptr < line_end && !end_sequence) @@ -702,10 +702,9 @@ dwarf_decode_lines (struct dwarf2_cu *cu, unrelocated_addr lowpc, buildsym_compunit *builder = cu->get_builder (); struct compunit_symtab *cust = builder->get_compunit_symtab (); - struct line_header *lh = cu->line_header; - for (file_entry &fe : lh->file_names ()) + for (file_entry &fe : cu->line_header->file_names ()) { - dwarf2_start_subfile (cu, fe, *lh); + dwarf2_start_subfile (*cu, fe); subfile *sf = builder->get_current_subfile (); if (sf->symtab == nullptr) diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index a783cee7337..f92d9b6eb42 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -6275,7 +6275,7 @@ dwarf2_cu::setup_type_unit_groups (struct die_info *die) for (i = 0; i < file_names.size (); ++i) { file_entry &fe = file_names[i]; - dwarf2_start_subfile (this, fe, *line_header); + dwarf2_start_subfile (*this, fe); buildsym_compunit *b = get_builder (); subfile *sf = b->get_current_subfile (); @@ -15993,12 +15993,11 @@ dwarf_decode_line_header (sect_offset sect_off, struct dwarf2_cu *cu, /* See dwarf2/read.h. */ void -dwarf2_start_subfile (dwarf2_cu *cu, const file_entry &fe, - const line_header &lh) +dwarf2_start_subfile (dwarf2_cu &cu, const file_entry &fe) { std::string filename_holder; const char *filename = fe.name; - const char *dirname = lh.include_dir_at (fe.d_index); + const char *dirname = cu.line_header->include_dir_at (fe.d_index); /* In order not to lose the line information directory, we concatenate it to the filename when it makes sense. @@ -16013,8 +16012,8 @@ dwarf2_start_subfile (dwarf2_cu *cu, const file_entry &fe, filename = filename_holder.c_str (); } - std::string filename_for_id = lh.file_file_name (fe); - cu->get_builder ()->start_subfile (filename, filename_for_id.c_str ()); + std::string filename_for_id = cu.line_header->file_file_name (fe); + cu.get_builder ()->start_subfile (filename, filename_for_id.c_str ()); } static void diff --git a/gdb/dwarf2/read.h b/gdb/dwarf2/read.h index 412b5a2d9b1..4ae2236466f 100644 --- a/gdb/dwarf2/read.h +++ b/gdb/dwarf2/read.h @@ -1410,9 +1410,8 @@ extern const dwarf2_section_info &get_section_for_ref extern struct dwarf2_section_info *get_debug_line_section (struct dwarf2_cu *cu); -/* Start a subfile for DWARF. FILENAME is the name of the file and - DIRNAME the name of the source directory which contains FILENAME - or NULL if not known. +/* Start a subfile for FE within CU. + This routine tries to keep line numbers from identical absolute and relative file names in a common subfile. @@ -1432,8 +1431,7 @@ extern struct dwarf2_section_info *get_debug_line_section start_subfile will ensure that this happens provided that we pass the concatenation of files.files[1].dir and files.files[1].name as the subfile's name. */ -extern void dwarf2_start_subfile (dwarf2_cu *cu, const file_entry &fe, - const line_header &lh); +extern void dwarf2_start_subfile (dwarf2_cu &cu, const file_entry &fe); /* A helper function that decides if a given symbol is an Ada Pragma Import or Pragma Export. */ From patchwork Mon Dec 29 16:15:17 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 127204 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id F2F164BA2E21 for ; Mon, 29 Dec 2025 16:18:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F2F164BA2E21 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=GPj2rHm2 X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org 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 DEA1A4BA2E25 for ; Mon, 29 Dec 2025 16:15:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DEA1A4BA2E25 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 DEA1A4BA2E25 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=1767024942; cv=none; b=NbK44zT9sO9Yslqb0lRsVd3V90Rl1u/YTHuNuFbzZ4Rg5ONsm9ebn2R0XNOnnS0X9OE02JexMSY8xfi5LzKtziav9Gl+tUdwJ0Tq5oZgvyOB/V5wcbJj10NAtSvAUILaLGjV04HlKDE+K46MsP63Kw0Juyez5jx38DpfQeANwNQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767024942; c=relaxed/simple; bh=8l2ZAaO61OZRF7JzG0GOQAyhxkvbXDMnk1rqxKN/Imw=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=tk0RNoWb9wT2q3PDjcIoTmnJ7eWjIL9HJ06CKyjAFvdeBCRyfNrb7QmxjbJLJI78TYGGzMhiYv1LJQl7p1L1SfL9ab6MxlHs1M50OaZ4yY+Srkeyd7nbQGIX/evHEGzwgsIqWyg1EI4zLNojttQGnLpEptxeZKseIJdSylqOAPs= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DEA1A4BA2E25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767024936; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jtpB2T38M2uxtgDVDDBk6i3n5zGoV22HJI/4q3CxDW0=; b=GPj2rHm2+xhOcE2sWoXVW5NOx7PalnOWIMzmo8UUPRuc/zzPYScx7W9a+sBziLZvVPkoVg i3YkdJ+NiOg3AxDYlbKO6fvbBmaulv6MxmDCVo6G6c2E3QN+eNnQSLSQXZyQFkAoeL1Mec zbP4zR6F68aslVvJr9vp5d7zO2vkEcc= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-590-8G56ILisO-C-wXwiGNpQ0w-1; Mon, 29 Dec 2025 11:15:35 -0500 X-MC-Unique: 8G56ILisO-C-wXwiGNpQ0w-1 X-Mimecast-MFC-AGG-ID: 8G56ILisO-C-wXwiGNpQ0w_1767024934 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-47d5c7a2f5dso2882975e9.2 for ; Mon, 29 Dec 2025 08:15:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767024933; x=1767629733; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=jtpB2T38M2uxtgDVDDBk6i3n5zGoV22HJI/4q3CxDW0=; b=gf0QL2j8pFsaKqUeUJ81jyZ43PulAIaMHEY/zC4P3wb3lfk1lyTYqe/NN12A/A7H0C ZOc2u6YATbTXPXZNwlvYbjwy8rVqdJ5HV2ZUrSphAXqGjhPBGfmadBQcqt4fcGVpjuZA q1pxZrgfZfP6f/AI7edG6gIU833N+juIIewbXrk8E75d0J6BbnCrZWNVEypAAz37b0+6 An48V03q44V39TXbAkfppKrpWCt0I1xQBbSjXa5XJ3kwkgW/svtPUxTYUA2wfX3yyZY6 JB5h5SDCOWP0v0MMJSN4hnyvLp8K42SU/e9UDmMViO+fcLFlrKQMR1nlnm9GcVYp54pn cf3w== X-Gm-Message-State: AOJu0YzFpV+a3urKds8NV5GoZR3H5T7XMg6zop5AvgApaSqGE+NybKVE 3i83Tj/l/Wl6AkDz+lwUNCPxbhYX7khm7U724OG4b0WSiO0S1nmqV9AHXKfiXuvsosPPBgqIFK5 irq4PxIsoj/Jqe2QKtN9AAt/x99fxlDvibV1CvZ//8n6mtuOrqIoOXWl5ZAVngPr+HNU6LKaRBX nqZSYYI2kySs25s/l2J/USUhCrqsXDfzEuPfzx3XeuOU6SkaE= X-Gm-Gg: AY/fxX5aUh6+TvKmEgcQiBlP3CN3uqu5YKvySmFt6PIhQ/1s4KJr+NzCRteN5+cbkXG PVxHMkUKIqiaxcu2RPeHT3tM9MaTDh4ep+UQLVSQwBPo0u7fVAPtXXpMshmmGoEr4XS+hU5O/GI PgFwXus6RopoDJ0GK1vRJp0Na2PJ3SWp4A6BdETYs1ZhxwyapkAkzrcPdVVjl/0W21Pso4AztJh 9cDsJBq1qmMQ6+UVm8LxFogi96akk4L8e0Y2Tbpirfk5DR1EQaaZFiDLGxXejJyDOXbQeX8HQGI 0OdpFugh1vvdagb8IH2pHrjRGHF82XdoPotRFU+9GkOu30c6eK5bZaNp72Y3o0NW/u1usbeDV2O 0Lew1HxHP2e/oRMdJXQogyqPPwX51iFXboA== X-Received: by 2002:a05:600c:828c:b0:479:3a87:2092 with SMTP id 5b1f17b1804b1-47d19598e86mr276230215e9.36.1767024933310; Mon, 29 Dec 2025 08:15:33 -0800 (PST) X-Google-Smtp-Source: AGHT+IGBz2YqRP9kqCD0Axi5nEpVTfTqtG37g8aVmZhJ94xe9z4DJf97Y7YMdKD41UK/w65m72DrRQ== X-Received: by 2002:a05:600c:828c:b0:479:3a87:2092 with SMTP id 5b1f17b1804b1-47d19598e86mr276229985e9.36.1767024932770; Mon, 29 Dec 2025 08:15:32 -0800 (PST) Received: from localhost (92.40.168.223.threembb.co.uk. [92.40.168.223]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4324ea22674sm64626277f8f.10.2025.12.29.08.15.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Dec 2025 08:15:32 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv4 4/7] gdb/dwarf: move subfile and symtab creation into dwarf2_cu method Date: Mon, 29 Dec 2025 16:15:17 +0000 Message-Id: <7832d2223c87b1712556a9de75cb6c2d1930ffd9.1767024363.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: G_B13NKGI6eSo91rByJTa_792OnlNwmtS9S4WL1S5tU_1767024934 X-Mimecast-Originator: redhat.com content-type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_BLOCKED, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on sourceware.org 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~patchwork=sourceware.org@sourceware.org There are two places in the dwarf2/ code where we create subfiles and symtabs for the entries in a dwarf2_cu's line_header. The code in each location is basically the same. Move this code into a new dwarf2_cu member function. In dwarf2/read.c the existing code had an additional task; this is left in dwarf2/read.c in its own loop immediately after the call to the new member function. There should be no user visible changes after this commit. --- gdb/dwarf2/cu.c | 22 ++++++++++++++++++++++ gdb/dwarf2/cu.h | 3 +++ gdb/dwarf2/line-program.c | 15 +-------------- gdb/dwarf2/read.c | 20 +++----------------- 4 files changed, 29 insertions(+), 31 deletions(-) diff --git a/gdb/dwarf2/cu.c b/gdb/dwarf2/cu.c index 6e5a41e2aec..b4da4dfe248 100644 --- a/gdb/dwarf2/cu.c +++ b/gdb/dwarf2/cu.c @@ -23,6 +23,7 @@ #include "filenames.h" #include "producer.h" #include "gdbsupport/pathstuff.h" +#include "dwarf2/line-header.h" /* Initialize dwarf2_cu to read PER_CU, in the context of PER_OBJFILE. */ @@ -238,3 +239,24 @@ dwarf2_cu::set_producer (const char *producer) m_checked_producer = true; } + +/* See dwarf2/cu.h. */ + +void +dwarf2_cu::create_subfiles_and_symtabs () +{ + buildsym_compunit *builder = this->get_builder (); + compunit_symtab *cust = builder->get_compunit_symtab (); + + for (file_entry &fe : this->line_header->file_names ()) + { + dwarf2_start_subfile (*this, fe); + subfile *sf = builder->get_current_subfile (); + + if (sf->symtab == nullptr) + sf->symtab = allocate_symtab (cust, sf->name.c_str (), + sf->name_for_id.c_str ()); + + fe.symtab = sf->symtab; + } +} diff --git a/gdb/dwarf2/cu.h b/gdb/dwarf2/cu.h index 68010a060cc..d4a5ae65f3c 100644 --- a/gdb/dwarf2/cu.h +++ b/gdb/dwarf2/cu.h @@ -72,6 +72,9 @@ struct dwarf2_cu const char *comp_dir, CORE_ADDR low_pc); + /* Create a subfile and symtab for every entry in the line_header. */ + void create_subfiles_and_symtabs (); + /* Reset the builder. */ void reset_builder () { m_builder.reset (); } diff --git a/gdb/dwarf2/line-program.c b/gdb/dwarf2/line-program.c index 46da4bf5a42..3e4e30fb227 100644 --- a/gdb/dwarf2/line-program.c +++ b/gdb/dwarf2/line-program.c @@ -699,18 +699,5 @@ dwarf_decode_lines (struct dwarf2_cu *cu, unrelocated_addr lowpc, /* Make sure a symtab is created for every file, even files which contain only variables (i.e. no code with associated line numbers). */ - buildsym_compunit *builder = cu->get_builder (); - struct compunit_symtab *cust = builder->get_compunit_symtab (); - - for (file_entry &fe : cu->line_header->file_names ()) - { - dwarf2_start_subfile (*cu, fe); - subfile *sf = builder->get_current_subfile (); - - if (sf->symtab == nullptr) - sf->symtab = allocate_symtab (cust, sf->name.c_str (), - sf->name_for_id.c_str ()); - - fe.symtab = sf->symtab; - } + cu->create_subfiles_and_symtabs (); } diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index f92d9b6eb42..09568c02715 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -6271,27 +6271,13 @@ dwarf2_cu::setup_type_unit_groups (struct die_info *die) = XOBNEWVEC (&cust->objfile ()->objfile_obstack, struct symtab *, line_header->file_names_size ()); + this->create_subfiles_and_symtabs (); + auto &file_names = line_header->file_names (); for (i = 0; i < file_names.size (); ++i) { file_entry &fe = file_names[i]; - dwarf2_start_subfile (*this, fe); - buildsym_compunit *b = get_builder (); - subfile *sf = b->get_current_subfile (); - - if (sf->symtab == nullptr) - { - /* NOTE: start_subfile will recognize when it's been - passed a file it has already seen. So we can't - assume there's a simple mapping from - cu->line_header->file_names to subfiles, plus - cu->line_header->file_names may contain dups. */ - const char *name = sf->name.c_str (); - const char *name_for_id = sf->name_for_id.c_str (); - sf->symtab = allocate_symtab (cust, name, name_for_id); - } - - fe.symtab = b->get_current_subfile ()->symtab; + gdb_assert (fe.symtab != nullptr); tug_unshare->symtabs[i] = fe.symtab; } } From patchwork Mon Dec 29 16:15:18 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 127203 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 7AA534BA2E04 for ; Mon, 29 Dec 2025 16:18:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7AA534BA2E04 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=XPy9/uT1 X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org 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 45CD14BA2E2F for ; Mon, 29 Dec 2025 16:15:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 45CD14BA2E2F 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 45CD14BA2E2F 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=1767024942; cv=none; b=H8cJ5lY5XDuQWTr4CRe/ER1TRoAA+h6kFa2bfE8CnO9UZ6Sxb1/LUi0AIdd6PhXyjguMiIqi5JKlvHf2RnkZeTeGiSV18IrQdTv2MpmXMPeH1BZX8yVyf2GbYnw0c3E2xkeyeJy95dOSfCPrluz8sj0hfB14BbK+lfgtbtgz/qo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767024942; c=relaxed/simple; bh=AmFLF7VrnLMYNsm2c26VgXI8iQJTxRkwTcT9ix38//M=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=AwOcCY7Z9g1obMAxaVIv1KVgWG6N/IZxrBL+bRY/IynouGfLenqxg7LJSsl5KqaRVyZbGSk10wRNAojCNImmwhB4bq9xu8SW98Z9+jwHWtzTwPP9FsClP94WwBxualdbl6eQ/5OfdcG/pZkROs1on4cqNGe2RPO/zmdLKeGESnw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 45CD14BA2E2F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767024937; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=m2XYBcPSTEq+uQxyEtZL14O8a+hcbI30chi9VPOuRVE=; b=XPy9/uT1Ltay7MbWHWuUAbU/SFonCZ98RjZbQX2RbHpEDz6xtAR6/Oy09gpMgSCAK306x2 YIXLzMjwQ58kBMCdVN3VtR03a3WzoPw/HxFcUvs8vSCa5qfltr7b0xdgvdsyN9kyMfQhZf wSOdrcwdDi8UlIMUejqpJZUhHgdunQE= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-449-Zgky48v-NjCZTjYsMSmmHg-1; Mon, 29 Dec 2025 11:15:36 -0500 X-MC-Unique: Zgky48v-NjCZTjYsMSmmHg-1 X-Mimecast-MFC-AGG-ID: Zgky48v-NjCZTjYsMSmmHg_1767024935 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4775f51ce36so85347935e9.1 for ; Mon, 29 Dec 2025 08:15:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767024935; x=1767629735; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=m2XYBcPSTEq+uQxyEtZL14O8a+hcbI30chi9VPOuRVE=; b=OUSMgA660Z0irUsfi05VPuKZPwGaiIS6aL8D2uIsKlE3+ysJCjmn74iPEw44HBcoMu wth5yp+D1BPMASuCr+0QZ2UgyB3AHGSy6KWpO3+YSxpU086EIgEt1A9iR9rUWy+0poVg rdfbl+nD0vmSX05OXwx+0V4yLqKb5gT8Xim8F83owog6MPpWh+9vpfqNZso0r4vvif7o rnUlPoKbc6lYZFwXV7iz2CkuRxEblmft6zyqbJZHkiVxzpuL8ZuxncXeqKDy7Zh7OkiN BOeHyG24g3XJpkIkeC1fydZXgQwzTBu01nd33u4TZ91XCnQEYlf71m0dtWJZ8iYsofYQ RN/g== X-Gm-Message-State: AOJu0Yys1mCYMLEVDObm6nImRqsl10Gs1K5YZ22wa2akcrHHeQGa2NJk QjbBeGBvG2H6gV9TyCi5kzqGsV+gxXTjJlZFqo4vNx+qAAibV0Y/1siZPBdFBJEUfGrlfouyKtS 22svDHTTyMJZmq8sFJsIUOJzB/czI44C2+7QXARwSER7IP67k3seYMXU3E/yEMabRrALsGweEbj lLAT/KhM6YuSOL5tW0HwcgnOVfQ5kPHwdjAUy6pD4pgcnIBJo= X-Gm-Gg: AY/fxX6Xct7Nrqm2C2jR4SRQtV/l9SQewTfFfkV6kFycoZNGVgB/ZTMygaj9MiKouAm gvESsQJC8n8QqeyVbac4uynVvOmdDpqCiiqCxRUPDx13D7OW9NNMgWkD9N2W0pvMmSGGlvIgHc1 nd0RYh65mnAS7fyeLchKBAl/+ey7NFScvVfbMPxh9bHZvQyZ7DNG4uqiHDJZgi7ETDEhdVkk9ql 57MntakKSrvCVnk5Ic7Zg1IRMvdiZdXOaXEGirkWCXiX1kdxaj1pdqe8XkxdYx5MoX1UKJaMdzv 0ZqXJ4SwlELTlYJN6z8tjR34waZB9oDTlO8TT2tGY2mKvw4VJZwUZaQvRFe2anFcMxEzQ9jONqB 2LSMP+N0BK6lOOimQOBAfu1+05NUSHCAyGA== X-Received: by 2002:a05:600c:3584:b0:46e:59bd:f7d3 with SMTP id 5b1f17b1804b1-47d195a724bmr400685745e9.20.1767024934798; Mon, 29 Dec 2025 08:15:34 -0800 (PST) X-Google-Smtp-Source: AGHT+IF6YuD7RlqFjZmwWwyUK1SPju/6Gax66X47TxgqRz3gL/7OpCyeVLn7nlrYggd+ayEs+PUTFA== X-Received: by 2002:a05:600c:3584:b0:46e:59bd:f7d3 with SMTP id 5b1f17b1804b1-47d195a724bmr400685315e9.20.1767024934317; Mon, 29 Dec 2025 08:15:34 -0800 (PST) Received: from localhost (92.40.168.223.threembb.co.uk. [92.40.168.223]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47be3a49315sm251832375e9.2.2025.12.29.08.15.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Dec 2025 08:15:33 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv4 5/7] gdb/dwarf: rename dwarf2_start_subfile to dwarf2_cu::start_subfile Date: Mon, 29 Dec 2025 16:15:18 +0000 Message-Id: <66d978fa035c1b674dc895eaa63b8c5db6651672.1767024363.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: FAQXzgyk88-MWtKtkTHvYBf9i8H3W1igixd5MgPacCo_1767024935 X-Mimecast-Originator: redhat.com content-type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, POISEN_SPAM_PILL, POISEN_SPAM_PILL_1, POISEN_SPAM_PILL_3, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on sourceware.org 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~patchwork=sourceware.org@sourceware.org Rename dwarf2_start_subfile to dwarf2_cu::start_subfile. This refactor continues the work started in the previous commit. There should be no user visible changes after this commit. --- gdb/dwarf2/cu.c | 29 ++++++++++++++++++++++++++++- gdb/dwarf2/cu.h | 4 ++++ gdb/dwarf2/line-program.c | 4 ++-- gdb/dwarf2/read.c | 26 -------------------------- gdb/dwarf2/read.h | 23 ----------------------- 5 files changed, 34 insertions(+), 52 deletions(-) diff --git a/gdb/dwarf2/cu.c b/gdb/dwarf2/cu.c index b4da4dfe248..eb27dc2ff1b 100644 --- a/gdb/dwarf2/cu.c +++ b/gdb/dwarf2/cu.c @@ -250,7 +250,7 @@ dwarf2_cu::create_subfiles_and_symtabs () for (file_entry &fe : this->line_header->file_names ()) { - dwarf2_start_subfile (*this, fe); + this->start_subfile (fe); subfile *sf = builder->get_current_subfile (); if (sf->symtab == nullptr) @@ -260,3 +260,30 @@ dwarf2_cu::create_subfiles_and_symtabs () fe.symtab = sf->symtab; } } + +/* See dwarf2/cu.h. */ + +void +dwarf2_cu::start_subfile (const file_entry &fe) +{ + std::string filename_holder; + const char *filename = fe.name; + const char *dirname = this->line_header->include_dir_at (fe.d_index); + + /* In order not to lose the line information directory, + we concatenate it to the filename when it makes sense. + Note that the Dwarf3 standard says (speaking of filenames in line + information): ``The directory index is ignored for file names + that represent full path names''. Thus ignoring dirname in the + `else' branch below isn't an issue. */ + + if (!IS_ABSOLUTE_PATH (filename) && dirname != NULL) + { + filename_holder = path_join (dirname, filename); + filename = filename_holder.c_str (); + } + + std::string filename_for_id = this->line_header->file_file_name (fe); + this->get_builder ()->start_subfile (filename, filename_for_id.c_str ()); +} + diff --git a/gdb/dwarf2/cu.h b/gdb/dwarf2/cu.h index d4a5ae65f3c..0fd64425e32 100644 --- a/gdb/dwarf2/cu.h +++ b/gdb/dwarf2/cu.h @@ -26,6 +26,7 @@ #include "language.h" #include "gdbsupport/unordered_set.h" #include "dwarf2/die.h" +#include "line-header.h" /* Type used for delaying computation of method physnames. See comments for compute_delayed_physnames. */ @@ -75,6 +76,9 @@ struct dwarf2_cu /* Create a subfile and symtab for every entry in the line_header. */ void create_subfiles_and_symtabs (); + /* Start a subfile for FE within this CU. */ + void start_subfile (const file_entry &fe); + /* Reset the builder. */ void reset_builder () { m_builder.reset (); } diff --git a/gdb/dwarf2/line-program.c b/gdb/dwarf2/line-program.c index 3e4e30fb227..2fc5c283c00 100644 --- a/gdb/dwarf2/line-program.c +++ b/gdb/dwarf2/line-program.c @@ -244,7 +244,7 @@ lnp_state_machine::handle_set_file (file_name_index file) else { m_line_has_non_zero_discriminator = m_discriminator != 0; - dwarf2_start_subfile (*m_cu, *fe); + m_cu->start_subfile (*fe); } } @@ -507,7 +507,7 @@ dwarf_decode_lines_1 (struct dwarf2_cu *cu, unrelocated_addr lowpc) const file_entry *fe = state_machine.current_file (); if (fe != NULL) - dwarf2_start_subfile (*cu, *fe); + cu->start_subfile (*fe); /* Decode the table. */ while (line_ptr < line_end && !end_sequence) diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 09568c02715..2c15deb0454 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -15976,32 +15976,6 @@ dwarf_decode_line_header (sect_offset sect_off, struct dwarf2_cu *cu, comp_dir); } -/* See dwarf2/read.h. */ - -void -dwarf2_start_subfile (dwarf2_cu &cu, const file_entry &fe) -{ - std::string filename_holder; - const char *filename = fe.name; - const char *dirname = cu.line_header->include_dir_at (fe.d_index); - - /* In order not to lose the line information directory, - we concatenate it to the filename when it makes sense. - Note that the Dwarf3 standard says (speaking of filenames in line - information): ``The directory index is ignored for file names - that represent full path names''. Thus ignoring dirname in the - `else' branch below isn't an issue. */ - - if (!IS_ABSOLUTE_PATH (filename) && dirname != NULL) - { - filename_holder = path_join (dirname, filename); - filename = filename_holder.c_str (); - } - - std::string filename_for_id = cu.line_header->file_file_name (fe); - cu.get_builder ()->start_subfile (filename, filename_for_id.c_str ()); -} - static void var_decode_location (struct attribute *attr, struct symbol *sym, struct dwarf2_cu *cu) diff --git a/gdb/dwarf2/read.h b/gdb/dwarf2/read.h index 4ae2236466f..e00383ce2e8 100644 --- a/gdb/dwarf2/read.h +++ b/gdb/dwarf2/read.h @@ -1410,29 +1410,6 @@ extern const dwarf2_section_info &get_section_for_ref extern struct dwarf2_section_info *get_debug_line_section (struct dwarf2_cu *cu); -/* Start a subfile for FE within CU. - - This routine tries to keep line numbers from identical absolute and - relative file names in a common subfile. - - Using the `list' example from the GDB testsuite, which resides in - /srcdir and compiling it with Irix6.2 cc in /compdir using a filename - of /srcdir/list0.c yields the following debugging information for list0.c: - - DW_AT_name: /srcdir/list0.c - DW_AT_comp_dir: /compdir - files.files[0].name: list0.h - files.files[0].dir: /srcdir - files.files[1].name: list0.c - files.files[1].dir: /srcdir - - The line number information for list0.c has to end up in a single - subfile, so that `break /srcdir/list0.c:1' works as expected. - start_subfile will ensure that this happens provided that we pass the - concatenation of files.files[1].dir and files.files[1].name as the - subfile's name. */ -extern void dwarf2_start_subfile (dwarf2_cu &cu, const file_entry &fe); - /* A helper function that decides if a given symbol is an Ada Pragma Import or Pragma Export. */ From patchwork Mon Dec 29 16:15:19 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 127202 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 3B6374BA2E2C for ; Mon, 29 Dec 2025 16:18:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3B6374BA2E2C 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=MVKFNJoA X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org 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 41FC74BA2E2B for ; Mon, 29 Dec 2025 16:15:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 41FC74BA2E2B 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 41FC74BA2E2B 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=1767024942; cv=none; b=uDvoNU5hrwIhexosd8HrleBwF274XuHVvCrUVR5t+7I7eTARUsX/Qa9N3gKBMeb/PbtIla9ZA9H1AnYbfaQrOxz/6NtpbGJ1rmuTya4AOu97b79LqJ9JZnA9SEMkAMBtpOVlohdzVD7ZD0xttEaqcE5GVKARAAbk/cs7zoyR+CE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767024942; c=relaxed/simple; bh=oxY1K272vbgvx2uIhAzG0G2xM7ALEwBTC/zosHLS7XY=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=El5N9YmgQW+j+HmYB/o50wXhLXSqYfNDjLo7jcYxznTLNoqWNHKzdAomX54u+nBCo6JkXIRzP5KdWaZCCWHaDx6BTiTeuMIzNGA6mMyIK0lKUxeHi4hs+pCKx0yDPiGx6hYCBi8kCThREaqjy6VhyYFAkocfDYRguB8EFLaUYcE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 41FC74BA2E2B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767024941; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0Ywg6t3zpknWEy5AHe06Rv8l4BTuiJC9v19uIUAjshA=; b=MVKFNJoA3NZLRKGKjgcWvVSabzdr/dvgtzkxn0i+SsHYWEA3Ei6cz+QyjkB+t1h3MDn4T/ cb1M2Mun/Nt8HTmrnurRF+BzIcSIJtTU/p8okwIWS7W8ZjrB2gdDTJCpN0sQtya6fxgdqi 4x2fk42tIM8xUn/vSfGABKQD0YcdFKo= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-668-hST-SEXBOz6ts3y3RCbF0A-1; Mon, 29 Dec 2025 11:15:40 -0500 X-MC-Unique: hST-SEXBOz6ts3y3RCbF0A-1 X-Mimecast-MFC-AGG-ID: hST-SEXBOz6ts3y3RCbF0A_1767024939 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-477563e531cso61318725e9.1 for ; Mon, 29 Dec 2025 08:15:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767024938; x=1767629738; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=0Ywg6t3zpknWEy5AHe06Rv8l4BTuiJC9v19uIUAjshA=; b=cM4PVamHSxiB0VnDGcmnyb0PqEWxvgaFao/PqPTPwe3fBSI8FTkO2A1hUMjbm/Hrs1 PkMZmRE0GVUm8QnH1oMxEiL6w9vwKZcZwIeVTu3J4H5Xeq4f3KiGG2FQmEIGBkHkSlXf rr5U9J7qLHTOwMqUwPKuTXobJQ5Kfwow8zGbVfu7zydY2Amj4yDIWeKo1KsF+NAmFrCt RVquqlTvUP5/ec7+PaQ1bJN2FqQGvbqTNl2WyXT9pPFsT9xXQG8UuIFP0ddIWc/sln3o 1qGj4TWEfuOCmeBM1EpeugI52OE9R0yhC/DHlOoUxMxqvIR5a6KpjqCNiCLUI+jzYJVh tgEw== X-Gm-Message-State: AOJu0Yze6AYAuofkcjmhUicNZTGE45Sv6kNVMohqzL9FvAaKQxy5TMqo xDSbCdSb4DP/s+pU3wICgmAoM6LI+7YRRwxZYz4Qxh3KX9Xx03wfQhy5RetffE8jWpSOHE7AtBc UFCTtFOSi3DUbrDZOEky1YKEGwudJuOjQbrtMIPGkwDJcVYhmCeE0ahwNScPcqvGpG2lvnZc7L/ PtzSm3DsMUzUjufm9PIxvGLX27/S5JttBCQ1vDOgjZQz7fYwA= X-Gm-Gg: AY/fxX4Qh7pKVWBenP4I+K8KduCz6QqL9DWZyO8SkX11nnKUk5fq+FR1exJi3zVMMtd j0g8m7gRRhO/aK6sQ4RrKeL8gdyTTRjqMW77H4t+2zMEbmUmtp2u1EGNCqG6Ov/+GpXK3nIKYai 76Q91NdcxLlFoxz1gIoWqV6yV4Mi0NCvOQxZEMSO62UvjtRGzPhTlGnPJHIDeQxPNwqGJz0JChA VCAUcjOLw52+kM57Kq+mCrxuaSVOzAc4mp2XikT7FJEEBFC6gpp0zwMpWEY0L+yzMmSW282J9bK LHqYqDemtGIfjbK4UyKF7W9qxseLIcb9r7i6L2GHmoXPIYdNI+TEsDzTAnEO3dAyKjF699vBtle RjTDICVEqUGebiB13VvyVcmxhgle/8+maYA== X-Received: by 2002:a05:600c:46d1:b0:47a:8088:439c with SMTP id 5b1f17b1804b1-47d1959d6a0mr368486355e9.35.1767024937551; Mon, 29 Dec 2025 08:15:37 -0800 (PST) X-Google-Smtp-Source: AGHT+IHKsBkH5F+h5Nn0TjCfg/YyFyTGF5vJDwv4mu1vZjecwYu+HKj+LfDGPWtWFbQqgLZcpA0Rkg== X-Received: by 2002:a05:600c:46d1:b0:47a:8088:439c with SMTP id 5b1f17b1804b1-47d1959d6a0mr368485075e9.35.1767024936143; Mon, 29 Dec 2025 08:15:36 -0800 (PST) Received: from localhost (92.40.168.223.threembb.co.uk. [92.40.168.223]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47be27b749esm602216355e9.14.2025.12.29.08.15.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Dec 2025 08:15:35 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv4 6/7] gdb: test for misplaced symtab causing file not found error Date: Mon, 29 Dec 2025 16:15:19 +0000 Message-Id: <3ce8b2dfd53527dc348daf3d43e6b3197b657906.1767024363.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: CpHfH68eYGjs0Hv0rj4xAsc3wCVS2hRG7zcPaLi-J8I_1767024939 X-Mimecast-Originator: redhat.com content-type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_BLOCKED, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on sourceware.org 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~patchwork=sourceware.org@sourceware.org This patch adds a new test that checks for a bug that was, if not fixed, then at least, worked around, by commit: commit a736ff7d886dbcc85026264c3ce11c125a8409b2 Date: Sat Sep 27 22:29:24 2025 -0600 Clean up iterate_over_symtabs The bug was reported against Fedora GDB which, at the time the bug was reported, is based off GDB 16, and so doesn't include the above commit. The bug report can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=2403580 To summarise the bug report: a user is inspecting an application backtrace. The original bug report was from a core file, but the same issue will trigger for a live inferior. It's the inspection of the stack frames which is important. The user moves up the stack with the 'up' command and eventually finds an interesting frame. They use 'list' to view the source code at the current location, this works and displays lines 6461 to 6470 from the source file '../glib/gmain.c'. The user then does 'list 6450' to try and display some earlier lines from the same source file, at which point GDB gives the message: warning: 6445 ../glib/gmain.c: No such file or directory So GDB initially manages to find the source file, but for the very next command, GDB now claims that the source file doesn't exist. As I said, commit a736ff7d886d appears to fix this issue, but it wasn't clear to me (from the commit message) if this commit was intended to fix any bugs, or if the bug was being hidden by this commit. I've spent some time trying to understand what's going on, and have come up with this test case. I think there might still be an issue in GDB, but I do think that the above commit really is making it so that the issue (if it is an issue) doesn't occur in that particular situation any more, so I think we can consider the above commit a fix, and testing for this bug is worth while to ensure it doesn't get reintroduced. In order to trigger this bug we need these high level requirements: 1. Multiple shared libraries compiled from the same source tree. In this case it was glib, but the test in this commit uses a much smaller library. 2. Common DWARF must be pulled from the libraries using the 'dwz' tool. 3. Debuginfod must be in use for at least downloading the source code. In the original bug, and in the test presented here, debuginfod is used for fetching both the debug info, and the source code for the library. There are some additional specific requirements for the DWARF in order to trigger the bug, but to make discussing this easier, lets look at the structure of the test presented here. When discussing the source files I'll drop the solib-with-dwz- prefix, e.g. when I mention 'foo.c' I really mean 'solib-with-dwz-foo.c'. There are three shared libraries built for this test, libbar.so, libfoo.so, and libfoo-2.so. The source file bar.c is used to create libbar.so, and foo.c is used to create libfoo.so and libfoo-2.so. The main test executable is built from main.c, and links against libbar.so and libfoo.so. libfoo-2.so is not used by the main executable, and just exists to trigger some desired behaviour from the dwz tool. The debug information for each shared library is extracted into a corresponding .debug file, and the dwz tool is used to extract common debug from the three .debug files into a file called 'common.dwz'. Given all this then, in order to trigger the bug, the following additional requirements must be met: 4. libbar.so must NOT make use of foo.c. In this test libbar.so is built from bar.c (and some headers) only. 5. A reference to foo.c must be placed into common.dwz. This is why libfoo-2.so exists, as this library is almost identical to libfoo.so, there is lots of shared DWARF between libfoo.so and libfoo-2.so which can be moved into common.dwz, this shared DWARF includes references to foo.c, so an entry for foo.c is added to the file table list in common.dwz. 6. There must be a DWARF construct within libbar.so.debug that references common.dwz, and which causes GDB to parse the line table from within common.dwz. For more details on this, see below. 7. We need libbar.so to appear before libfoo.so in GDB's comunit_symtab lists. This means that GDB will scan the symtabs for libbar.so before checking the symtabs of libfoo.so. I achieve this by mentioning libbar.so first when building the executable, but this is definitely the most fragile part of the test. To satisfy requirement (6) the inline function 'add_some_int' is added to the test. This function appears in both libbar.so and libfoo.so, this means that the DW_TAG_subprogram representing the abstract instance tree will be moved into common.dwz. However, as this is an inline function, the DW_TAG_inlined_subroutine DIEs for each concrete instance, will be left in libbar.so.debug and libfoo.so.debug, with a DW_AT_abstract_origin that points into common.dwz. When GDB parses libbar.so.debug it finds the DW_TAG_inlined_subroutine and begins processing it. It sees the DW_AT_abstract_origin and so jumps into common.dwz to read the DIEs that define the inline function. Here is the DWARF from libbar.so.debug for the inlined instance: <2><91>: Abbrev Number: 3 (DW_TAG_inlined_subroutine) <92> DW_AT_abstract_origin: <96> DW_AT_low_pc : 0x1121 <9e> DW_AT_high_pc : 31 <9f> DW_AT_call_file : 1 DW_AT_call_line : 26 DW_AT_call_column : 15 <3>: Abbrev Number: 5 (DW_TAG_formal_parameter) DW_AT_abstract_origin: DW_AT_location : 2 byte block: 91 68 (DW_OP_fbreg: -24) <3>: Abbrev Number: 5 (DW_TAG_formal_parameter) DW_AT_abstract_origin: DW_AT_location : 2 byte block: 91 6c (DW_OP_fbreg: -20) And here's the DWARF from common.dwz for the abstract instance tree: <1><1b>: Abbrev Number: 7 (DW_TAG_subprogram) <1c> DW_AT_name : (indirect string, offset: 0x18a): add_some_int <20> DW_AT_decl_file : 1 <21> DW_AT_decl_line : 24 <22> DW_AT_decl_column : 1 <23> DW_AT_prototyped : 1 <23> DW_AT_type : <0x14> <24> DW_AT_inline : 3 (declared as inline and inlined) <2><25>: Abbrev Number: 8 (DW_TAG_formal_parameter) <26> DW_AT_name : a <28> DW_AT_decl_file : 1 <29> DW_AT_decl_line : 24 <2a> DW_AT_decl_column : 19 <2b> DW_AT_type : <0x14> <2><2c>: Abbrev Number: 8 (DW_TAG_formal_parameter) <2d> DW_AT_name : b <2f> DW_AT_decl_file : 1 <30> DW_AT_decl_line : 24 <31> DW_AT_decl_column : 26 <32> DW_AT_type : <0x14> While processing the common.dwz DIEs GDB sees the DW_AT_decl_file attributes, and this triggers a read of the file table within common.dwz, which creates symtabs for any files mentioned, if the symtabs don't already exist. But, and this is the important bit, when doing this, GDB is creating a compunit_symtab for libbar.so.debug, so any symtabs created will be attached to the libbar.so.debug objfile. Remember requirement (5), the file list in common.dwz mentions 'foo.c', so even though libbar.so doesn't use 'foo.c' we end up with a symtab for 'foo.c' created within the compunit_symtab for libbar.so.debug! I don't think this is ideal. This wastes memory and time; we have more symtabs to search through even if, as I'll discuss below, we usually end up ignoring these symtabs. The exact path that triggers this weird symtab creation starts with a call to 'new_symbol' (dwarf2/read.c) for the DW_TAG_formal_parameter in the abstract instance tree. These include DW_AT_decl_file, which is read in 'new_symbol'. In 'new_symbol' GDB spots that the line_header has not yet been read in, so handle_DW_AT_stmt_list is called which reads the file/line table and then calls 'dwarf_decode_lines' (line_program.c), which then creates symtabs for all the files mentioned. This symtab creation issue still exists today in GDB, though I've not been able to find any real issues that this is causing after commit a736ff7d886d fixed the issue I'm discussing here. So, having tricked GDB into creating a misplaced symtab, what problem did this cause prior to commit a736ff7d886d? To answer this, we need to take a diversion to understand how a command like 'list 6450' works. The two interesting functions are create_sals_line_offset and decode_digits_list_mode, which is called from the former. The create_sals_line_offset is called indirectly from list_command via the initial call to decode_line_1. In create_sals_line_offset, if the incoming linespec doesn't specify a specific symtab, then GDB uses the name of the default symtab to lookup every symtab with a matching name, this is done with the line: ls->file_symtabs = collect_symtabs_from_filename (self->default_symtab->filename (), self->search_pspace); In our case, when the default symtab is 'foo.c', this is going to return multiple symtabs, these will include the correct 'foo.c' symtab from libfoo.so, but will also include the misplaced 'foo.c' symtab from libbar.so. This is where the ordering is important. As list will only ever list one file, at a later point in this process we're going to toss out everything except the first result. So, to trigger the bug, it is critical that the FIRST result returned here be the misplaced 'foo.c' symtab from libbar.so. In the test I try to ensure this by mentioning libbar.so before libfoo.so when building the executable, which currently means we get back the misplaced symtab first, but this could change in the future and wouldn't necessarily mean that the problem has gone away. Having got the symtab list GDB then calls decode_digits_list_mode which iterates over the symtabs and converts them into symtab_and_line objects, at the heart of which is a call to find_line_symtab, which checks if a given symtab has a line table entry for the desired line. If it does then the symtab is returned. If it doesn't then GDB looks for another symtab with the same name that does have a line table entry. If no suitably named symtab has an exact match, then the symtab with the closest line above the required line is returned. If no symtab has a matching line table entry then find_line_symtab returns NULL. Remember, the misplaced symtab was only created as a side effect of trying to attach the DW_TAG_formal_parameter symbol to a symtab. The actual line table for libbar.so (in libbar.so.debug) has no line table entries for 'foo.c'. What this means is that the line table for 'foo.c' attached to libbar.so.debug is empty. So normally what happens is that find_line_symtab will instead find a line table entry for 'foo.c' in libfoo.so.debug that does have a suitable line table entry, and will switch GDB back to that symtab, effectively avoiding the problem. However, that is not what happens in the bug case. In the bug case find_line_symtab returns NULL, which means that decode_digits_list_mode just uses the original symtab, in this case the symtab for 'foo.c' from libbar.so.debug. In the original bug, the code is compiled with -O2, and this optimisation has left the line table covering the problem file pretty sparse. In fact, there are no line table entries for any line after the line that the user is trying to list. This is why find_line_symtab doesn't find a better alternative symtab, and instead just returns NULL. In the test I've replicated this by having a comment at the end of the source file, and asking GDB to list a line within this comment. The result is that there are no line table entries for that line in any 'foo.c' symtab, and so find_line_symtab returns NULL. After decode_digits_list_mode sees the NULL from find_line_symtab, it just uses the initial symtab. After this we eventually return back to list_command (cli/cli-cmds.c) with a list of symtab_and_line objects. The first entry in this list is for the symtab 'foo.c' from libbar.so. In list_command we call filter_sals which throws away everything but the first entry as all the symtabs have the same filename (and are in the same program space). Using the symtab we build an absolute path to the source file. Now, if the source is installed locally, GDB performs no additional checks; we found a symtab, the symtab gave us a source filename, if the source file exists on disk, then the requires lines are listed for the user. But if the source file doesn't exist on disk, then we are going to ask debuginfod for the source file. To do that we use two pieces of information; the absolute path to the source file, which we have; and the build-id of an objfile, this is the objfile that owns the symtab we are trying to get the source for. In this case libbar.so. And so we send the build-id and filename to debuginfod. Now debuginfod isn't going to just serve any file to anyone, that would be a security issue for the server. Instead, debuginfod scans the DWARF and builds up its own model of which objfiles use which source files, and for a given build-id, debuginfod will only serve back files that the objfile matching that build-id, actually uses. So, in this case, when we ask for 'foo.c' from libbar.so, debuginfod correctly realises the 'foo.c' is not part of libbar.so, and refuses to send the file back. And this is how the original bug occurred. So, why does commit a736ff7d886d fix this problem? The answer is in iterate_over_symtabs, which is used by collect_symtabs_from_filename to find the matching symtabs. Prior to this commit, iterate_over_symtabs had two phases, first a call to iterate_over_some_symtabs which walks over compunit_symtabs that already exist looking for matches, during this phase only the symtab filenames are considered. The second phase uses objfile::map_symtabs_matching_filename to look through the objfiles and expand new symtabs that match the required name. In our case, by the time iterate_over_symtabs is called, all of the interesting symtabs have already been expanded, so we only perform the filename check in iterate_over_some_symtabs, this passes, and so 'foo.c' from libbar.so is considered a suitable symtab. After commit a736ff7d886d the initial call to iterate_over_some_symtabs has been removed from iterate_over_symtabs, and only the objfile::map_symtabs_matching_filename call remains. This ends up in cooked_index_functions::search (dwarf2/read.c) to search for matching symtabs. The first think cooked_index_functions::search does is setup a vector of CUs to skip by calling dw_search_file_matcher, this then calls dw2_get_file_names to get the file and line table for a CU, this function in turn creates a cutu_reader object, passing true for the 'skip_partial' argument to its constructor. As our 'foo.c' symtab was created from within the dwz extracted DWARF, then it is associated with the DW_TAG_partial_unit that held the DW_TAG_subprogram DIEs that were being processed when the misplaced symtab was original created; this is a partial unit. As this is a partial unit, and the skip_partial flag was passed true, the cutu_reader::is_dummy function will return true. Back in dw2_get_file_names, if cutu_reader::is_dummy is true then dw2_get_file_names_reader is never called, and the file names are never read. This means that back in dw_search_file_matcher, the file data, returned from dw2_get_file_names is NULL, and so this CU is marked to be skipped. Which is exactly what we want, this misplaced symtab, which was created for a partial unit and associated with libbar.so, is skipped and never considered as a possible match. There is a remaining problem, which is marked in the test with an xfail. That is, when the test does the 'list LINENO', GDB still tries to download the source for 'foo.c' from libbar.so. The reason for this is that, while it is true that the initial collect_symtabs_from_filename call no longer returns 'foo.c' from libbar.so, when decode_digits_list_mode calls find_line_symtab for the correct 'foo.c' from libfoo.so, it is still the case that there is no exact match for LINENO in that symtabs line table. As a result, GDB looks through all the other symtabs for 'foo.c' to see if any are a better match. Checking if another symtab is a possible better match requires a full comparison of the symtabs source file name, which in this case triggers an attempt to download the source file from debuginfod. Here's the backtrace at the time of the rogue source download request, which appears as an xfail in the test presented here: #0 debuginfod_source_query (build_id=..., build_id_len=..., srcpath=..., destname=...) at ../../src/gdb/debuginfod-support.c:332 #1 0x0000000000f0bb3b in open_source_file (s=...) at ../../src/gdb/source.c:1152 #2 0x0000000000f0be42 in symtab_to_fullname (s=...) at ../../src/gdb/source.c:1214 #3 0x0000000000f6dc40 in find_line_symtab (sym_tab=..., line=..., index=...) at ../../src/gdb/symtab.c:3314 #4 0x0000000000aea319 in decode_digits_list_mode (self=..., ls=..., line=...) at ../../src/gdb/linespec.c:3939 #5 0x0000000000ae4684 in create_sals_line_offset (self=..., ls=...) at ../../src/gdb/linespec.c:2039 #6 0x0000000000ae557f in convert_linespec_to_sals (state=..., ls=...) at ../../src/gdb/linespec.c:2289 #7 0x0000000000ae6546 in parse_linespec (parser=..., arg=..., match_type=...) at ../../src/gdb/linespec.c:2647 #8 0x0000000000ae7605 in location_spec_to_sals (parser=..., locspec=...) at ../../src/gdb/linespec.c:3045 #9 0x0000000000ae7c7f in decode_line_1 (locspec=..., flags=..., search_pspace=..., default_symtab=..., default_line=...) at ../../src.dev-m/gdb/linespec.c:3167 I think that this might not be what we really want to do here. After downloading the source file we'll end up with a filename within the debuginfod download cache, which will be different for each objfile (the cache partitions downloads based on build-id). So if two symtabs originate from the same source file, but are in two different objfiles, then, when the source is on disk, the filenames for these symtabs will be identical, and the symtabs will be considered equivalent by find_line_symtab. But when debuginfod is downloading the source the source paths will be different, and find_line_symtab will consider the symtabs different. This doesn't seem right to me. But I'm going to leave worrying about that for another day. Given this last bug, I am of the opinion that the misplaced symtab is likely a bug, though after commit a736ff7d886d, the only issue I can find is the extra debuginfod download request, which isn't huge. But still, maybe just reducing the number of symtabs would be worth it? But this patch isn't about fixing any bugs, it's about adding a test case for an issue that was a problem, but isn't any longer. --- .../gdb.debuginfod/solib-with-dwz-bar.c | 36 ++ .../gdb.debuginfod/solib-with-dwz-bar.h | 25 ++ .../gdb.debuginfod/solib-with-dwz-common.h | 32 ++ .../gdb.debuginfod/solib-with-dwz-foo.c | 79 ++++ .../gdb.debuginfod/solib-with-dwz-foo.h | 27 ++ .../gdb.debuginfod/solib-with-dwz-main.c | 34 ++ .../gdb.debuginfod/solib-with-dwz.exp | 344 ++++++++++++++++++ gdb/testsuite/lib/gdb.exp | 34 ++ 8 files changed, 611 insertions(+) create mode 100644 gdb/testsuite/gdb.debuginfod/solib-with-dwz-bar.c create mode 100644 gdb/testsuite/gdb.debuginfod/solib-with-dwz-bar.h create mode 100644 gdb/testsuite/gdb.debuginfod/solib-with-dwz-common.h create mode 100644 gdb/testsuite/gdb.debuginfod/solib-with-dwz-foo.c create mode 100644 gdb/testsuite/gdb.debuginfod/solib-with-dwz-foo.h create mode 100644 gdb/testsuite/gdb.debuginfod/solib-with-dwz-main.c create mode 100644 gdb/testsuite/gdb.debuginfod/solib-with-dwz.exp diff --git a/gdb/testsuite/gdb.debuginfod/solib-with-dwz-bar.c b/gdb/testsuite/gdb.debuginfod/solib-with-dwz-bar.c new file mode 100644 index 00000000000..bd70ff52458 --- /dev/null +++ b/gdb/testsuite/gdb.debuginfod/solib-with-dwz-bar.c @@ -0,0 +1,36 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2025 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +#include "solib-with-dwz-bar.h" +#include "solib-with-dwz-common.h" + +static int bar_data = 0; + +void +process_bar_data (int value) +{ + bar_data += add_some_int (3, value); + +} + +volatile int *ptr = 0; + +void bar_func (void) +{ + /* This will hopefully trigger a segfault. */ + *ptr = 0; /* Crash here. */ +} diff --git a/gdb/testsuite/gdb.debuginfod/solib-with-dwz-bar.h b/gdb/testsuite/gdb.debuginfod/solib-with-dwz-bar.h new file mode 100644 index 00000000000..d7b014bc90a --- /dev/null +++ b/gdb/testsuite/gdb.debuginfod/solib-with-dwz-bar.h @@ -0,0 +1,25 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2025 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +#ifndef SOLIB_WITH_DWZ_BAR_H +#define SOLIB_WITH_DWZ_BAR_H + +extern void process_bar_data (int value); + +extern void bar_func (void); + +#endif /* SOLIB_WITH_DWZ_BAR_H */ diff --git a/gdb/testsuite/gdb.debuginfod/solib-with-dwz-common.h b/gdb/testsuite/gdb.debuginfod/solib-with-dwz-common.h new file mode 100644 index 00000000000..653d5d497c3 --- /dev/null +++ b/gdb/testsuite/gdb.debuginfod/solib-with-dwz-common.h @@ -0,0 +1,32 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2025 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +#ifndef SOLIB_WITH_DWZ_COMMON_H +#define SOLIB_WITH_DWZ_COMMON_H + +void breakpt (int a, int b); + +static inline int __attribute__((always_inline)) +add_some_int (int a, int b) +{ + if (a > b) + breakpt (a, b); + + return a + b; +} + +#endif /* SOLIB_WITH_DWZ_COMMON_H */ diff --git a/gdb/testsuite/gdb.debuginfod/solib-with-dwz-foo.c b/gdb/testsuite/gdb.debuginfod/solib-with-dwz-foo.c new file mode 100644 index 00000000000..145a2e29c86 --- /dev/null +++ b/gdb/testsuite/gdb.debuginfod/solib-with-dwz-foo.c @@ -0,0 +1,79 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2025 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +#include "solib-with-dwz-foo.h" +#include "solib-with-dwz-common.h" + +struct foo_data_type +{ + int positive_value; + int negative_value; +}; + +static struct foo_data_type foo_data; + +void +do_callback (foo_callback_type cb) +{ + cb (); /* Call line. */ +} + +void +process_foo_data (int input) +{ +#ifdef FOO2 + int other_value = 4; +#else + int other_value = 6; +#endif + + if (input > 0) + foo_data.positive_value += add_some_int (input, other_value); + else + foo_data.negative_value += add_some_int (other_value, input); +} + +/* This comment must appear at the end of the source file with no compiled + code after it. When looking for a line number LINENO, GDB looks for a + symtab with a line table entry for LINENO or a later line. It is + important for this test that there be no suitable line table entry. The + numbers have no real meaning, I just want to ensure that the 'XXX' line, + which is what the test lists is far from any previous source listing. + + 0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + XXX: Second line to list. + 10 + 9 + 8 + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 */ diff --git a/gdb/testsuite/gdb.debuginfod/solib-with-dwz-foo.h b/gdb/testsuite/gdb.debuginfod/solib-with-dwz-foo.h new file mode 100644 index 00000000000..65eb58ae28c --- /dev/null +++ b/gdb/testsuite/gdb.debuginfod/solib-with-dwz-foo.h @@ -0,0 +1,27 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2025 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +#ifndef SOLIB_WITH_DWZ_FOO_H +#define SOLIB_WITH_DWZ_FOO_H + +extern void process_foo_data (int value); + +typedef void (*foo_callback_type) (void); + +extern void do_callback (foo_callback_type cb); + +#endif /* SOLIB_WITH_DWZ_FOO_H */ diff --git a/gdb/testsuite/gdb.debuginfod/solib-with-dwz-main.c b/gdb/testsuite/gdb.debuginfod/solib-with-dwz-main.c new file mode 100644 index 00000000000..10214a7e40a --- /dev/null +++ b/gdb/testsuite/gdb.debuginfod/solib-with-dwz-main.c @@ -0,0 +1,34 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2025 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +#include "solib-with-dwz-foo.h" +#include "solib-with-dwz-bar.h" + +void +breakpt (int a, int b) +{ + (void) a; + (void) b; +} + +int +main (void) +{ + do_callback (bar_func); + + return 0; +} diff --git a/gdb/testsuite/gdb.debuginfod/solib-with-dwz.exp b/gdb/testsuite/gdb.debuginfod/solib-with-dwz.exp new file mode 100644 index 00000000000..d30707d5433 --- /dev/null +++ b/gdb/testsuite/gdb.debuginfod/solib-with-dwz.exp @@ -0,0 +1,344 @@ +# Copyright 2025 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . */ + +# This test covers a bug where GDB would try to list source lines from an +# invalid symtab, and as a result would print a message saying that the +# source file doesn't exist. +# +# Three shared libraries are compiled and their debug information is split +# into separate .debug files. Common debug is then extracted using the +# 'dwz' tool. +# +# There are a few critical things required for the bug to manifest: +# +# 1. 'foo.c' must be mentioned in the dwz extracted common debug. To +# achieve this two versions of libfoo are compiled with a small +# difference. +# +# 2. 'foo.c' must NOT be used by libbar. This is why two copies of libfoo +# are created alongside libbar. +# +# 3. There must be a DWARF construct in libbar which causes the line table +# of the 'dwz' extracted DWARF to be read within the context of parsing +# libbar. In this case we have the 'add_some_int' inlined function that +# is used in libbar and libfoo, as such the DW_TAG_subprogram is placed +# into the 'dwz' extracted DWARF, but there is a +# DW_TAG_inlined_subroutine in the DWARF for both libfoo and libbar. The +# DW_AT_abstract_origin for the inlined subroutine points to the 'dwz' +# extracted DWARF file. +# +# What happens then is that when GDB interprets the DW_TAG_inlined_subroutine, +# it goes off to find the DW_AT_abstract_origin, which is in the 'dwz' +# extracted DWARF. +# +# While processing the DW_AT_abstract_origin GDB parses the line table from +# the 'dwz' extracted DWARF, and creates symtabs (if not exist already). +# +# As the 'dwz' extracted DWARF mentions 'foo.c' in its line table, then GDB +# ends up creating a symtab in libbar, for 'foo.c'. +# +# This used to be a problem as GDB could end up trying to use this symtab +# when listing source code. This isn't normally an issue as the symtab for +# 'foo.c' within libbar, though misplaced, is identical to the symtab for +# 'foo.c' that exists within libfoo. As such, when GDB computes the source +# path for either, the same full source path is computed, GDB will then read +# the same file on disk. +# +# However, if debuginfod is involved, then the source lookup has an extra +# check. To fetch the source from debuginfod GDB must supply the source +# filename AND the build-id for the original objfile, in our problematic +# case this ends up being the build-id for libbar. +# +# As 'foo.c' is not a source file that is part of libbar, debuginfod refuses +# to send this source file back, and claims the file doesn't exist. GDB +# would then say that the source file couldn't be found. +# +# However, changes in GDB means that this problem no longer exists. When +# looking for a source file by name, symtabs that are created for a +# DW_TAG_partial_unit are ignored, at least in the places we care about. As +# a result, GDB now ignores the symtab for 'foo.c' that is created within +# libbar. +# +# There is one remaining issue though, which this test does expose. While +# searching the symtabs, GDB will still trigger an attempt to download the +# source code for 'foo.c' within libbar, even if, later on, GDB decides that +# the symtab should be ignore on account of it being a DW_TAG_partial_unit. +# This source code download is unfortunate as to the user it appears like a +# second (unnecessary) download of the file. There's an XFAIL in this test +# related to this issue. + +load_lib debuginfod-support.exp + +require allow_shlib_tests +require {istarget "*-linux*"} +require {!is_remote host} +require {dwz_version_at_least 0.13} + +standard_testfile -main.c -bar.c -foo.c + +set libbar_filename [standard_output_file "libbar.so"] +set libfoo_filename [standard_output_file "libfoo.so"] +set libfoo_2_filename [standard_output_file "libfoo-2.so"] + +# Compile libbar.so. +if {[build_executable "build libbar.so" $libbar_filename \ + $srcfile2 { debug shlib build-id }] == -1} { + return +} + +# If we are running with a board that splits the debug information out and +# adds a .gnu_debuglink, then this test isn't going to work. We want to be +# in control of splitting out the debug information, and we definitely don't +# want a .gnu_debuglink otherwise debuginfod isn't going to be needed. +if {[section_get $libbar_filename ".gnu_debuglink"] ne ""} { + unsupported "debug information has already been split out" + return +} + +# Compile libfoo.so. +if {[build_executable "build libfoo.so" $libfoo_filename \ + $srcfile3 { debug shlib build-id }] == -1} { + return +} + +# Compile libfoo-2.so. +if {[build_executable "build libfoo-2.so" $libfoo_2_filename \ + $srcfile3 { debug shlib build-id additional_flags=-DFOO2}] == -1} { + return +} + +# Build the executable. +if { [build_executable "build executable" ${binfile} ${srcfile} \ + [list debug shlib=${libbar_filename} shlib=${libfoo_filename} shlib_load]] == -1 } { + return +} + +# For each library file, move the debug information into a .debug +# file. Don't add the gnu-debuglink from the library to the debug +# file yet as the generated CRC depends on the debug information in +# the .debug file, and in the next step we will change that debug +# information using the DWZ tool. +foreach filename [list $libbar_filename $libfoo_filename $libfoo_2_filename] { + if {[gdb_gnu_strip_debug $filename no-debuglink]} { + unsupported "produce separate debug info for [file tail $filename]" + return + } +} + +# Move the .debug files into the debug/ directory. +set debug_dir [standard_output_file "debug"] +remote_exec build "mkdir \"$debug_dir\"" +remote_exec build "mv \"${libbar_filename}.debug\" \"${debug_dir}/\"" +remote_exec build "mv \"${libfoo_filename}.debug\" \"${debug_dir}/\"" +remote_exec build "mv \"${libfoo_2_filename}.debug\" \"${debug_dir}/\"" + +# Run DWZ tool on the separate debug files. This moves shared debug +# information into a 'common.dwz' file. First move into DEBUG_DIR +# then run DWZ using relative filenames, this means that the link +# placed into the *.debug files will be relative, and GDB will not be +# able to find the common.dwz file itself; as a result it will have to +# download the file via debuginfod. +with_cwd $debug_dir { + set status \ + [remote_exec build "dwz -m ./common.dwz \ + ./libbar.so.debug \ + ./libfoo.so.debug \ + ./libfoo-2.so.debug"] + if {[lindex $status 0] != 0} { + unsupported "unable to run dwz tool" + return + } +} + +# Some earlier versions of dwz would fail to process the .debug files, +# producing some error output, but still exit with code 0. A +# successful execution of dwz should produce no output. +if {[lindex $status 1] ne ""} { + unsupported "unexpected output from dwz tool" + return +} + +# Check the debuginfod client cache directory CACHE, look in the directory +# corresponding to libbar.so, and check to see if the *-foo.c source file, +# global SRCFILE3, was downloaded. Return true if the file was downloaded, +# otherwise, return false. +proc check_cache_for_foo { cache } { + set build_id [get_build_id $::libbar_filename] + set cache_dir $cache/$build_id + set files [glob -nocomplain -tails -directory $cache_dir \*$::srcfile3] + if { [llength $files] > 0 } { + return true + } + return false +} + +# Use DB and DEBUG_DIR to start debuginfod, then start GDB. Configure GDB +# so that it cannot find the test source code; we'll download this from +# debuginfod. Load the test executable and run until it crashes. Move up +# the stack until we're in libfoo.so, specifically, in the file +# solib-with-dwz-foo.c, then use 'list', this displays source lines around +# the current location, and sets the default symtab within GDB. The source +# will have been downloaded from debuginfod. +# +# Now use 'list LINENO', this should display LINENO within the default +# symtab. +proc run_test { cache db debug_dir use_filename } { + set url [start_debuginfod $db $debug_dir] + if { $url == "" } { + unresolved "start debuginfod server" + return + } + + # Point the client to the server. + setenv DEBUGINFOD_URLS $url + + clean_restart + + # Set the substitute-path, this prevents GDB from reading the + # source code directly from the file system. + gdb_test_no_output "set substitute-path $::srcdir /dev/null" \ + "set substitute-path" + + # And remove SRCDIR from the source directory path, this prevents + # GDB from reading the source files relative to this location. + gdb_test "with confirm off -- dir" \ + "^Source directories searched: \\\$cdir:\\\$cwd" \ + "reset source directory path" + + # Turn on support for debuginfod. + gdb_test_no_output "set debuginfod enabled on" \ + "enabled debuginfod for initial test" + + # Now GDB is configured, load the executable. + gdb_load $::binfile + + if { ![runto_main] } { + return + } + + # This test relies on reading address zero triggering a SIGSEGV. + # If address zero is readable then give up now. + if { [is_address_zero_readable] } { + unsupported "address zero in readable" + return + } + + set crash_line_num [gdb_get_line_number "Crash here" $::srcfile2] + + gdb_test "continue" \ + "\r\n$crash_line_num\\s+[string_to_regexp {*ptr = 0; /* Crash here. */}]" + + set call_line_num [gdb_get_line_number "Call line" $::srcfile3] + + gdb_test "up" \ + "\r\n$call_line_num\\s+[string_to_regexp {cb (); /* Call line. */}]" + + gdb_test "list" \ + "\r\n$call_line_num\\s+[string_to_regexp {cb (); /* Call line. */}]\r\n.*" \ + "list default location in $::srcfile3" + + set list_line_num [gdb_get_line_number "Second line to list" $::srcfile3] + + # Try 'list LINENO' or 'list FILE:LINENO'. GDB will perform a search + # for the current symtab or the symtab matching FILE, and could end up + # finding the wrong symtab, resulting in a file not found message + # instead of the source code being printed. + + if { $use_filename } { + set filename_prefix "${::srcfile3}:" + } else { + set filename_prefix "" + } + + set saw_missing_source_warning false + set saw_source_download false + set saw_expected_source_line false + gdb_test_multiple "list $filename_prefix$list_line_num" "list by line number in $::srcfile3" { + -re "^list $filename_prefix$list_line_num\r\n" { + exp_continue + } + -re "^Downloading source file \[^\r\n\]+\r\n" { + set saw_source_download true + exp_continue + } + -re "^warning:\\s+$::decimal\\s+\[^\r\n\]+: No such file or directory\r\n" { + set saw_missing_source_warning true + exp_continue + } + -re "^$list_line_num\\s+[string_to_regexp {XXX: Second line to list.}]\r\n" { + set saw_expected_source_line true + exp_continue + } + -re "^$::gdb_prompt $" { + # If the source download reply from debuginfod is very quick, + # then debuginfod might not even print a line indicating that + # anything was downloaded. If we get here an still think that + # the source wasn't downloaded, then check the cache, just to + # confirm. + if { !$saw_source_download } { + set saw_source_download [check_cache_for_foo $cache] + } + + # GDB ends up creating a symtab for solib-with-dwz-foo.c + # associated with libbar.so. This isn't ideal as *-foo.c wasn't + # used within libbar.so. The symtab is a result of loading the + # file/line table from the DWZ file while processing the DWARF + # for libbar.so. + # + # While performing the 'list LINENO' or 'list FILE:LINENO' + # command GDB performs a search of all symtabs, as part of this + # process GDB tries to establish the full source filename for + # the *-foo.c symtab associated with libbar.so, this in turn + # causes GDB to try and download the source from debuginfod. + # + # This download will fail as *-foo.c is not used within + # libbar.so, but having GDB try to download the file is not + # ideal, even if it is harmless. + # + # If/when this xfail is addressed, the comment at the start of + # this file will need updating too. + setup_xfail "*-*-*" + gdb_assert { !$saw_source_download } \ + "$gdb_test_name, no source download" + + gdb_assert { $saw_expected_source_line \ + && !$saw_missing_source_warning } \ + "$gdb_test_name, saw source line" + } + -re "^\[^\r\n\]*\r\n" { + exp_continue + } + } +} + +# Create CACHE and DB directories ready for debuginfod to use. +prepare_for_debuginfod cache db + +with_debuginfod_env $cache { + foreach_with_prefix use_filename { true false } { + + # Cleanup state the will be created in run_test. Do this before the + # call to make debugging the test easier; the state remains after + # calling run_test. + unset -nocomplain env(DEBUGINFOD_URLS) + file delete -force $cache + file delete -force $db + + # Now run the test. + run_test $cache $db $debug_dir $use_filename + stop_debuginfod + } +} + diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index f7d9b61fec0..bdd90feef15 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -11780,5 +11780,39 @@ gdb_caching_proc have_startup_shell {} { return $supported } +# Return the version number of the 'dwz' tool as a list. If the 'dwz' +# tool is not found, or the version cannot be established, an empty +# list is returned. +# +# The 'dwz' version is currently of the form 0.12, 0.13, 0.14, etc. +# So the returned list will have two elements, e.g. { 0 12 }. + +proc dwz_version { } { + set dwz_program "dwz" + set res [catch {exec $dwz_program --version} output] + + # Don't check the exit value of 'dwz' process as 'dwz' doesn't + # exit immediately after displaying the version number, and for + # some reason, version 0.13 always seems to exit with a code of 1. + # The version number is still displayed though. + + set lines [split $output \n] + set line [lindex $lines 0] + set res [regexp {dwz version[ \t]+([0-9]+)[.]([0-9]+)[^ \t]*$} \ + $line dummy dwz_major dwz_minor] + if { $res != 1 } { + return [list] + } + + return [list $dwz_major $dwz_minor] +} + +# Return true if the version of the 'dwz' tool is at least VER. The +# VER should have the same form as a 'dwz' version number, e.g. 0.12, +# 0.13, 0.14, etc. +proc dwz_version_at_least { ver } { + return [version_compare [split $ver .] <= [dwz_version]] +} + # Always load compatibility stuff. load_lib future.exp From patchwork Mon Dec 29 16:15:20 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 127206 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id C597F4BA2E2E for ; Mon, 29 Dec 2025 16:19:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C597F4BA2E2E 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=DuXRtnKs X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org 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 00B654BA23C4 for ; Mon, 29 Dec 2025 16:15:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 00B654BA23C4 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 00B654BA23C4 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=1767024943; cv=none; b=rGDBVF7gEB38NXEZxMdBONb3XLBdDNMbhlPSaEh57dWfqVwGDru7G/BYfsvAXSqMQo5ZgHk6ghCyx+NGdXU7ljhHQ8QVwxPzdDI33cPWvKTWi5tyxvcAcr4I+8oygE+OS+l0guD2BKSRIbdwdTU34+Qt4CHQzQAywFDC0DeCjdQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767024943; c=relaxed/simple; bh=nLVaJAHVJx2iICaStr2/+znWMs8+Cj75k4QCOPL+fI4=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=EDRM6qmL9+Yf+OO4TGO2jPZbE9ZCV+8z2U9pRelkrNxZ1LM0O152VwwpSPAnBgJYA2YXhnbmwaMwLTiOOJ44gMtBFOdtnqB1zosrvKE0dApzsg8G0vzqURuzxBx0p0x+7Ol5dLT55CiLSKSJlNGVbE9iViJg901ze20Q2A4wJ98= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 00B654BA23C4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767024942; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lDGaU3w7lqsSHmGLSX6B/N80Xb1Ad4XkPsefLEgUG4s=; b=DuXRtnKsAxJIhmam8tMMSS1qhT1DvF/ejrAGRQhRtR0uKduSJW80IcWqEXU8xWEql5aewr EHVn6nlIFCn185lOf8LypVU8gPHlN7f5Z+wcNdD/Vyhx42JiBnMyXJxsVTPJGqpDSMqOUg aGLicBuIZGLkR2DEZFLCsPqIXbm81YQ= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-622-ALR2Csh9M7yH25It4zqisA-1; Mon, 29 Dec 2025 11:15:41 -0500 X-MC-Unique: ALR2Csh9M7yH25It4zqisA-1 X-Mimecast-MFC-AGG-ID: ALR2Csh9M7yH25It4zqisA_1767024940 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-477563a0c75so26570355e9.1 for ; Mon, 29 Dec 2025 08:15:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767024939; x=1767629739; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=lDGaU3w7lqsSHmGLSX6B/N80Xb1Ad4XkPsefLEgUG4s=; b=cvHLiIRJHtv+XbK2/h6KPUw0MbyiNerr9XOti7u+mf+t5bD2aIgaxMrmlNBz4jf8HH nF2NKYRhtSgazB1WtFeMv45zalsNNSA8liLqHjD5YoBIr36fcGgC1vP+PLYdTmhLDq4Q 5lCne70PYGKGpG2p2hJ94/pcpE3TsfWP/INOxchlxzhK1Stmtzhr+Buw4N6NhREKxhSO m8kjbavk/Bsza7k2Y7uDZgiIB7HGCefsC+pkU19vUw/K/2ijW/PSM3p8GwWGvR1wT9tU tc5AJOK/rfQvS67YpC89sSbKx80EhTGFA0boIJfyIEf80dtEWbewhhlJj2P7YkD3DGuO HmLA== X-Gm-Message-State: AOJu0YyCBMLdOfjiYaF0/mZtaAG/Yshdiy6eTAd0pcMU/klQY0KDGrDz P6ZD8qj9cv+d8BbR31dCzsBESZpgcuf9LcbLj3phgAreA1jevkQtFJ84bTqRxGNltcdTYjOQ4R8 GgLwR3QnPcPth6rcrnjdIML3uZElrsnc2Tklv4F4Wt4fmjMhVXJu3wP/ZpL9GJLMUXxZAnQsT2d Uav/5N8+8DY93wLyuUkGDExVNMqcKoQmEbVsf/YWh4Jq1n+/4= X-Gm-Gg: AY/fxX4byINfrgzriivSUz1QNnPto38E/emdxhpAQ8TZSoKD6mYJ46lm9gVeWzF23CM v/gjAS/c1D1XbZmPN1VdcKJ3l+hWs5YzFAc5ub9ZbiFeHZi0HT1Spg4ZKfaaAtfd+h6bPp68C2H NMke2EKfVz3D6ssZwR/G8ei/iTb5E8IMWsMyg6uf/T51MMsPd3VCZqTQyRJvzdqXCEQH1VWZlzG /eyJZGUhW5KX14K5EUQoPUmK19/X3Gq11pjLQzFjmXVMwY+Zq8vnmHb7W+WK6zM2ZrdnxAtVics 1PcMSTzdAUOq5Dw+27VaKTCaes7bbUoc2gN/iOzTUFVkmRRsMc6PAmDF3BvSwzdEkvIB5jnkQ5n xRrYXqQRMLywvybivQpWBmXvhkHj1vvYJfA== X-Received: by 2002:a05:600c:1d0b:b0:479:2a0b:180d with SMTP id 5b1f17b1804b1-47d1954a5f7mr357406625e9.11.1767024938816; Mon, 29 Dec 2025 08:15:38 -0800 (PST) X-Google-Smtp-Source: AGHT+IFgjrysqv4W57X34DnXUmUZThlOvUcsWvXuL1I9y7zJpz9JFi5LGwc4SRAizX+X28sUQeigUw== X-Received: by 2002:a05:600c:1d0b:b0:479:2a0b:180d with SMTP id 5b1f17b1804b1-47d1954a5f7mr357405665e9.11.1767024937758; Mon, 29 Dec 2025 08:15:37 -0800 (PST) Received: from localhost (92.40.168.223.threembb.co.uk. [92.40.168.223]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d19346d33sm557683345e9.3.2025.12.29.08.15.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Dec 2025 08:15:37 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv4 7/7] gdb: avoid creating misplaced symtabs for dwz files Date: Mon, 29 Dec 2025 16:15:20 +0000 Message-Id: X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ElLV7GAXlORNdNk25agoM6di3yn1DQnaGw_-N3dzRw8_1767024940 X-Mimecast-Originator: redhat.com content-type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_BLOCKED, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on sourceware.org 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~patchwork=sourceware.org@sourceware.org This commit fixes the issue that is described in detail in the previous commit; when processing a DWZ file, GDB can end up creating a symtab associated with a compunit_symtab for a file that was never compiled into a given compunit_symtab. The previous commit added a test for this issue, however, things are slightly complicated because a recent change to GDB: commit a736ff7d886dbcc85026264c3ce11c125a8409b2 Date: Sat Sep 27 22:29:24 2025 -0600 Clean up iterate_over_symtabs Changed GDB in such a way that the problem being discussed here no longer appears to cause any incorrect behaviour. Still, I think this problem is worth fixing. Adding additional symtabs that are in the wrong place has the potential to cause problems in the future, but also, wastes GDB memory, and increases time needed to search through all symtabs. The precise problem here is triggered when a DWZ file is created from multiple object files (as is usually the case). The DWZ file will contain a line table which can hold references to any of the source files, from any of the object files. Note that a source file doesn't have to be included in every object file in order to be added to the line table of the DWZ file. Within GDB the problem originates from the 'new_symbol' function (in dwarf2/read.c). This function looks for the DW_AT_call_file or DW_AT_decl_file of a symbol, uses this to lookup the line table entry, and uses this to obtain the symtab to which the symbol should be attached. For an inlined subroutine instance, this information can be split between an objfile's debug information and a shared DWZ file. For example, from the gdb.debuginfod/solib-with-dwz.exp test case, this first bit of DWARF is from the objfile's debug information: <2><91>: Abbrev Number: 3 (DW_TAG_inlined_subroutine) <92> DW_AT_abstract_origin: <96> DW_AT_low_pc : 0x1121 <9e> DW_AT_high_pc : 31 <9f> DW_AT_call_file : 1 DW_AT_call_line : 26 DW_AT_call_column : 15 <3>: Abbrev Number: 5 (DW_TAG_formal_parameter) DW_AT_abstract_origin: DW_AT_location : 2 byte block: 91 68 (DW_OP_fbreg: -24) <3>: Abbrev Number: 5 (DW_TAG_formal_parameter) DW_AT_abstract_origin: DW_AT_location : 2 byte block: 91 6c (DW_OP_fbreg: -20) The DW_AT_abstract_origin attributes are referencing the following DWARF which has been placed into the DWZ file: <1><1b>: Abbrev Number: 7 (DW_TAG_subprogram) <1c> DW_AT_name : (indirect string, offset: 0x18a): add_some_int <20> DW_AT_decl_file : 1 <21> DW_AT_decl_line : 24 <22> DW_AT_decl_column : 1 <23> DW_AT_prototyped : 1 <23> DW_AT_type : <0x14> <24> DW_AT_inline : 3 (declared as inline and inlined) <2><25>: Abbrev Number: 8 (DW_TAG_formal_parameter) <26> DW_AT_name : a <28> DW_AT_decl_file : 1 <29> DW_AT_decl_line : 24 <2a> DW_AT_decl_column : 19 <2b> DW_AT_type : <0x14> <2><2c>: Abbrev Number: 8 (DW_TAG_formal_parameter) <2d> DW_AT_name : b <2f> DW_AT_decl_file : 1 <30> DW_AT_decl_line : 24 <31> DW_AT_decl_column : 26 <32> DW_AT_type : <0x14> When GDB tries to create the symbols for the DW_TAG_formal_parameter then this will find the DW_AT_decl_line in the DWZ file. This will cause the line table of the DWZ file to be parsed. This parsing currently creates symtabs for every file mentioned in the DWZ file's line table, which includes files that are not part of the original objfile. Currently GDB creates and stores the symtabs within the file_entry object (see dwarf2/line-header.h). I propose that we make the symtab creation lazy; when the symtab is requested from a file_entry object, the symtab will be created at this point. Doing this will cause another problem though. In dwarf_decode_lines, we specifically create all of the symtabs so that there will be a symtab even for files that contain no code. We don't want to regress this case. The solution is that dwarf_decode_lines will still trigger the symtab creation (by asking the file_entries for their symtab), unless we're processing a DWZ file. We don't need to worry about files that have no code, which are mentioned in a DWZ file, as these files will also be mentioned in the original objfile's line table. When that line table is processed (as it will be), then symtabs for all files mentioned will be created. In this way we will get: (a) symtabs for every source file mentioned in the original objfile, and (b) symtabs for every source file that is specifically used by the DWARF from the DWZ file. I've update the gdb.debuginfod/solib-with-dwz.exp test to check the symtab creation, and also added gdb.base/dwz-symtabs.exp, which is very similar to solib-with-dwz.exp, but doesn't depend on debuginfod and instead just focuses on which symtabs are created, this make the test a little simpler overall. --- gdb/dwarf2/cu.c | 13 +- gdb/dwarf2/line-header.c | 23 +++ gdb/dwarf2/line-header.h | 13 +- gdb/dwarf2/line-program.c | 19 +- gdb/dwarf2/read.c | 10 +- gdb/testsuite/gdb.base/dwz-symtabs-bar.c | 36 ++++ gdb/testsuite/gdb.base/dwz-symtabs-bar.h | 25 +++ gdb/testsuite/gdb.base/dwz-symtabs-common.h | 32 +++ gdb/testsuite/gdb.base/dwz-symtabs-foo.c | 79 ++++++++ gdb/testsuite/gdb.base/dwz-symtabs-foo.h | 27 +++ gdb/testsuite/gdb.base/dwz-symtabs-main.c | 34 ++++ gdb/testsuite/gdb.base/dwz-symtabs.exp | 188 ++++++++++++++++++ .../gdb.debuginfod/solib-with-dwz.exp | 74 +++++-- 13 files changed, 532 insertions(+), 41 deletions(-) create mode 100644 gdb/testsuite/gdb.base/dwz-symtabs-bar.c create mode 100644 gdb/testsuite/gdb.base/dwz-symtabs-bar.h create mode 100644 gdb/testsuite/gdb.base/dwz-symtabs-common.h create mode 100644 gdb/testsuite/gdb.base/dwz-symtabs-foo.c create mode 100644 gdb/testsuite/gdb.base/dwz-symtabs-foo.h create mode 100644 gdb/testsuite/gdb.base/dwz-symtabs-main.c create mode 100644 gdb/testsuite/gdb.base/dwz-symtabs.exp diff --git a/gdb/dwarf2/cu.c b/gdb/dwarf2/cu.c index eb27dc2ff1b..03e909f3c82 100644 --- a/gdb/dwarf2/cu.c +++ b/gdb/dwarf2/cu.c @@ -245,19 +245,10 @@ dwarf2_cu::set_producer (const char *producer) void dwarf2_cu::create_subfiles_and_symtabs () { - buildsym_compunit *builder = this->get_builder (); - compunit_symtab *cust = builder->get_compunit_symtab (); - for (file_entry &fe : this->line_header->file_names ()) { - this->start_subfile (fe); - subfile *sf = builder->get_current_subfile (); - - if (sf->symtab == nullptr) - sf->symtab = allocate_symtab (cust, sf->name.c_str (), - sf->name_for_id.c_str ()); - - fe.symtab = sf->symtab; + struct symtab *symtab = fe.symtab (*this); + gdb_assert (symtab != nullptr); } } diff --git a/gdb/dwarf2/line-header.c b/gdb/dwarf2/line-header.c index d2cd06c4a3b..dae67a247b0 100644 --- a/gdb/dwarf2/line-header.c +++ b/gdb/dwarf2/line-header.c @@ -421,3 +421,26 @@ dwarf_decode_line_header (sect_offset sect_off, bool is_dwz, return lh; } + +/* See dwarf2/line-header.h. */ + +struct symtab * +file_entry::symtab (dwarf2_cu &cu) +{ + if (m_symtab == nullptr) + { + buildsym_compunit *builder = cu.get_builder (); + compunit_symtab *cust = builder->get_compunit_symtab (); + + cu.start_subfile (*this); + + subfile *sf = builder->get_current_subfile (); + if (sf->symtab == nullptr) + sf->symtab = allocate_symtab (cust, sf->name.c_str (), + sf->name_for_id.c_str ()); + + m_symtab = sf->symtab; + } + + return m_symtab; +} diff --git a/gdb/dwarf2/line-header.h b/gdb/dwarf2/line-header.h index e6f9ea9f2d4..b4427a0e4ad 100644 --- a/gdb/dwarf2/line-header.h +++ b/gdb/dwarf2/line-header.h @@ -23,6 +23,7 @@ #include "dwarf2/types.h" struct dwarf2_per_objfile; +struct dwarf2_cu; /* dir_index is 1-based in DWARF 4 and before, and is 0-based in DWARF 5 and later. */ @@ -65,8 +66,18 @@ struct file_entry unsigned int length {}; + /* Get the symtab for this file_entry. If no symtab has yet been created + or set (see set_symtab) for this file_entry then a new one will be + created. */ + struct symtab *symtab (struct dwarf2_cu &cu); + + /* Set the symtab for this file_entry. */ + void set_symtab (struct symtab *s) + { m_symtab = s; } + +private: /* The associated symbol table, if any. */ - struct symtab *symtab {}; + struct symtab *m_symtab {}; }; /* The line number information for a compilation unit (found in the diff --git a/gdb/dwarf2/line-program.c b/gdb/dwarf2/line-program.c index 2fc5c283c00..0dfbb360660 100644 --- a/gdb/dwarf2/line-program.c +++ b/gdb/dwarf2/line-program.c @@ -696,8 +696,19 @@ dwarf_decode_lines (struct dwarf2_cu *cu, unrelocated_addr lowpc, if (decode_mapping) dwarf_decode_lines_1 (cu, lowpc); - /* Make sure a symtab is created for every file, even files - which contain only variables (i.e. no code with associated - line numbers). */ - cu->create_subfiles_and_symtabs (); + /* For non DWZ CUs, make sure a symtab is created for every file, even + files which contain only variables (i.e. no code with associated line + numbers). + + For DWZ CUs the line table can contain references to files that are no + part of the original CU. In fact, if multiple object files were used + to create the DWZ file (as is normal), then the DWZ CU's line table + can contain references to files that are in objfiles that are not part + of the current inferior. For DWZ we rely on lazy symtab creation. In + the end we should still end up with a symtab for every file as the + original CU (the non-DWZ CU) will still contain a line table, and that + line table will mention every file, so when that is processed we'll + create symtabs as needed. */ + if (!cu->per_cu->is_dwz ()) + cu->create_subfiles_and_symtabs (); } diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 2c15deb0454..8adf3f59906 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -6277,8 +6277,8 @@ dwarf2_cu::setup_type_unit_groups (struct die_info *die) for (i = 0; i < file_names.size (); ++i) { file_entry &fe = file_names[i]; - gdb_assert (fe.symtab != nullptr); - tug_unshare->symtabs[i] = fe.symtab; + gdb_assert (fe.symtab (*this) != nullptr); + tug_unshare->symtabs[i] = fe.symtab (*this); } } else @@ -6296,7 +6296,7 @@ dwarf2_cu::setup_type_unit_groups (struct die_info *die) for (i = 0; i < file_names.size (); ++i) { file_entry &fe = file_names[i]; - fe.symtab = tug_unshare->symtabs[i]; + fe.set_symtab (tug_unshare->symtabs[i]); } } @@ -11646,7 +11646,7 @@ process_structure_scope (struct die_info *die, struct dwarf2_cu *cu) { /* Any related symtab will do. */ symtab - = cu->line_header->file_names ()[0].symtab; + = cu->line_header->file_names ()[0].symtab (*cu); } else { @@ -16201,7 +16201,7 @@ new_symbol (struct die_info *die, struct type *type, struct dwarf2_cu *cu, if (fe == NULL) complaint (_("file index out of range")); else - sym->set_symtab (fe->symtab); + sym->set_symtab (fe->symtab (*file_cu)); } } diff --git a/gdb/testsuite/gdb.base/dwz-symtabs-bar.c b/gdb/testsuite/gdb.base/dwz-symtabs-bar.c new file mode 100644 index 00000000000..aef10a0456d --- /dev/null +++ b/gdb/testsuite/gdb.base/dwz-symtabs-bar.c @@ -0,0 +1,36 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2025 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +#include "dwz-symtabs-bar.h" +#include "dwz-symtabs-common.h" + +static int bar_data = 0; + +void +process_bar_data (int value) +{ + bar_data += add_some_int (3, value); + +} + +volatile int *ptr = 0; + +void bar_func (void) +{ + /* This will hopefully trigger a segfault. */ + *ptr = 0; /* Crash here. */ +} diff --git a/gdb/testsuite/gdb.base/dwz-symtabs-bar.h b/gdb/testsuite/gdb.base/dwz-symtabs-bar.h new file mode 100644 index 00000000000..d7b014bc90a --- /dev/null +++ b/gdb/testsuite/gdb.base/dwz-symtabs-bar.h @@ -0,0 +1,25 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2025 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +#ifndef SOLIB_WITH_DWZ_BAR_H +#define SOLIB_WITH_DWZ_BAR_H + +extern void process_bar_data (int value); + +extern void bar_func (void); + +#endif /* SOLIB_WITH_DWZ_BAR_H */ diff --git a/gdb/testsuite/gdb.base/dwz-symtabs-common.h b/gdb/testsuite/gdb.base/dwz-symtabs-common.h new file mode 100644 index 00000000000..653d5d497c3 --- /dev/null +++ b/gdb/testsuite/gdb.base/dwz-symtabs-common.h @@ -0,0 +1,32 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2025 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +#ifndef SOLIB_WITH_DWZ_COMMON_H +#define SOLIB_WITH_DWZ_COMMON_H + +void breakpt (int a, int b); + +static inline int __attribute__((always_inline)) +add_some_int (int a, int b) +{ + if (a > b) + breakpt (a, b); + + return a + b; +} + +#endif /* SOLIB_WITH_DWZ_COMMON_H */ diff --git a/gdb/testsuite/gdb.base/dwz-symtabs-foo.c b/gdb/testsuite/gdb.base/dwz-symtabs-foo.c new file mode 100644 index 00000000000..0fdd9ce0dd6 --- /dev/null +++ b/gdb/testsuite/gdb.base/dwz-symtabs-foo.c @@ -0,0 +1,79 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2025 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +#include "dwz-symtabs-foo.h" +#include "dwz-symtabs-common.h" + +struct foo_data_type +{ + int positive_value; + int negative_value; +}; + +static struct foo_data_type foo_data; + +void +do_callback (foo_callback_type cb) +{ + cb (); /* Call line. */ +} + +void +process_foo_data (int input) +{ +#ifdef FOO2 + int other_value = 4; +#else + int other_value = 6; +#endif + + if (input > 0) + foo_data.positive_value += add_some_int (input, other_value); + else + foo_data.negative_value += add_some_int (other_value, input); +} + +/* This comment must appear at the end of the source file with no compiled + code after it. When looking for a line number LINENO, GDB looks for a + symtab with a line table entry for LINENO or a later line. It is + important for this test that there be no suitable line table entry. The + numbers have no real meaning, I just want to ensure that the 'XXX' line, + which is what the test lists is far from any previous source listing. + + 0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + XXX: Second line to list. + 10 + 9 + 8 + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 */ diff --git a/gdb/testsuite/gdb.base/dwz-symtabs-foo.h b/gdb/testsuite/gdb.base/dwz-symtabs-foo.h new file mode 100644 index 00000000000..65eb58ae28c --- /dev/null +++ b/gdb/testsuite/gdb.base/dwz-symtabs-foo.h @@ -0,0 +1,27 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2025 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +#ifndef SOLIB_WITH_DWZ_FOO_H +#define SOLIB_WITH_DWZ_FOO_H + +extern void process_foo_data (int value); + +typedef void (*foo_callback_type) (void); + +extern void do_callback (foo_callback_type cb); + +#endif /* SOLIB_WITH_DWZ_FOO_H */ diff --git a/gdb/testsuite/gdb.base/dwz-symtabs-main.c b/gdb/testsuite/gdb.base/dwz-symtabs-main.c new file mode 100644 index 00000000000..244ee5b5556 --- /dev/null +++ b/gdb/testsuite/gdb.base/dwz-symtabs-main.c @@ -0,0 +1,34 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2025 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +#include "dwz-symtabs-foo.h" +#include "dwz-symtabs-bar.h" + +void +breakpt (int a, int b) +{ + (void) a; + (void) b; +} + +int +main (void) +{ + do_callback (bar_func); + + return 0; +} diff --git a/gdb/testsuite/gdb.base/dwz-symtabs.exp b/gdb/testsuite/gdb.base/dwz-symtabs.exp new file mode 100644 index 00000000000..72b42a06ae1 --- /dev/null +++ b/gdb/testsuite/gdb.base/dwz-symtabs.exp @@ -0,0 +1,188 @@ +# Copyright 2025 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . */ + +# This test is very similar to gdb.debuginfod/solib-with-dwz.exp, +# except this one doesn't depend on debuginfod, and doesn't split the +# debug information out of the shared libraries before running the dwz +# tool. +# +# Three shared libraries are created, and the dwz tool is used to +# extract common debug information from these into a common.dwz file. +# +# The libraries libbar, libfoo, an libfoo-2. The foo.c and foo.h +# source files are shared between libfoo and libfoo-2, but are not +# used to create libbar. +# +# There is another header, common.h, which is shared between all of +# the libraries. +# +# The test starts the inferior, and runs until the symtabs of libbar +# have been expanded, and then checks to make sure that there is no +# symtab for foo.c or foo.h associated with libbar. Remember, these +# source files are not used to build libbar. +# +# At one point, a bug in GDB would mean that symtabs for these files +# were created and associated with libbar, this is because these files +# are mentioned in the common.dwz file. + +require allow_shlib_tests +require {istarget "*-linux*"} +require {!is_remote host} +require {dwz_version_at_least 0.13} + +standard_testfile -main.c -bar.c -foo.c -foo.h -common.h + +set libbar_filename [standard_output_file "libbar.so"] +set libfoo_filename [standard_output_file "libfoo.so"] +set libfoo_2_filename [standard_output_file "libfoo-2.so"] + +# Compile libbar.so. +if {[build_executable "build libbar.so" $libbar_filename \ + $srcfile2 { debug shlib build-id }] == -1} { + return +} + +# If we are running with a board that splits the debug information out and +# adds a .gnu_debuglink, then this test isn't going to work. We want to be +# in control of splitting out the debug information, and we definitely don't +# want a .gnu_debuglink otherwise debuginfod isn't going to be needed. +if {[section_get $libbar_filename ".gnu_debuglink"] ne ""} { + unsupported "debug information has already been split out" + return +} + +# Compile libfoo.so. +if {[build_executable "build libfoo.so" $libfoo_filename \ + $srcfile3 { debug shlib build-id }] == -1} { + return +} + +# Compile libfoo-2.so. +if {[build_executable "build libfoo-2.so" $libfoo_2_filename \ + $srcfile3 { debug shlib build-id additional_flags=-DFOO2}] == -1} { + return +} + +# Build the executable. +if { [build_executable "build executable" ${binfile} ${srcfile} \ + [list debug shlib=${libbar_filename} shlib=${libfoo_filename} shlib_load]] == -1 } { + return +} + +gdb_download_shlib $libbar_filename +gdb_download_shlib $libfoo_filename +gdb_download_shlib $libfoo_2_filename + +# Run DWZ tool on the library files. This moves shared debug +# information into a 'common.dwz' file. +set dwz_file [standard_output_file "common.dwz"] +set status \ + [remote_exec build "dwz -m $dwz_file \ + $libbar_filename \ + $libfoo_filename \ + $libfoo_2_filename"] +if {[lindex $status 0] != 0} { + unsupported "unable to run dwz tool" + return +} + +# Some earlier versions of dwz would fail to process the .debug files, +# producing some error output, but still exit with code 0. A +# successful execution of dwz should produce no output. +if {[lindex $status 1] ne ""} { + unsupported "unexpected output from dwz tool" + return +} + +clean_restart $testfile + +if { ![runto_main] } { + return +} + +# This test relies on reading address zero triggering a SIGSEGV. +# If address zero is readable then give up now. +if { [is_address_zero_readable] } { + unsupported "address zero in readable" + return +} + +set crash_line_num [gdb_get_line_number "Crash here" $::srcfile2] +gdb_test "continue" \ + "\r\n$crash_line_num\\s+[string_to_regexp {*ptr = 0; /* Crash here. */}]" + +set call_line_num [gdb_get_line_number "Call line" $::srcfile3] +gdb_test "up" \ + "\r\n$call_line_num\\s+[string_to_regexp {cb (); /* Call line. */}]" + +gdb_test "list" \ + "\r\n$call_line_num\\s+[string_to_regexp {cb (); /* Call line. */}]\r\n.*" \ + "list default location in $::srcfile3" + +set list_line_num [gdb_get_line_number "Second line to list" $::srcfile3] +gdb_test "list $list_line_num" "$list_line_num\\s+XXX: Second line to list\\.\r\n.*" \ + "list additional lines in $::srcfile3" + +# Use 'maint info symtabs' to list all symtabs and find the +# symtabs that are associated with libbar.so. +# +# Then check that *-foo.c and *-foo.h don't appear in this list. +# +# But check that *-bar.c and *-common.h do appear in the list. +set build_id [get_build_id $::libbar_filename] +set symtabs [list] +set collect_symtabs false + +gdb_test_multiple "maint info symtabs" "" { + -re "^maint info symtabs\r\n" { + exp_continue + } + -re "^\{ objfile (\[^\r\n\]+) \\(\\(struct objfile \\*\\) $::hex\\)\r\n" { + set objfile_name $expect_out(1,string) + if { [file tail $objfile_name] eq [file tail $libbar_filename] } { + set collect_symtabs true + } else { + set collect_symtabs false + } + exp_continue + } + -re "^\\s+\{ symtab \[^\r\n\]+\r\n" { + # Ignore '' nameless symtabs. + exp_continue + } + -re "^\\s+\{ symtab (\[^\r\n\]+) \\(\\(struct symtab \\*\\) $::hex\\)\r\n" { + if { $collect_symtabs } { + set symtab_name $expect_out(1,string) + lappend symtabs [file tail $symtab_name] + } + exp_continue + } + -re "^$::gdb_prompt $" { + pass $gdb_test_name + } + -re "^\[^\r\n\]+\r\n" { + exp_continue + } +} + +foreach filename [list $::srcfile3 $::srcfile4] { + gdb_assert { [lsearch -exact $symtabs $filename] == -1 } \ + "$filename is not in the symtab list" +} + +foreach filename [list $::srcfile2 $::srcfile5] { + gdb_assert { [lsearch -exact $symtabs $filename] != -1 } \ + "$filename is in the symtab list" +} diff --git a/gdb/testsuite/gdb.debuginfod/solib-with-dwz.exp b/gdb/testsuite/gdb.debuginfod/solib-with-dwz.exp index d30707d5433..354b52fc0f5 100644 --- a/gdb/testsuite/gdb.debuginfod/solib-with-dwz.exp +++ b/gdb/testsuite/gdb.debuginfod/solib-with-dwz.exp @@ -86,7 +86,7 @@ require {istarget "*-linux*"} require {!is_remote host} require {dwz_version_at_least 0.13} -standard_testfile -main.c -bar.c -foo.c +standard_testfile -main.c -bar.c -foo.c -foo.h -common.h set libbar_filename [standard_output_file "libbar.so"] set libfoo_filename [standard_output_file "libfoo.so"] @@ -291,25 +291,6 @@ proc run_test { cache db debug_dir use_filename } { set saw_source_download [check_cache_for_foo $cache] } - # GDB ends up creating a symtab for solib-with-dwz-foo.c - # associated with libbar.so. This isn't ideal as *-foo.c wasn't - # used within libbar.so. The symtab is a result of loading the - # file/line table from the DWZ file while processing the DWARF - # for libbar.so. - # - # While performing the 'list LINENO' or 'list FILE:LINENO' - # command GDB performs a search of all symtabs, as part of this - # process GDB tries to establish the full source filename for - # the *-foo.c symtab associated with libbar.so, this in turn - # causes GDB to try and download the source from debuginfod. - # - # This download will fail as *-foo.c is not used within - # libbar.so, but having GDB try to download the file is not - # ideal, even if it is harmless. - # - # If/when this xfail is addressed, the comment at the start of - # this file will need updating too. - setup_xfail "*-*-*" gdb_assert { !$saw_source_download } \ "$gdb_test_name, no source download" @@ -321,6 +302,59 @@ proc run_test { cache db debug_dir use_filename } { exp_continue } } + + # Use 'maint info symtabs' to list all symtabs and find the + # symtabs that are associated with libbar.so (actually with the + # separate debug file for libbar.so). + # + # Then check that *-foo.c and *-foo.h don't appear in this list. + # + # But check that *-bar.c and *-common.h do appear in the list. + set build_id [get_build_id $::libbar_filename] + set symtabs [list] + set collect_symtabs false + + gdb_test_multiple "maint info symtabs" "" { + -re "^maint info symtabs\r\n" { + exp_continue + } + -re "^\{ objfile (\[^\r\n\]+) \\(\\(struct objfile \\*\\) $::hex\\)\r\n" { + set objfile_name $expect_out(1,string) + if { [string first $build_id $objfile_name] != -1 } { + set collect_symtabs true + } else { + set collect_symtabs false + } + exp_continue + } + -re "^\\s+\{ symtab \[^\r\n\]+\r\n" { + # Ignore '' nameless symtabs. + exp_continue + } + -re "^\\s+\{ symtab (\[^\r\n\]+) \\(\\(struct symtab \\*\\) $::hex\\)\r\n" { + if { $collect_symtabs } { + set symtab_name $expect_out(1,string) + lappend symtabs [file tail $symtab_name] + } + exp_continue + } + -re "^$::gdb_prompt $" { + pass $gdb_test_name + } + -re "^\[^\r\n\]+\r\n" { + exp_continue + } + } + + foreach filename [list $::srcfile3 $::srcfile4] { + gdb_assert { [lsearch -exact $symtabs $filename] == -1 } \ + "$filename is not in the symtab list" + } + + foreach filename [list $::srcfile2 $::srcfile5] { + gdb_assert { [lsearch -exact $symtabs $filename] != -1 } \ + "$filename is in the symtab list" + } } # Create CACHE and DB directories ready for debuginfod to use.