GDB (mis)behavior depends on DWARF DW_TAG_compile_unit data

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

-- Good case:
>>> 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.

-- Bad case:
>>> 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

Re: GDB (mis)behavior depends on DWARF DW_TAG_compile_unit data

[Daniel Jacobowitz]

On Mon, Mar 12, 2007 at 01:33:45PM -0700, Maxim Grigoriev wrote:
> 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?

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB (mis)behavior depends on DWARF DW_TAG_compile_unit data

[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

Daniel Jacobowitz wrote:
> On Mon, Mar 12, 2007 at 01:33:45PM -0700, Maxim Grigoriev wrote:
>   
>> 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?
>
>   

Re: GDB (mis)behavior depends on DWARF DW_TAG_compile_unit data

[Joel Brobecker]

> 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.

-- 
Joel

Re: GDB (mis)behavior depends on DWARF DW_TAG_compile_unit data

[Maxim Grigoriev]

Now I'm getting convinced more and more that this is Tensilica 
compiler's problem.
It could be not that trivial as I thought in the beginning. I didn't 
actually compare executables
from different compilers running them under latests GDB's control. 
Instead, I was comparing
DWARF data, specifically, "DWARF DW_TAG_compile_unit" tag. That's why I 
missed
the point that Xtensa-specific GDB misbehavior has nothing to do with 
"DWARF DW_TAG_compile_unit"
entry ( which looks the same across all the compilers ). It has to be 
something else.

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 much for your valuable input on this. It really helps.

-- Maxim

Joel Brobecker wrote:
>> 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.
>
>   

Re: GDB (mis)behavior depends on DWARF DW_TAG_compile_unit data

[Daniel Jacobowitz]

On Mon, Mar 12, 2007 at 02:54:05PM -0700, Maxim Grigoriev wrote:
> 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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB (mis)behavior depends on DWARF DW_TAG_compile_unit data

[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

Daniel Jacobowitz wrote:
> On Mon, Mar 12, 2007 at 02:54:05PM -0700, Maxim Grigoriev wrote:
>   
>> 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.
>
>   

Re: GDB (mis)behavior depends on DWARF DW_TAG_compile_unit data

[Bob Wilson]

Maxim Grigoriev wrote:
> 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