Re: debug info problem with mn10300-elf-gas

[Bart Veer]

>>>>> "Nick" == Nick Clifton <address@hidden> writes:

    <snip>

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

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

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

    Nick>     The section .debug_info contains:

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

Every eCos testcase shows this problem. For example:

 $  % mn10300-elf-readelf --debug-dump=info bin_sem0 | more
 The section .debug_info contains:

  Compilation Unit @ 0:
   Length:        11741
   Version:       2
   Abbrev Offset: 0
   Pointer Size:  4
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
     DW_AT_stmt_list   : 448379 
     DW_AT_name        : (indirect string, offset: 0x7e67c): <offset is too 
big>        
     DW_AT_producer    : (indirect string, offset: 0x7d119): <offset is too 
big>        
     DW_AT_language    : 4      (C++)
 <1><19>: Abbrev Number: 2 (DW_TAG_enumeration_type)
     DW_AT_sibling     : <4a>   
     DW_AT_name        : (indirect string, offset: 0x846c0): <offset is too 
big>        
     DW_AT_byte_size   : 4      
     DW_AT_decl_file   : 2      
     DW_AT_decl_line   : 209    
 <2><25>: Abbrev Number: 3 (DW_TAG_enumerator)
     DW_AT_name        : (indirect string, offset: 0x7e2c3): <offset is too 
big>        
     DW_AT_const_value : -1     
 ...

Going back from the executable to the object files seemed to indicate
problems with those, hence I thought the problem was in the assembler.
I am somewhat surprised that the mn10300 object files still contain
relocations for the debug strings. When I looked at arm-elf object
files for comparison, the assembler had fixed up the references to the
strings and there was no need for relocation entries. Also, when I
looked at gas' tc-mn10300.h it has a comment

  /* Fixup debug sections since we will never relax them. ... */

which also implied to me that the debug sections should be fixed up by
the assembler, not left to the linker.

However, if it is valid for the .o files to contain relocation entries
for this debug info then I guess the next step is to explore what is
happening in the linker and how it is ending up with these bogus
offsets.

Hmmm, offset 0x7e67c. According to mn10300-elf-readelf -S has an
address of 0x7cb52 and a size of 0x850f. Absolute vs. section relative
offsets, or something like that?

Bart