GDB cannot find line info

GDB cannot find line info

[Christophe LYON]

Hello,

I have found a bug in our compiler (Open64 for ST200), which I have 
fixed to make it correctly output the directory table related to 
debug_line info.
But now, I have many regressions in the GDB testsuite (6.8), the first 
one being in break.exp: now the command "break break.c:103" returns 'No 
line 103 in file "break.c"'

I have dumped the dwarf debug_line info with 'dwarfdump -l' and 'readelf 
-wl', but could not find anything suspect:
- with dwarfdump, the only difference is in the directory path
- with readelf, the directory tables contain one more entry (absolute 
path to gdb.base) and the file table has dir numbers updated 
accordingly. (obviously, the length and offset of the corresponding 
sections are different)

Is there any GDB internal command I could use to understand the problem?

Thanks,

Christophe.

Re: GDB cannot find line info

[Frédéric RISS]

Hi Christophe,

On ven., 2009-09-18 at 18:11 +0200, Christophe LYON wrote:
> But now, I have many regressions in the GDB testsuite (6.8), the
> first 
> one being in break.exp: now the command "break break.c:103" returns
> 'No 
> line 103 in file "break.c"'

I thought that got reported internally at ST. I'm quite sure that the
issue is Open64 not setting the is_stmt flag, and newer GDBs discarding
any line info not marked as such:

http://sourceware.org/ml/gdb-patches/2009-06/msg00633.html

Fred

Re: GDB cannot find line info

[Frederic Riss]

2009/9/18 Frédéric RISS <frederic.riss@gmail.com>:
> On ven., 2009-09-18 at 18:11 +0200, Christophe LYON wrote:
>> But now, I have many regressions in the GDB testsuite (6.8), the
>> first
>> one being in break.exp: now the command "break break.c:103" returns
>> 'No
>> line 103 in file "break.c"'
>
> I thought that got reported internally at ST. I'm quite sure that the
> issue is Open64 not setting the is_stmt flag, and newer GDBs discarding
> any line info not marked as such:
>
> http://sourceware.org/ml/gdb-patches/2009-06/msg00633.html

Oops. Seems I've answered too fast as you point out you're using 6.8
and that behavior is more recent... The issue must be different.

Fred

Re: GDB cannot find line info

[Joel Brobecker]

> Is there any GDB internal command I could use to understand the problem?

try the GDB/MI -symbol-list-lines command to dump the line table as
known by GDB. Looks like it might be empty... After that, the only
method I know to diagnose this sort of issue is debugging GDB while
it is reading the line table.

-- 
Joel

Re: GDB cannot find line info

[Robert Bu]

Hi Christophe,

Maybe you can try the CVS head or the 7.0 preview. I've once met the
same problem. And the problem is gone in CVS. Actually the problem is
fixed by the newly added function "watch_main_source_file_lossage
(void)" in buildsym.c

Robert.

>
>
> Hello,
>
> I have found a bug in our compiler (Open64 for ST200), which I have
> fixed to make it correctly output the directory table related to
> debug_line info.
> But now, I have many regressions in the GDB testsuite (6.8), the first
> one being in break.exp: now the command "break break.c:103" returns
> 'No line 103 in file "break.c"'
>
> I have dumped the dwarf debug_line info with 'dwarfdump -l' and
> 'readelf -wl', but could not find anything suspect:
> - with dwarfdump, the only difference is in the directory path
> - with readelf, the directory tables contain one more entry (absolute
> path to gdb.base) and the file table has dir numbers updated
> accordingly. (obviously, the length and offset of the corresponding
> sections are different)
>
> Is there any GDB internal command I could use to understand the problem?
>
> Thanks,
>
> Christophe.
>

Re: GDB cannot find line info

[Christophe LYON]

Hi Robert,

Thanks for the suggestion, indeed it has fixed my problem, though I 
don't really understand why :-)

I tried Joel's suggestion, and indeed the line table is empty.
I have tried comparing the output of "maintenance print symbols" between 
  executable files generated by 2 compilers (on break.c from the 
testsuite), and:
* with the compiler with the bug (incorrect source directory), Symtab 
for break.c appears once, with a line table
* with the compiler with my fix, Symtab for break.c appears twice, once 
with only "break.c" and no line table, and once with the full path to 
"break.c" and the right line table.

Christophe.


On 21.09.2009 09:45, Robert Bu wrote:
> Hi Christophe,
> 
> Maybe you can try the CVS head or the 7.0 preview. I've once met the
> same problem. And the problem is gone in CVS. Actually the problem is
> fixed by the newly added function "watch_main_source_file_lossage
> (void)" in buildsym.c
> 
> Robert.
> 
>>
>> Hello,
>>
>> I have found a bug in our compiler (Open64 for ST200), which I have
>> fixed to make it correctly output the directory table related to
>> debug_line info.
>> But now, I have many regressions in the GDB testsuite (6.8), the first
>> one being in break.exp: now the command "break break.c:103" returns
>> 'No line 103 in file "break.c"'
>>
>> I have dumped the dwarf debug_line info with 'dwarfdump -l' and
>> 'readelf -wl', but could not find anything suspect:
>> - with dwarfdump, the only difference is in the directory path
>> - with readelf, the directory tables contain one more entry (absolute
>> path to gdb.base) and the file table has dir numbers updated
>> accordingly. (obviously, the length and offset of the corresponding
>> sections are different)
>>
>> Is there any GDB internal command I could use to understand the problem?
>>
>> Thanks,
>>
>> Christophe.
>>
> 

Re: GDB cannot find line info

