Re: GDB cannot find line info

[Christophe LYON <christophe.lyon@st.com>]

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