topic Re: Duplicate Addresses in Elf generated from S32DS/PPC in S32 Design Studio

Duplicate Addresses in Elf generated from S32DS/PPC

ronlewis — Mon, 30 Jan 2017 21:34:58 GMT

There seems to be a error in the elf file generation in S32DS power-pc. A dump of an elf generated for the S32DS has duplicate entries for the same address:

<1><3f1>: Abbrev Number: 9 (DW_TAG_subprogram)
<3f2> DW_AT_external : 1
<3f2> DW_AT_name : (indirect string, offset: 0x2f9): app_init
<3f6> DW_AT_decl_file : 1
<3f7> DW_AT_decl_line : 40
<3f8> DW_AT_prototyped : 1
<3f8> DW_AT_low_pc : 0x5300
<3fc> DW_AT_high_pc : 0x148
<400> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<402> DW_AT_GNU_all_tail_call_sites: 1
<402> DW_AT_sibling : <0x469>

This exerpt is from an dump using the readelf utility:

readelf.exe --debug-dump=info MyApp.elf

Original Attachment has been moved to: 5644_Test.elf.zip

Re: Duplicate Addresses in Elf generated from S32DS/PPC

martin_kovar — Wed, 01 Feb 2017 14:47:46 GMT

Hello,

could you please upload here the elf you mentioned in your post?

Regards,

Martin

Re: Duplicate Addresses in Elf generated from S32DS/PPC

ronlewis — Wed, 01 Feb 2017 16:36:33 GMT

Martin,

I uploaded an example elf that exhibits the issue. This was taken from a base project targeting the 5644a.

-Ron

Re: Duplicate Addresses in Elf generated from S32DS/PPC

stanish — Tue, 07 Feb 2017 17:02:43 GMT

Hi Ron,

I'm not expert on ELF/DWARF spec but I don't think this is an issue.

<3f8> does not represent an address - it's rather an offset within .debug_info section.

It's quite common that a flag "shares" the same offset with other tags.

In fact If I disassembly your project I can find a different "overlap" in .debug_info e.g.:

 <1><f3>: Abbrev Number: 4 (DW_TAG_subprogram)
    <f4>   DW_AT_external    : 1
    <f4>   DW_AT_name        : (indirect string, offset: 0xcee): main
    <f8>   DW_AT_decl_file   : 1
    <f9>   DW_AT_decl_line   : 10
    <fa>   DW_AT_prototyped  : 1
    <fa>   DW_AT_type        : <0xad>
    <fe>   DW_AT_low_pc      : 0x4044
    <102>   DW_AT_high_pc     : 0x28
    <106>   DW_AT_frame_base  : 1 byte block: 9c         (DW_OP_call_frame_cfa)
    <108>   DW_AT_GNU_all_tail_call_sites: 1
    <108>   DW_AT_sibling     : <0x11b>‍‍‍‍‍‍‍‍‍‍‍‍

In fact the block above refers to DW_TAG_subprogram (Abbreviation table #4)

  4      DW_TAG_subprogram    [has children]
    DW_AT_external     DW_FORM_flag_present
    DW_AT_name         DW_FORM_strp
    DW_AT_decl_file    DW_FORM_data1
    DW_AT_decl_line    DW_FORM_data1
    DW_AT_prototyped   DW_FORM_flag_present
    DW_AT_type         DW_FORM_ref4
    DW_AT_low_pc       DW_FORM_addr
    DW_AT_high_pc      DW_FORM_data4
    DW_AT_frame_base   DW_FORM_exprloc
    DW_AT_GNU_all_tail_call_sites DW_FORM_flag_present
    DW_AT_sibling      DW_FORM_ref4
    DW_AT value: 0     DW_FORM value: 0‍‍‍‍‍‍‍‍‍‍‍‍‍

According to the dwarf spec flag is (http://dwarfstd.org/doc/DWARF4.pdf

"A flag is represented explicitly as a single byte of data (DW_FORM_flag) or implicitly (DW_FORM_flag_present). In the first case, if the flag has value zero, it indicates the absence of the attribute; if the flag has a non-zero value, it indicates the presence of the attribute. In the second case, the attribute is implicitly indicated as present, and no value is encoded in the debugging information entry itself."

My understanding is that the second part describes what is going on here. The flag is implicitly indicated as present in the DW_TAG_subprogram definition and therefore there is no single byte value present in .debug_info which would increase the offset for the next item DW_AT_type.

Does this specific issue cause any problem on your side while e.g. debugging?

Hope it helps.

Stan