Re: debug info problem with mn10300-elf-gas

[Nick Clifton]

Hi Bart,

> compiled using "mn10300-elf-g++ -c -g -O2 bin_sem0.cxx"
> 
> "mn10300-elf-objdump -g" on the resulting object file fails with
> "no recognized debugging information"

Which is to be expected since objdump does not understand DWARF debug
information.  If you had compiled the test case with:

  mn10300-elf-g++ -c -gstabs -O2 bin_sem0.cxx

then you would find that objdump can cope.


> "mn10300-read-elf --debug-dump=info bin_sem0.o" gives a bit more
> information:
> 
>   The section .debug_info contains:
> 
>   readelf: Warning: Skipping unexpected symbol type 0
>     Compilation Unit @ 0:
>      Length:        65
>      Version:       2
>      Abbrev Offset: 0
>      Pointer Size:  4
>    <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
>        DW_AT_stmt_list   : 0  
>        DW_AT_high_pc     : 0 0        
>        DW_AT_low_pc      : 0 0        
>        DW_AT_name        : (indirect string, offset: 0x0): GNU C++ 3.2.1
>        DW_AT_comp_dir    : (indirect string, offset: 0x0): GNU C++ 3.2.1
>        DW_AT_producer    : (indirect string, offset: 0x0): GNU C++ 3.2.1
>        DW_AT_language    : 4  (C++)
>   ...
> 
> It appears that all string offsets in the debug info have been set to
> 0.

The first thing to note is that there are a lot of pending relocations
on the .debug_info section, so that its contents cannot be considered
to be ready for input to a debugger or debug-info-parser tool:

    % mn10300-elf-objdump -r bin_sem0.o
  [snip]
    RELOCATION RECORDS FOR [.debug_info]:
    OFFSET   TYPE              VALUE
    00000006 R_MN10300_32      .Ldebug_abbrev0
    0000000c R_MN10300_32      .Ldebug_line0
    00000010 R_MN10300_32      .Letext0
    00000014 R_MN10300_32      .Ltext0
    00000018 R_MN10300_32      .LASF0
    0000001d R_MN10300_32      .LASF1
    00000021 R_MN10300_32      .LASF2
    00000027 R_MN10300_32      .LASF3
    0000002d R_MN10300_32      .LFB3
    00000031 R_MN10300_32      .LFE3
  [snip]

This is presumably why the offsets are zero - they have not yet been
relocated.

> The resulting .o files can be linked to give a functional executable
> but the final debug info is bogus: mn10300-elf-gdb reports
> ".DW_FORM_strp pointing outside of .debug_str section".

Ok - now this should not be happening.  Using your test program
however, it appears that the correct information is being generated:

    % mn10300-elf-ld bin_sem0.o --defsym _start=0
    % mn10300-elf-readelf -wi a.out

    The section .debug_info contains:

    Compilation Unit @ 0:
     Length:        52
     Version:       2
     Abbrev Offset: 0
     Pointer Size:  4
   <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
       DW_AT_stmt_list   : 0
       DW_AT_high_pc     : 0x2 2
       DW_AT_low_pc      : 0 0
       DW_AT_producer    : (indirect string, offset: 0x40): GNU C++ 3.4 
20030313 (experimental)
       DW_AT_language    : 4      (C++)
       DW_AT_name        : (indirect string, offset: 0xa): bin_sem0.cxx
       DW_AT_comp_dir    : (indirect string, offset: 0x11): 
/home/nickc/work/builds/egcs/mn10300-elf/tests
   <1><25>: Abbrev Number: 2 (DW_TAG_subprogram)
       DW_AT_external    : 1
       DW_AT_name        : (indirect string, offset: 0x0): cyg_start
       DW_AT_decl_file   : 1
       DW_AT_decl_line   : 3
       DW_AT_low_pc      : 0 0
       DW_AT_high_pc     : 0x2 2
       DW_AT_frame_base  : 1 byte block: 59       (DW_OP_reg9; )
  
Do you have a test case that reproduces the ".DW_FORM_strp pointing
outside of .debug_str section" problem ?

Cheers
        Nick