[Christophe LYON]

I have investigated a bit more, and the GDB patch actually seems to 
match perfectly my compiler behavior... maybe it was designed for 
another port of Open64 ;-)

For the record, debug_line describes only the source file basename + 
reference to the full path, while debug_info uses the full path name.

Hence, the same basename appears twice in GDB line table, but one of the 
entries has an empty line table (the one from debug_info).

Thanks for your help!

Christophe.


On 21.09.2009 17:00, Christophe LYON wrote:
> Hi Robert,
> 
> Thanks for the suggestion, indeed it has fixed my problem, though I 
> don't really understand why :-)
> 
> I tried Joel's suggestion, and indeed the line table is empty.
> I have tried comparing the output of "maintenance print symbols" between 
>  executable files generated by 2 compilers (on break.c from the 
> testsuite), and:
> * with the compiler with the bug (incorrect source directory), Symtab 
> for break.c appears once, with a line table
> * with the compiler with my fix, Symtab for break.c appears twice, once 
> with only "break.c" and no line table, and once with the full path to 
> "break.c" and the right line table.
> 
> Christophe.
> 
> 
> On 21.09.2009 09:45, Robert Bu wrote:
>> Hi Christophe,
>>
>> Maybe you can try the CVS head or the 7.0 preview. I've once met the
>> same problem. And the problem is gone in CVS. Actually the problem is
>> fixed by the newly added function "watch_main_source_file_lossage
>> (void)" in buildsym.c
>>
>> Robert.
>>
>>>
>>> Hello,
>>>
>>> I have found a bug in our compiler (Open64 for ST200), which I have
>>> fixed to make it correctly output the directory table related to
>>> debug_line info.
>>> But now, I have many regressions in the GDB testsuite (6.8), the first
>>> one being in break.exp: now the command "break break.c:103" returns
>>> 'No line 103 in file "break.c"'
>>>
>>> I have dumped the dwarf debug_line info with 'dwarfdump -l' and
>>> 'readelf -wl', but could not find anything suspect:
>>> - with dwarfdump, the only difference is in the directory path
>>> - with readelf, the directory tables contain one more entry (absolute
>>> path to gdb.base) and the file table has dir numbers updated
>>> accordingly. (obviously, the length and offset of the corresponding
>>> sections are different)
>>>
>>> Is there any GDB internal command I could use to understand the problem?
>>>
>>> Thanks,
>>>
>>> Christophe.
>>>
>>
> 
> 

Re: GDB cannot find line info

[Christophe LYON]

Hi,

Merging the patch mentioned earlier does fix most of the regressions I 
introduced after "fixing" our compiler, but there is still 1 regression 
left, which I fail to understand.

In langs.exp, I have now 1 failure:
up
#3  0x080003e4 in fsub_ ()
Current language:  auto; currently fortran
(gdb) FAIL: gdb.base/langs.exp: up to fsub in langs.exp


Remember, the difference between a "langs" executable that passes the 
test, and one that fails is the correct inclusion of the full dirname of 
the source file in the debug_line directory table.

I am using GDB 6.8 ported to ST200.

I have dumped the debug information in various ways:
* As suggested by Joel, with MI -symbol-list-lines
   Gives the very same results in both cases:
(gdb) -symbol-list-lines langs1.c
^done,lines=[{pc="0x080003a0",line="24"},{pc="0x080003a4",line="0"},{pc="0x080003a4",line="25"},{pc="0x080003a8",line="0"},{pc="0x080 
3a8",line="0"},{pc="0x080003b0",line="0"},{pc="0x080003bc",line="0"}]
(gdb) -symbol-list-lines langs1.f
^done,lines=[{pc="0x080003a8",line="5"},{pc="0x080003b0",line="0"},{pc="0x080003b0",line="6"},{pc="0x080003bc",line="0"},{pc="0x08000 
c",line="6"},{pc="0x080003c8",line="0"}]

* Using "maintenance print symbols":
- in the failing case, the data for "langs1.f" is dumped first, while it 
appears at the end of the dump in the other case.
- in the failing case, langs1.c is prefixed with its full path name.

* Using readelf -wl:
- the failing case has 1 entry in the directory table for langs1.o (full 
dirname for langs1.c) and langs1.c references it.
- In the executable which passes the test, the directory table for 
langs1.o is empty, and langs1.c has "0" as directory.

In both cases, langs1.f has "0" as directory.

* Using dwarfdump on langs1.o,
- DW_AT_decl_file attributes pointing to langs1.c show the full path in 
the failing case, and langs1.f (full path) has the hostname as prefix.
- In the object file which passes the test, the full path of langs1.c 
and langs1.f has always the hostname as prefix.

- the same difference appears in the debug_line dump.


It looks a bit like the problem I had several months ago 
(http://sourceware.org/ml/gdb-patches/2009-03/msg00617.html).

All the information I managed to dump looks correct to me, but GDB is 
still unhappy :-(

Any suggestion appreciated :-)

Thanks
Christophe.

Re: GDB cannot find line info

[Christophe LYON]

Hi,

I have made some progress on my problem: our compiler did not generate 
the full source pathname in the Dwarf2 compile unit (it added only the 
basename).
Making the compiler generate the full source pathname did fix the 
regression I observed in the GDB testsuite.

I report this here because, despite investigating for quite some time, I 
couldn't figure what actually confused GDB.

It looks a bit like what was already fixed by 
http://sourceware.org/ml/gdb-patches/2008-04/msg00158.html
so maybe there is another inconsistency case that could be supported by GDB?

Christophe.