From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id U8KjDpKPnmD3HgAAWB0awg (envelope-from ) for ; Fri, 14 May 2021 10:56:18 -0400 Received: by simark.ca (Postfix, from userid 112) id 2D9DB1F11C; Fri, 14 May 2021 10:56:18 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from 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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 879781E783 for ; Fri, 14 May 2021 10:56:16 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 092583950C85; Fri, 14 May 2021 14:56:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 092583950C85 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1621004176; bh=7r+1M8x6R3tgSAoAEHsP/KMsJ4uGCqxB828DaoD92iU=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=nsPIC0E3qp6GDXbFO8q+LQZ2Sbi3yxKyihPbl+3N8KrR62ybM1OpbbalOgEBHe2BX H+XL2coGTufmcLFroid1tMyhPcq6x20yc0JhcPeArpj/IE0HsQJ9KwdLwLKvYdg0Y4 ud6Fqj6iyXD0Yp2PP7RWtV7VKPp6PNZwXXxlyKKo= 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 C3B753951401 for ; Fri, 14 May 2021 14:56:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C3B753951401 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-46-Q9PZaoeMOLqx_ffcrJ33nw-1; Fri, 14 May 2021 10:56:10 -0400 X-MC-Unique: Q9PZaoeMOLqx_ffcrJ33nw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D7486803620; Fri, 14 May 2021 14:56:09 +0000 (UTC) Received: from [10.3.112.40] (ovpn-112-40.phx2.redhat.com [10.3.112.40]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A01525D6D1; Fri, 14 May 2021 14:56:09 +0000 (UTC) Subject: Re: [PATCH] Fix macro info lookup for binaries containing DWARFv5 line table To: Sourabh Singh Tomar , gdb-patches@sourceware.org References: <20210512171655.9463-1-SourabhSingh.Tomar@amd.com> Message-ID: <22ab603a-35e1-4048-3ccc-6738a13889df@redhat.com> Date: Fri, 14 May 2021 07:56:08 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210512171655.9463-1-SourabhSingh.Tomar@amd.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Keith Seitz via Gdb-patches Reply-To: Keith Seitz Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Coincidentally, I happened to be looking at gdb/27306 about a similar problem, and I was curious to see how our patches interacted. On 5/12/21 10:16 AM, Sourabh Singh Tomar via Gdb-patches wrote: > As one may notice that dir index `0` will always contain > absoulte path(Not including the file name as), this causes > GDB to append the path + filename to construt macro info > `main_file->filename`. This leads to overriding of the macro filename > which will cause macro info lookup failure due to mismatch in > `main_file->filename` and `sal.symtab->filename`. gdb/27306 highlights a similar problem with gcc using -gdwarf-5: cat -n undef-macro.c 1 #define FOO 1 2 3 int main(int argc, char **argv) 4 { 5 return FOO; 6 } $ gcc -gdwarf-5 undef-macro.c -o undef-macro $ ./gdb -nx -q undef-macro -ex start -ex "p FOO" (gdb) start Temporary breakpoint 1 at 0x401111: file foo.c, line 5. Starting program: undef-macro Temporary breakpoint 1, main (argc=1, argv=0x7fffffffdd48) at undef-macro.c:5 5 return FOO; No symbol "FOO" in current context. The problem is that file name returned by file_file_name is /not/ relative to the compilation directory. Ever. >From file_file_name: const file_entry *fe = file_name_at (file); if (!IS_ABSOLUTE_PATH (fe->name)) { const char *dir = fe->include_dir (this); /* The file at index 0 (valid starting with DWARF 5) is already relative to the compilation directory. */ if (file != 0) return gdb::unique_xmalloc_ptr (concat (dir, SLASH_STRING, fe->name, (char *) NULL)); Even with your patch, gdb will still return an absolute path for the above test. As you've already mentioned, macro_start_file and macro_lookup_inclusion require that macro_source_file.filename be relative to the compliation directory. Furthermore, the documentation for macro_source_file.filename is stricter: /* A source file --- possibly a header file. This filename is relative to the compilation directory (table->comp_dir), it exactly matches the symtab->filename content. */ const char *filename; So if symtab->filename and macro_source_filename are required to be the same, why are we bothering with prepending directories? We already have access to the symtab in `fe'. This is the version I was playing with... diff --git a/gdb/dwarf2/line-header.c b/gdb/dwarf2/line-header.c index 7575297f966..117c5a42cc5 100644 --- a/gdb/dwarf2/line-header.c +++ b/gdb/dwarf2/line-header.c @@ -69,15 +69,10 @@ line_header::file_file_name (int file) const { const file_entry *fe = file_name_at (file); - if (!IS_ABSOLUTE_PATH (fe->name)) - { - const char *dir = fe->include_dir (this); - if (dir != NULL) - return gdb::unique_xmalloc_ptr (concat (dir, SLASH_STRING, - fe->name, - (char *) NULL)); - } - return make_unique_xstrdup (fe->name); + /* macro_source_file requires: "This filename is relative to the + compilation directory, it exactly matches the symtab->filename + content." */ + return make_unique_xstrdup (fe->symtab->filename); } else { By happy coincidence, this has the same effect of your patch, but it also fixes gdb/27306. I checked the origins of file_file_name and it appears that this function was split out from file_full_name, but this directory prepending bit was never removed to fulfill the "relative" requirement of the stated documentation. [This is from commit 233d95b548ec948c4a6d01cd05c307385dd615fb.] I hate to post counter-patches, but in this case, I think we are really both attempting to solve the same design problem with line_header::file_file_name. > This problem does not pops up with GCC compiled binaries, since > GCC does not emits DWARFv5 compliant line tables. This test (as written) does not pass using gcc: $ make check TESTS=gdb.base/dwarf5-macro.exp [snip] Running /home/keiths/work/gdb/branches/virgin/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/dwarf5-macro.exp ... FAIL: gdb.base/dwarf5-macro.exp: info macro HELLO_GDB === gdb Summary === # of unexpected failures 1 However, if I force -gdwarf-5 for gcc, too: $ make check TESTS=gdb.base/dwarf5-macro.exp RUNTESTFLAGS="unix/-g3/-gdwarf-5" [snip] Running /home/keiths/work/gdb/branches/virgin/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/dwarf5-macro.exp ... === gdb Summary === # of expected passes 1 I suggest that be corrected -- just force gcc to emit dwarf-5 debuginfo as well. IMO, the correct, compiler-agnostic way of dealing with this is via the DWARF assembler, but I am not going to suggest you do that. I'd be happy if the test simply didn't FAIL on non-clang targets. Keith