Re: Source info in discontiguous hand asm files

Ross Morley
2006-05-04T09:07:22Z

Daniel Jacobowitz wrote:

>On Wed, May 03, 2006 at 06:22:57PM -0700, Ross Morley wrote:
>
>
>>Hello,
>>
>>gdb 6.1, as 2.15.92.0.2, gcc 3.4.2 per FC3 distro.
>>
>>
>
>All of these are fairly old versions. Have you looked at the generated
>debug information? Is it correct, or not?
>
>
Yes, it is correct, though not as extensive as it could be.
In the case where there are multiple ranges of text in a compilation
unit, DA_AT_{low,high}_pc is omitted from the CU per DWARF spec.
Where there is only one range of text, those are present and correct.
The assembler doesn't add function-specific info.
There is info in the aranges table to associate the ranges with the
compilation unit, so a scan of that table could provide it.

I'm reluctant to say much about my incomplete analysis, given my
lack of familiarity with GDB handling of symbols and debug info.
However, at risk of having missed something, here's what I found.

I've stepped through the lookup of the symtab and there's no
source file info associated with the symbol. To find out why,
I've stepped through the reading of the dwarf info. The relevant
code is in dwarf2read.c, function dwarf2_build_psymtabs_hard(). The
psymtab for the CU ends up not having its 'textlow' and 'texthigh' set,
so they remain 0x0 after the DWARF is read. I don't know enough about
the process of building the symtabs to be sure, but I suspect this
leads to the lack of source file info associated with the symbols
in this CU.

I've looked at GDB 6.4 sources and it's the same, so I'd be
surprised if you can't reproduce this at top of trunk. The test
case is very easy to try if you have a top of trunk build.

>>The DWARF .debug_aranges section seems to have enough information
>>to deal with this, but GDB doesn't use it.
>>
>>
>
>I'm not sure how .debug_aranges comes into this. That's used to
>describe the range of the compilation unit DIEs and shouldn't affect
>.debug_line.
>
>
Somehow the debug line info doesn't make it into the symbol table,
perhaps because the psymtab is not associated with the correct range
(again, I'm guessing, not being familiar with this stuff).

There is other DWARF info that the assembler could include but doesn't
(compiler-generated DWARF does, so this problem doesn't show there).
However a fix there would require end users to edit their source,
which is why I'm being asked to solve it in GDB. There is enough info
in the DWARF to determine which source file addresses in these ranges
belong to, so the expectation is that GDB should be able to figure it
out. If that's not the case, then the assembler has a problem.

Thanks for any insight.

Ross