This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB cannot find line info


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.






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]