bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: debug info problem with mn10300-elf-gas


From: Daniel Jacobowitz
Subject: Re: debug info problem with mn10300-elf-gas
Date: Thu, 13 Mar 2003 18:06:09 -0500
User-agent: Mutt/1.5.1i

On Thu, Mar 13, 2003 at 10:46:22PM +0000, Bart Veer wrote:
> >>>>> "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?

Sounds to me like your debug info sections aren't being placed at zero. 
That's a linker script bug, usually... does yours have something like
this:

  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer




reply via email to

[Prev in Thread] Current Thread [Next in Thread]