From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: gdb-patches@sourceware.org
Cc: Daniel Jacobowitz <drow@false.org>,
iam ahal <hal9000ed2k@gmail.com>,
Tom Tromey <tromey@redhat.com>,
Eli Zaretskii <eliz@gnu.org>,
palves@redhat.com, dje@google.com, pmuldoon@redhat.com,
brobecker@adacore.com, asmwarrior@gmail.com
Subject: Re: [commit] Handle files without DW_AT_comp_dir
Date: Fri, 06 Apr 2012 12:37:00 -0000 [thread overview]
Message-ID: <20120406123641.GA18063@host2.jankratochvil.net> (raw)
In-Reply-To: <20070604123615.GA22533@caradoc.them.org>
http://sourceware.org/ml/gdb-patches/2007-06/msg00031.html
On Mon, 04 Jun 2007 14:36:15 +0200, Daniel Jacobowitz wrote:
> Joseph Myers discovered a case where GCC emits an absolute path in
> DW_AT_name, no DW_AT_comp_dir, and relative pathnames in the directory
> table.
I see only absolute directory pathnames in .debug_line in such case.
If it really was a GCC bug it should be addressed by DW_AT_producer based
workaround limitation.
> GDB could not handle this, and failed to locate header files
> in the correct paths.
>
> The GCC behavior is a bug, and I think Joseph's working on a fix for
> it. But it's been around for a long time, so I think it's worthwhile
> to handle it in GDB. I tested the patch below on x86_64-linux and
> checked it in.
[...]
> attr = dwarf2_attr (die, DW_AT_comp_dir, cu);
> if (attr)
> + comp_dir = DW_STRING (attr);
> + else if (name != NULL && IS_ABSOLUTE_PATH (name))
> {
> + comp_dir = ldirname (name);
This is affecting the long thread of patch
[patch] GDB 7.2: new feature for "backtrace" that cuts path to file (remain filename)
DWARF considers the CU's DW_AT_comp_dir attribute optional.
I do not see any problem with it, compilation directory is not known in such
case. I do not see any testcase in this patch which would show which GCC
versions under which conditions produced such buggy output. These GCC
versions produce correct output, that is:
cd /tmp; gcc -o ~/1 ~/1.c -g
CU's DW_AT_name is absolute /root/1.c
CU's DW_AT_comp_dir is not present
.debug_line uses directory entry /root
.debug_line uses filename entry 1.c
with:
GNU C 2.96 20000731 (Red Hat Linux 7.2 2.96-116.7.2)
gcc (GCC) 3.3.5
gcc (GCC) 4.4.7
gcc (GCC) 4.8.0 20120406 (experimental)
Without known GCC buggy versions going to revert this patch as it breaks
correct DWARF. The thread "that cuts path to file (remain filename)" tries to
(in some way) undo what this patch does.
Thanks,
Jan
next prev parent reply other threads:[~2012-04-06 12:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-04 12:36 Daniel Jacobowitz
2012-04-06 12:37 ` Jan Kratochvil [this message]
2012-04-07 22:37 ` Daniel Jacobowitz
2012-04-07 23:27 ` Joseph S. Myers
2012-04-09 15:48 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120406123641.GA18063@host2.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=asmwarrior@gmail.com \
--cc=brobecker@adacore.com \
--cc=dje@google.com \
--cc=drow@false.org \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=hal9000ed2k@gmail.com \
--cc=palves@redhat.com \
--cc=pmuldoon@redhat.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox