From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id mgUZIx4m8GhMLjYAWB0awg (envelope-from ) for ; Wed, 15 Oct 2025 18:54:22 -0400 Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=dominicclifton.name header.i=@dominicclifton.name header.a=rsa-sha256 header.s=email header.b=A1WjifK3; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 7FD3A1E0BA; Wed, 15 Oct 2025 18:54:22 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_INVALID,DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D8A4F1E047 for ; Wed, 15 Oct 2025 18:54:20 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 08174385843A for ; Wed, 15 Oct 2025 22:54:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 08174385843A Authentication-Results: sourceware.org; dkim=fail reason="signature verification failed" (1024-bit key, unprotected) header.d=dominicclifton.name header.i=@dominicclifton.name header.a=rsa-sha256 header.s=email header.b=A1WjifK3 Received: from mx03.hydraservices.com (mx03.hydraservices.com [82.113.145.160]) by sourceware.org (Postfix) with ESMTPS id 47CD7385842B for ; Wed, 15 Oct 2025 22:53:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 47CD7385842B Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=dominicclifton.name Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dominicclifton.name ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 47CD7385842B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=82.113.145.160 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760568822; cv=none; b=m1Wcpn+kLPhr2KUpLVg/Jebb+mPFtKjL6DpsL0yLIir6aNuZ8ThyLXq7zkf9bO4acH7H2u8m/rImHyJRZDqDVCZ4kVW/poGaY+69/OMh1NA14fMJ5vrZ3VXGoH10HVGXvWHNdmzS5PA2tibncYYETSIoO2ny3LpUJSrcU4fjcc8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760568822; c=relaxed/simple; bh=EiVRruYXgnJ83Fy0/rEhwZQPBuvvB9HFIBGrR1yi2vM=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=wKgnWg811y3YJFyTrn+buEmBpy0PfcoaVHajNnau4VJzw3/95EQ5gPeOm0gg/jKdDduuQvFhSG7NyLxgF1bRClagpRwg7rB/ynkDQAC/kQW2oBoJKrfzfcuZqreuF1IR0GMSzpZlwo7l5QEBejcUd5LLc93t+4wbVpp1xy8E2Yw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 47CD7385842B DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dominicclifton.name; s=email; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=urWWcF3DxT6IV4B9DGtEM1vyv2xN5WYG7pPQnhk7Fb0=; b=A1WjifK3+bP/J3p4CCIq3hpjUH HOqtCQXt/9yQuVFVyzlwX0qPBAJqD/I7jcTKHXwr+dyzUUGauyW2yBNyxZL0vZa4XdnGOM7IfDyGx 1WHTzOosuG3V54YgkxCZBfmxnTa1ejVTVX9x7lWNvhowA/SN9OOTmRbecQqtPgrf1Qm8=; Received: from [45.86.185.202] (helo=HYDRA01) by mx03.hydraservices.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1v9ANI-00GPaQ-F6; Wed, 15 Oct 2025 23:53:40 +0100 From: "Dominic Clifton" To: "'Andrew Burgess'" , References: <00d101dc3609$37564b00$a602e100$@dominicclifton.name> <017301dc3943$0ba55950$22f00bf0$@dominicclifton.name> <877bwybu6l.fsf@redhat.com> In-Reply-To: <877bwybu6l.fsf@redhat.com> Subject: RE: [PATCH] read_file_scope - avoid eventual crash when the file or directory name is null. Date: Thu, 16 Oct 2025 00:53:39 +0200 Message-ID: <004d01dc3e26$8c7576e0$a56064a0$@dominicclifton.name> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGDN+atxJvNFm6cT9B7vvoZgOzQVAIjXVrhAbNWRWq1VyaKEA== Content-Language: en-gb X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hi Andrew, Thanks for responding. The elf file in question is here: https://drive.google.com/file/d/1um3lJFHTvLHdAZdM7D-hLMmdsGJneDeC/view?usp=s haring Yes, I suspected there might be more to fixing this, I don't have a good understanding of the gdb codebase nor the time to create a proper fix if this isn't it, I simply don't have time to get comfortable with the codebase. However, I do have time to help someone who does know the gdb codebase to fix it properly by means of any assistance and testing as required. Let me know if there's anything else you need. Kind regards, Dominic -----Original Message----- From: Andrew Burgess Sent: 13 October 2025 19:14 To: Dominic Clifton ; gdb-patches@sourceware.org Subject: Re: [PATCH] read_file_scope - avoid eventual crash when the file or directory name is null. "Dominic Clifton" writes: > * without this, launching the debugger results in the following error: > > ``` > terminate called after throwing an instance of 'std::logic_error' what(): > basic_string: construction from null is not valid ``` Thanks for looking into this failure. > > find_file_and_directory - return empty strings instead of null pointers. > > --- > gdb/dwarf2/read.c | 29 +++++++++++++++++++++-------- > 1 file changed, 21 insertions(+), 8 deletions(-) > > diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index > 955893c5f0c..287ce7b518c 100644 > --- a/gdb/dwarf2/read.c > +++ b/gdb/dwarf2/read.c > @@ -5942,10 +5942,18 @@ find_file_and_directory (struct die_info *die, > struct dwarf2_cu *cu) > if (cu->per_cu->fnd != nullptr) > return *cu->per_cu->fnd; > > + // Ensure that nullptrs become empty strings const char *name = > + dwarf2_string_attr(die, DW_AT_name, cu); const char *comp_dir = > + dwarf2_string_attr(die, DW_AT_comp_dir, cu); > + > + if (!name) > + name = ""; > + if (!comp_dir) > + comp_dir = ""; > + > /* Find the filename. Do not use dwarf2_name here, since the filename > is not a source language identifier. */ > - file_and_directory res (dwarf2_string_attr (die, DW_AT_name, cu), > - dwarf2_string_attr (die, DW_AT_comp_dir, cu)); > + file_and_directory res(name, comp_dir); I suspect this change is going to cause problems. If you checkout struct file_and_directory in file-and-dir.h you'll see there are a couple of methods which check for nullptr as a special value, so masking all of the nullptr inputs is going to change the behaviour. > > if (res.get_comp_dir () == nullptr And just here we have an example of some code which appears to be checking for nullptr, which is no longer going to work as expected after this change. Could you expand on what the DWARF looks like that is triggering this failure? We have a DWARF assembler in our testsuite, see gdb.dwarf2/ for some examples (look for 'Dwarf::assemble'), so we should be able to reproduce the problematic DWARF and trigger the failure. I initially figured it might be as simple as a missing DW_AT_name on a DW_TAG_compile_unit, but that didn't seem to trigger the issue, so there must be more too it. If you can show the DWARF in question then we can likely write a test for this issue, or, if you feel adventurous, you could have a go yourself. Thanks, Andrew > && cu->producer_is_gcc_lt_4_3 () @@ -6083,28 +6091,33 @@ > read_file_scope (struct die_info *die, struct dwarf2_cu *cu) > > file_and_directory &fnd = find_file_and_directory (die, cu); > > + // ensure fnd.get_name() and fnd.get_comp_dir() are never null, > + which > they sometimes are > + const char *fname = fnd.get_name() ? fnd.get_name() : ""; const > + char *compdir = fnd.get_comp_dir() ? fnd.get_comp_dir() : ""; > + > /* GAS supports generating dwarf-5 info starting version 2.35. Versions > 2.35-2.37 generate an incorrect CU name attribute: it's relative, > implicitly prefixing it with the compilation dir. Work around this by > prefixing it with the source dir instead. */ > - if (cu->header.version == 5 && !IS_ABSOLUTE_PATH (fnd.get_name ()) > + if (cu->header.version == 5 && !IS_ABSOLUTE_PATH (fname) > && cu->producer_is_gas_lt_2_38 ()) > { > attr = dwarf2_attr (die, DW_AT_stmt_list, cu); > if (attr != nullptr && attr->form_is_unsigned ()) > { > sect_offset line_offset = (sect_offset) attr->as_unsigned (); > - line_header_up lh = dwarf_decode_line_header (line_offset, cu, > - fnd.get_comp_dir > ()); > + line_header_up lh = dwarf_decode_line_header (line_offset, cu, > compdir); > if (lh->version == 5 && lh->include_dir_at (1) != nullptr) > { > - std::string dir = lh->include_dir_at (1); > - fnd.set_comp_dir (std::move (dir)); > + const char* dir_ptr = lh->include_dir_at (1); > + std::string dir = dir_ptr ? dir_ptr : compdir; > + > + fnd.set_comp_dir (std::move (dir)); > } > } > } > > - cu->start_compunit_symtab (fnd.get_name (), fnd.intern_comp_dir > (objfile), > + cu->start_compunit_symtab (fname, fnd.intern_comp_dir (objfile), > lowpc); > > gdb_assert (per_objfile->sym_cu == nullptr); > -- > 2.48.1