Is the ELF file generated by S32 studio a standard one?

[umsteigen]

Dear NXP,

now we use both GreenHill compiler and S32 studio to compile our project based on MPC5745R. We develop one ELF analysis tool according to the standard ELF format. But we found that we can get right information from the ELF file generated by GreenHill but can't get right information out of the ELF file generated byS32 studio.

Is the ELF file generated by S32 studio a standard one? Or what is the format of such ELF file?

Thank you very much.

Regards,

[stanish]

Hello,

Thanks for the update.

Indeed S32DS / GCC compiler supports dwarf v4 by default.

I'd recommend you to switch debug compiler settings to dwarf-2 (-gdwarf-2) and disable gnu debug extension (-gstrict-dwarf)

Hope it helps.

Stan

[stanish]

Hello Cheng,

I've built an elf file and set disassebler to show Debug information:

If I disassemble the generated elf - I get a lots of information about debug section/info - including e.g. DW_TAG_variable 

Contents of the .debug_info section:
Compilation Unit @ offset 0x0:
 Length: 0xf1e (32-bit)
 Version: 4
 Abbrev Offset: 0x0
 Pointer Size: 4
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
 <c> DW_AT_producer : (indirect string, offset: 0x11b9): GNU C 4.9.2 20141030 (Wed Sep 7 17:26:57 MSK 2016 build.sh rev= ELvle) -mcpu=e200z4 -mbig -mvle -mregnames -mhard-float -g3 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections
 <10> DW_AT_language : 1 (ANSI C)
 <11> DW_AT_name : (indirect string, offset: 0x5238): C:/nxp/S32DS_ARM_v1.3/S32DS/FreeMASTER_Serial_Communication_Driver_V2_0/examples/SCI_driver_examples/Common/freemaster_example.c
 <15> DW_AT_comp_dir : (indirect string, offset: 0x3ebe): C:\nxp\S32DS_ARM_v1.3\S32DS\FreeMASTER_Serial_Communication_Driver_V2_0\examples\SCI_driver_examples\MPC57xx\MPC574xP_EVB\Debug
 <19> DW_AT_ranges : 0x0
 <1d> DW_AT_low_pc : 0x0
 <21> DW_AT_stmt_list : 0x0
 <25> DW_AT_GNU_macros : 0x0
 <1><29>: Abbrev Number: 2 (DW_TAG_typedef)
 <2a> DW_AT_name : (indirect string, offset: 0x5204): size_t
 <2e> DW_AT_decl_file : 2
 <2f> DW_AT_decl_line : 22
 <30> DW_AT_type : <0x34>
 <1><34>: Abbrev Number: 3 (DW_TAG_base_type)
 <35> DW_AT_byte_size : 4
 <36> DW_AT_encoding : 7 (unsigned)
 <37> DW_AT_name : (indirect string, offset: 0x136b): unsigned int
 <1><3b>: Abbrev Number: 4 (DW_TAG_base_type)
 <3c> DW_AT_byte_size : 4
 <3d> DW_AT_encoding : 5 (signed)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Could you please try to display it this way? If you are missing a specific information, could you attach short example + elf + description which debug information are you missing?

This will help us to resolve this issue much faster.

Thanks,

Stan

[umsteigen]

Dear Stanislav,

we may find the cause of such problem. The ELF generated by S32 Studio includes the debug information of DWARF 4.0 format. But my tool can only analysis DWARF 2.0.

Please help me to check whether this is true or not.

Regards,

[umsteigen]

Dear Stanish,

I have tried to disassemble an ELF in S32 studio, but it only works for a small size ELF file. It seems the S32 studio cann't disassemble an ELF file with large size.

I also try to disassemble the same file in Codewarrior 2.10 for MPC5xxx.  I compared three ELF files (one is generated by S32 studio for a simple example of MPC5746R

created through the new project wizard, one is generated by Codewarrior 2.10 for MPC5604P, the last one is generated by GreenHill compiler for MPC5746R).

