GDB (mis)behavior depends on DWARF DW_TAG_compile_unit data

[Maxim Grigoriev]

Hello members,

I would like to hear your opinion on whether what I see is a compiler problem or a GDB misbehavior.

GDB session goes wrong, if my test case is compiled using a base name as a source file. Everything is fine, when an absolute path name is used instead. I checked several compilers ( all GCCs ). They seem to be consistent in generating DWARF DW_TAG_compile_unit information in this case.

Anyway, even if GDB treats this situation as a bad DWARF data it doesn't look decent to output misleading error messages, like 'No line 6 in file "test.c".', when there actually is the line number 6, and the test case was compiled with "-g".

* * * * *

Here come the details:

1) The GDB version is: GNU gdb 6.6.50.20070312-cvs

2) The test program is:

001: extern int printf(const char *fmt,...);
002:
003: int main()
004: {
005: printf("Hello, World !\n");
006: printf("Let's make DWARF consistent across all the tools !\n");
007: }

3) It was compiled with two different command line options:

gcc -g test.c -o basename_used.exe
gcc -g /home/maxim/W/BadgerPass/FSF_QUESTION/test.c -o full_path_used.exe

4) Freshly build GDB was run with the command file CMD_FILE:

break main
break test.c:6
quit

gdb full_path_used.exe --command=CMD_FILE

[ . . . . . ]
Breakpoint 1 at 0x40000970: file /home/maxim/W/BadgerPass/FSF_QUESTION/test.c, line 4.
Breakpoint 2 at 0x4000097c: file /home/maxim/W/BadgerPass/FSF_QUESTION/test.c, line 6.

gdb basename_used.exe --command=CMD_FILE

[ . . . . . ]
Breakpoint 1 at 0x40000970: file /home/maxim/W/BadgerPass/FSF_QUESTION/test.c, line 4.
CMD_FILE:2: Error in sourced command file:
No line 6 in file "test.c".

5) The difference in DWARF info is :

-- Good case, full_path_used.exe:
[ . . . . ]
<0><c3>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_name : /home/maxim/W/BadgerPass/FSF_QUESTION/test.c
DW_AT_comp_dir : /home/maxim/W/BadgerPass/FSF_QUESTION

-- Bad case, basename_used.exe:
[ . . . . ]
<0><c3>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_name : test.c
DW_AT_comp_dir : /home/maxim/W/BadgerPass/FSF_QUESTION

Thanks in advance for any input on this,
-- Maxim

[Daniel Jacobowitz]

Post by Maxim Grigoriev
Hello members,
I would like to hear your opinion on whether what I see is a compiler
problem or a GDB misbehavior.
GDB session goes wrong, if my test case is compiled using a base name as a
source file. Everything is fine, when an absolute path name is used
instead. I checked several compilers ( all GCCs ). They seem to be
consistent in generating DWARF DW_TAG_compile_unit information in this case.
Anyway, even if GDB treats this situation as a bad DWARF data it doesn't
look decent to output misleading error messages, like 'No line 6 in file
"test.c".', when there actually is the line number 6, and the test case was
compiled with "-g".

There must be more to the problem, since many people do this all the
time without any trouble. GDB has support for both cases. What
platform - is this Cygwin maybe? Is there any other test.c that GDB
might be opening?

[Maxim Grigoriev]

The problem is consistent across both hosts I checked : Linux and Cygwin.
The case I described is "--host=i686-pc-linux-gnu --target=xtensa-elf".
There is only one place in the DWARD sections where "test.c" is mentioned.
So there is no interference with any other file named "test.c".

If you think it's a generic GDB problem I can fix it. I have to fix it
anyway on
Xtensa GDB. I don't see how it can be Xtensa-specific. Xtensa GCC compiler
DWARF is consistent with native GCC 4.1.1 compiler on my Linux box.
So if this is a compiler problem ( which I doubt ) it seems to be pretty
generic.

-- Maxim

Post by Daniel Jacobowitz

Post by Maxim Grigoriev
Hello members,
I would like to hear your opinion on whether what I see is a compiler
problem or a GDB misbehavior.
GDB session goes wrong, if my test case is compiled using a base name as a
source file. Everything is fine, when an absolute path name is used
instead. I checked several compilers ( all GCCs ). They seem to be
consistent in generating DWARF DW_TAG_compile_unit information in this case.
Anyway, even if GDB treats this situation as a bad DWARF data it doesn't
look decent to output misleading error messages, like 'No line 6 in file
"test.c".', when there actually is the line number 6, and the test case was
compiled with "-g".

There must be more to the problem, since many people do this all the
time without any trouble. GDB has support for both cases. What
platform - is this Cygwin maybe? Is there any other test.c that GDB
might be opening?

[Joel Brobecker]

Post by Maxim Grigoriev
If you think it's a generic GDB problem I can fix it. I have to fix it
anyway on Xtensa GDB. I don't see how it can be Xtensa-specific.
Xtensa GCC compiler DWARF is consistent with native GCC 4.1.1 compiler
on my Linux box. So if this is a compiler problem ( which I doubt )
it seems to be pretty generic.

With the information you have given us, all I can say is that GDB
should be able to handle the situation, so we do have a bug somewhere.
Whether it is in GCC or GDB is still an open question as far as I can
tell.

Have you checked the line-table as well in both cases? There is
a very convenient command that gives you the list of lines known
by GDB for any given file: -symbol-list-lines. It's a MI command,
but you should be able to use it from the GDB prompt using
"interpreter-exe mi -symbol-list-lines" followed by the filename.

[Maxim Grigoriev]

This post might be inappropriate. Click to display it.

[Daniel Jacobowitz]

Post by Maxim Grigoriev
Let me find out what it is and get back to you with my conclusions. It's
still can be
important for GDB in terms of better handling bad DWARF data.

Thanks - I completely agree. It's not the obvious problem, but
whatever it is, we should fix it if we can.

[Maxim Grigoriev]

I found what the problem is. It's strictly Tensilica-compiler-specific.

I suggest we discuss it on the gdb-patch list since I already tried
to provide a patch to fix this issue.

If we end up with understanding that compiler should be fixed then
my GDB patch should be modified to recognize inconsistent DWARF and
issue a warning instead of printing misleading error messages (like it
does now).

-- Maxim

Post by Daniel Jacobowitz

Post by Maxim Grigoriev
Let me find out what it is and get back to you with my conclusions. It's
still can be
important for GDB in terms of better handling bad DWARF data.

Thanks - I completely agree. It's not the obvious problem, but
whatever it is, we should fix it if we can.

[Bob Wilson]

Post by Maxim Grigoriev
Hello members,
I would like to hear your opinion on whether what I see is a compiler
problem or a GDB misbehavior.

I don't know what's going wrong, but I just tried your testcase and the problem
did not occur. This was on x86/Linux with a freshly updated copy of GDB. Let
me know if you'd like me to help track down your problem (offline).

--Bob