Source info in discontiguous hand asm files

Source info in discontiguous hand asm files

[Ross Morley]

Hello,

gdb 6.1, as 2.15.92.0.2, gcc 3.4.2 per FC3 distro.

GDB fails to display source file and line info for functions in
two different sections in a hand-assembly source file.

A simple test-case that demonstrates the problem follows:

> cat test.S

    .text
.globl foo
foo:
    nop
    
.globl main

#ifdef DIFFERENT_TEXT_SECTION
    .section .text.with.another.name,"ax",@progbits
#endif
main:
    nop


> gcc test.S -Wa,--gdwarf2
> gdb a.out
...
(gdb) b main
Breakpoint 1 at 0x804834f: file test.S, line 13.
(gdb) b foo
Breakpoint 2 at 0x8048347: file test.S, line 5.
(gdb) quit

> gcc test.S -Wa,--gdwarf2 -DDIFFERENT_TEXT_SECTION
> gdb a.out
...
(gdb) b main
Breakpoint 1 at 0x804834f
(gdb) b foo
Breakpoint 2 at 0x8048347
(gdb)


The DWARF .debug_aranges section seems to have enough information
to deal with this, but GDB doesn't use it.

We'd like to find a fix for this. Any enlightenment is appreciated.


Regards,
Ross Morley
Tensilica, Inc.

Re: Source info in discontiguous hand asm files

[Daniel Jacobowitz]

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?

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

-- 
Daniel Jacobowitz
CodeSourcery

Re: Source info in discontiguous hand asm files

[Ross Morley]

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

Re: Source info in discontiguous hand asm files

[Daniel Jacobowitz]

On Thu, May 04, 2006 at 02:06:08AM -0700, Ross Morley wrote:
> 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.

The section .debug_info contains:

  Compilation Unit @ offset 0x0:
   Length:        52
   Version:       2
   Abbrev Offset: 0
   Pointer Size:  8
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
     DW_AT_stmt_list   : 0      
     DW_AT_name        : text.S 
     DW_AT_comp_dir    : /home/drow/text        
     DW_AT_producer    : GNU AS 2.16.91 
     DW_AT_language    : 32769  (MIPS assembler)

From the DWARF standard:

Compilation unit entries may have the following attributes:

1. Either a DW_AT_low_pc and DW_AT_high_pc pair of attributes or a
   DW_AT_ranges attribute whose values encode the contiguous or
   non-contiguous address ranges, respectively, of the machine
   instructions generated for the compilation unit (see Section 2.16).

   A DW_AT_low_pc attribute may also be specified in combination with
   DW_AT_ranges to specify the default base address for use in location
   lists (see Section 2.5.4) and range lists (see Section 2.16.3).

Now, there's a "may" there, so the compilation unit clearly isn't
required to have either.  But GDB definitely expects a compilation unit
to have one or the other.  It does not implement .debug_aranges
support.

So, your options are to use .debug_aranges to look up textlow/texthigh
for compilation units that don't have a PC range, or to modify gas to
emit DW_AT_ranges.  The latter is likely to be easier.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Source info in discontiguous hand asm files

[Ross Morley]

Daniel Jacobowitz wrote:

>On Thu, May 04, 2006 at 02:06:08AM -0700, Ross Morley wrote:
>  
>
>>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.
>>    
>>
>
>The section .debug_info contains:
>
>  Compilation Unit @ offset 0x0:
>   Length:        52
>   Version:       2
>   Abbrev Offset: 0
>   Pointer Size:  8
> <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
>     DW_AT_stmt_list   : 0      
>     DW_AT_name        : text.S 
>     DW_AT_comp_dir    : /home/drow/text        
>     DW_AT_producer    : GNU AS 2.16.91 
>     DW_AT_language    : 32769  (MIPS assembler)
>
>>From the DWARF standard:
>
>Compilation unit entries may have the following attributes:
>
>1. Either a DW_AT_low_pc and DW_AT_high_pc pair of attributes or a
>   DW_AT_ranges attribute whose values encode the contiguous or
>   non-contiguous address ranges, respectively, of the machine
>   instructions generated for the compilation unit (see Section 2.16).
>
>   A DW_AT_low_pc attribute may also be specified in combination with
>   DW_AT_ranges to specify the default base address for use in location
>   lists (see Section 2.5.4) and range lists (see Section 2.16.3).
>  
>
Ah, DW_AT_ranges is in DWARF3, not DWARF2, so it's relatively new.

>Now, there's a "may" there, so the compilation unit clearly isn't
>required to have either.  But GDB definitely expects a compilation unit
>to have one or the other.  It does not implement .debug_aranges
>support.
>  
>
That I knew. And now it seems there's a better way.

>So, your options are to use .debug_aranges to look up textlow/texthigh
>for compilation units that don't have a PC range, or to modify gas to
>emit DW_AT_ranges.  The latter is likely to be easier.
>
>  
>
Agreed.
Thanks for your help.

Ross