(I have also attached the threeELF files. "Third_Z4_0.elf" is created by S32 Studio. “application.elf" is generated by GreenHill.)

The following content is contained in the disassembling result of Third_Z4_0.elf in S32 studio (in the ".debug_info" section)

------------------------------------------------------------------------------------------------------------------------------------------------------------

Contents of the .debug_info section:

Compilation Unit @ offset 0x0:
Length: 0x8f (32-bit)
Version: 2
Abbrev Offset: 0x0
Pointer Size: 4
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_stmt_list : 0x0
<10> DW_AT_low_pc : 0x11c0000
<14> DW_AT_high_pc : 0x11c026c
<18> DW_AT_name : ../Project_Settings/Startup_Code/startup.S
<43> DW_AT_comp_dir : C:\Users\umsteigen\workspaceS32DS.Power\Third\Third_Z4_0\Debug
<82> DW_AT_producer : GNU AS 2.24.51
<91> DW_AT_language : 32769 (MIPS assembler)
Compilation Unit @ offset 0x93:
Length: 0x161a (32-bit)
Version: 4
Abbrev Offset: 0x14
Pointer Size: 4
<0><9e>: Abbrev Number: 1 (DW_TAG_compile_unit)
<9f> DW_AT_producer : (indirect string, offset: 0x48c6f): GNU C 4.9.2 20141030 (Wed Sep 7 17:26:57 MSK 2016 build.sh rev= ELvle) -mcpu=e200z4 -mbig -mvle -mregnames -mhard-float -g3 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections
<a3> DW_AT_language : 1 (ANSI C)
<a4> DW_AT_name : (indirect string, offset: 0x4814b): ../src/main_Z4_0.c
<a8> DW_AT_comp_dir : (indirect string, offset: 0x51bf0): C:\Users\umsteigen\workspaceS32DS.Power\Third\Third_Z4_0\Debug
<ac> DW_AT_ranges : 0x0
<b0> DW_AT_low_pc : 0x0
<b4> DW_AT_stmt_list : 0xf5
<b8> DW_AT_GNU_macros : 0x0

<1><bc>: Abbrev Number: 2 (DW_TAG_base_type)
<bd> DW_AT_byte_size : 4
<be> DW_AT_encoding : 5 (signed)
<bf> DW_AT_name : int

.... ...

------------------------------------------------------------------------------------------------------------------------------------------------------------

When disassembling with Codewarrior 2.10, the "same" information is shown as following:

------------------------------------------------------------------------------------------------------------------------------------------------------------

00000000: Header
Entry Length : 143
DWARF Version : 2
Offset in .debug_abbrev : 0
Address Size : 4
Address: Tag/Attributes
0000000b: <DW_TAG_compile_unit>
0000000c: DW_AT_stmt_list(00000000)
00000010: DW_AT_low_pc(011c0000)
00000014: DW_AT_high_pc(011c026c)
00000018: DW_AT_name(../Project_Settings/Startup_Code/startup.S)
00000043: DW_AT_comp_dir(C:\Users\umsteigen\workspaceS32DS.Power\Third\Third_Z4_0\Debug)
00000082: DW_AT_producer(GNU AS 2.24.51)
00000091: DW_AT_language(ffff8001)

00000093: Header
Entry Length : 5658
DWARF Version : 4
Offset in .debug_abbrev : 20
Address Size : 4
Address: Tag/Attributes
0000009e: <DW_TAG_compile_unit>
0000009f: DW_AT_producer(00048c6f)
000000a3: DW_AT_language(01)
000000a4: DW_AT_name(0004814b)
000000a8: DW_AT_comp_dir(00051bf0)
000000ac: DW_AT_ranges000000ac: DW_AT_low_pc(00000000)
000000b0: DW_AT_stmt_list000000b0: DW_AT_<unknown:2119>000000b0: <null entry>
000000b1: <null entry>
000000b2: <null entry>
000000b3: <null entry>
000000b4: <null entry>
000000b5: <null entry>
000000b6: <null entry>
<<error>> : invalid .debug_abbrev code : 117

------------------------------------------------------------------------------------------------------------------------------------------------------------

It seems the disassembler of Codewarrior 2.10 cann't recognize "DW_AT_GNU_macros ". But the disassembler of Codewarrior 2.10

should be a standard one because it also generate standard ELF files.

The facts are that the ELF files generated by Codewarrior 2.10 and GreenHill Compiler can be analyzed by our tool. But the ELF file
generated by S32 studio cann't.

And if I disassemble an ELF file generated by Codewarrior 2.10, the following shows some information contained in the ".debug_info" section.

------------------------------------------------------------------------------------------------------------------------------------------------------------

00000000: Header
Entry Length : 277
DWARF Version : 2
Offset in .debug_abbrev : 0
Address Size : 4
Address: Tag/Attributes
0000000b: <DW_TAG_compile_unit>
0000000d: DW_AT_language(00000002)
0000000e: DW_AT_low_pc(00002000)
00000012: DW_AT_high_pc(00002018)
00000016: DW_AT_stmt_list(00000000)
0000001a: DW_AT_macro_info(00000000)
0000001e: DW_AT_name(D:\ECTEK\System\软件设计\项目管理\000_公司内部开发\024_000_SCR泵控制器软件开发\Pump\src\main.c)
0000007d: DW_AT_producer(MW EABI PPC C-Compiler)
00000094: DW_AT_comp_dir(D:\ECTEK\System\软件设计\项目管理\000_公司内部开发\024_000_SCR泵控制器软件开发\Pump\src\)
000000ed: <DW_TAG_base_type>
000000ef: DW_AT_byte_size(00000004)
000000f3: DW_AT_encoding(05)
000000f4: DW_AT_name(int)
000000f8: <DW_TAG_subprogram>
000000fa: DW_AT_low_pc(00002000)
000000fe: DW_AT_high_pc(00002018)
00000102: DW_AT_decl_line(000e)
00000104: DW_AT_decl_file(0008)
00000106: DW_AT_type(000000ed)
0000010a: DW_AT_external(01)
0000010b: DW_AT_frame_base(00000000)
0000010f: DW_AT_name(main)
00000114: DW_AT_sibling(00000118)
00000118: <null entry>

... ...

------------------------------------------------------------------------------------------------------------------------------------------------------------

And if I disassemble an ELF file generated by GreenHill, the following shows some information contained in the ".debug_info" section.

------------------------------------------------------------------------------------------------------------------------------------------------------------

00000476: Header
Entry Length : 767
DWARF Version : 2
Offset in .debug_abbrev : 288
Address Size : 4
Address: Tag/Attributes
00000481: <DW_TAG_compile_unit>
00000482: DW_AT_low_pc(010c04a4)
00000486: DW_AT_high_pc(010c053e)
0000048a: DW_AT_name(src\Application_Layer\BattCD.c)
000004a9: DW_AT_comp_dir(D:\MotorControl)
000004b9: DW_AT_producer(GHS C 2014.1.4 [dual])
000004cf: DW_AT_language(0001)
000004d1: DW_AT_stmt_list(00001755)
000004d5: DW_AT_macro_info(00000d9d)
000004d9: DW_AT_identifier_case(00)
000004da: <DW_TAG_subroutine_type>
000004db: DW_AT_prototyped(01)
000004dc: <null entry>
000004dd: <DW_TAG_subroutine_type>
000004de: DW_AT_prototyped(01)
000004df: <null entry>
000004e0: <DW_TAG_subroutine_type>
000004e1: DW_AT_prototyped(01)
000004e2: <null entry>
000004e3: <DW_TAG_base_type>
000004e4: DW_AT_name(unsigned char)
000004f2: DW_AT_encoding(08)
000004f3: DW_AT_byte_size(01)
000004f4: <DW_TAG_base_type>
000004f5: DW_AT_name(signed char)
00000501: DW_AT_encoding(06)
00000502: DW_AT_byte_size(01)

... ...

 ------------------------------------------------------------------------------------------------------------------------------------------------------------

I think there must be some wrong information contained in the ".debug_info" section of the ELF file generated by S32 studio.

It seems that the "DW_AT_GNU_macros" should be "DW_AT_macro_info"?

We will also try more to check which is wrong.

Regards,

[martin_kovar]

Hi,

S32 Design Studio uses  GNU Build Tools for e200 processors (support VLE and BookE ISA, based on gcc 4.9.2, binutils 2.24 and gdb 7.8.2). GCC compiler generates standard .elf files. Could you please write me back, which information is not correct in the .elf file generated by S32 Design Studio?

Could you please also write me all compiler and linker settings you used?

Regards,

Martin

[umsteigen]

Dear Martin,

is there no further information about my question?

Thank you.

[martin_kovar]

Hello,

I am sorry for delay, but I do not have any answer from application team. I will as my colleague about progress today.

Regards,

Martin

[umsteigen]

Dear Martin,

we analysis the ELF file with the DWARF2.0 format according to the following steps:

(1) enter the "Compilation Units" of ".debug_info" section;

(2) get the "Abbreviation Code" of "debugging information entry";

(3) find the “Abbreviation Table” in section ".debug_abbrev" section with the "Abbreviation code" and the offset in the "Compilation Unit";

(4) get the type of the entry, for example, "DW_TAG_array_type", "DW_TAG_variable", "DW_TAG_structure_type".

But in the ELF file generated by S32 studio, we can find any information of variables in the section ".debug_info" section. And we have no idea how to control the contents of ELF file in S32 studio.

Regards,