• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 54 subscribers
  • Views 1351 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler: Mapping of sections to segments

Guy Mardiks
Genius 4135 points

Tool/software: TI C/C++ Compiler

Hello,

Below it an output of my resulted ELF file after compiling and linking with TI tools v16.9.2.LTS.

I am a bit confused with this output - why the different segments keep contain the same sections (why sections are mapped to several/all segments)? what is the mapping logic from sections to segments that makes this behavior?

How come the .text section is on the same segment as sections which is basically data  (in this case uninitialized data but i have also seen a build in which .text and .data where on the same segment)?

Why does the stack section is NOT marked as allocated?  how does the stack defined area is reserved?

.stack,.sysmem,.ocmc_common .sar .ocmc_global_info .imgArea .buffersArea,.ipu2 --> are NOLOAD type sections 

.testsec -> a NOINIT type section which holds an initialized global variable  (loaded with program load but does not go through C initialization routine)


Elf file type is EXEC (Executable file)
Entry point 0x9
There are 10 program headers, starting at offset 1209336

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000034 0x00000000 0x00000000 0x00050 0x00058 R E 0x4
LOAD 0x000084 0x00000058 0x00000058 0x001e4 0x001e4 R E 0x4
LOAD 0x000400 0x00001000 0x00001000 0x00000 0x00220 RW 0x400
LOAD 0x000400 0x00001220 0x00001220 0x00018 0x00018 R E 0x2
LOAD 0x000418 0x1fa04000 0x1fa04000 0x0aa1c 0x0aa1c R E 0x4
LOAD 0x00b000 0x1fc04000 0x1fc04000 0x00000 0x14328 RW 0x1000
LOAD 0x00b000 0x1fc18328 0x1fc18328 0x01e88 0x01e88 R 0x4
LOAD 0x00ce88 0x1fc1b1b0 0x1fc1b1b0 0x00000 0x00800 RW 0x4
LOAD 0x00ce88 0x1fc1b9b0 0x1fc1b9b0 0x00400 0x00400 RW 0x4
LOAD 0x00d288 0x1fc1bdb0 0x1fc1bdb0 0x00bd8 0x00bd8 R 0x8

Section to Segment mapping:
Segment Sections...
00 .ocmc_common .sar .ocmc_global_info .imgArea .buffersArea .ipu1 .ipu_c0_resetVec .ipu2 .rodata .phy_ram_sec .sysmem .stack .TI.persistent
01 .ocmc_common .sar .ocmc_global_info .imgArea .buffersArea .ipu_c1_resetVec .ipu2 .main_boot_area_sec .phy_ram_sec .sysmem .stack .TI.persistent
02 .ocmc_common .sar .ocmc_global_info .imgArea .buffersArea .ipu2 .intvecs .phy_ram_sec .sysmem .stack .TI.persistent
03 .ocmc_common .sar .ocmc_global_info .imgArea .buffersArea .ipu2 .vir_ram_sec .phy_ram_sec .sysmem .stack .TI.persistent
04 .ocmc_common .sar .ocmc_global_info .imgArea .buffersArea .ipu2 .text .phy_ram_sec .sysmem .stack .TI.persistent
05 .ocmc_common .sar .ocmc_global_info .imgArea .buffersArea .ipu2 .data .bss .phy_ram_sec .sysmem .stack .TI.persistent
06 .ocmc_common .sar .ocmc_global_info .imgArea .buffersArea .ipu2 .const .phy_ram_sec .sysmem .stack .TI.persistent
07 .ocmc_common .sar .ocmc_global_info .imgArea .buffersArea .ipu2 .TI.noinit .phy_ram_sec .sysmem .stack .TI.persistent
08 .ocmc_common .sar .ocmc_global_info .imgArea .buffersArea .ipu2 .phy_ram_sec .sysmem .stack .testsec .TI.persistent
09 .ocmc_common .sar .ocmc_global_info .imgArea .buffersArea .ipu2 .cinit .phy_ram_sec .sysmem .stack .TI.persistent

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

There are 38 section headers, starting at offset 0x127538:

Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .ocmc_common NOBITS 4037d000 00de60 000358 00 0 0 4
[ 2] .sar NOBITS 4ae26000 00de60 000018 00 0 0 4
[ 3] .ocmc_global_ NOBITS 4035d000 00de60 005b00 00 0 0 4
[ 4] .imgArea NOBITS f9600000 00de60 2000000 00 0 0 1
[ 5] .sblBuffersArea NOBITS 00000000 000000 000000 00 0 0 1
[ 6] .ipu1 PROGBITS 00000000 000034 000050 00 AX 0 0 4
[ 7] .ipu_c0_resetVec NOBITS 00000050 000084 000008 00 A 0 0 1
[ 8] .ipu_c1_resetVec PROGBITS 00000058 000084 000008 00 A 0 0 4
[ 9] .ipu2 NOBITS ffa00000 00de60 004000 00 0 0 1
[10] .main_boot_ar PROGBITS 00000060 00008c 0001dc 00 AX 0 0 4
[11] .intvecs NOBITS 00001000 000400 000220 00 WA 0 0 1024
[12] .vir_ram_sec PROGBITS 00001220 000400 000018 00 AX 0 0 2
[13] .text PROGBITS 1fa04000 000418 00aa1c 00 AX 0 0 4
[14] .data NOBITS 1fc15028 01c028 003300 00 WA 0 0 4
[15] .const PROGBITS 1fc18328 00b000 001e88 00 A 0 0 4
[16] .rodata NOBITS 00000000 00de60 000000 00 A 0 0 1
[17] .cinit PROGBITS 1fc1bdb0 00d288 000bd8 00 A 0 0 8
[18] .bss NOBITS 1fc04000 00b000 011028 00 WA 0 0 4096
[19] .TI.noinit NOBITS 1fc1b1b0 00ce88 000800 00 WA 0 0 4
[20] .phy_ram_sec NOBITS 00000000 000000 000000 00 0 0 1
[21] .sysmem NOBITS 1fc1a1b0 00de60 001000 00 0 0 8
[22] .stack NOBITS 55024000 00de60 001000 00 0 0 8
[23] .testsec PROGBITS 1fc1b9b0 00ce88 000400 00 WA 0 0 4
[24] .TI.persistent NOBITS 00000000 000000 000000 00 0 0 1
[25] .debug_info PROGBITS 00000000 00de60 07efc2 00 0 0 1
[26] .debug_line PROGBITS 00000000 08ce22 01a3cd 00 0 0 1
[27] .debug_frame PROGBITS 00000000 0a71ef 004c81 00 0 0 1
[28] .debug_abbrev PROGBITS 00000000 0abe70 012514 00 0 0 1
[29] .debug_str PROGBITS 00000000 0be384 018963 00 0 0 1
[30] .debug_aranges PROGBITS 00000000 0d6ce7 001fa8 00 0 0 1
[31] .debug_pubnames PROGBITS 00000000 0d8c8f 00d1f6 00 0 0 1
[32] .debug_pubtypes PROGBITS 00000000 0e5e85 005a60 00 0 0 1
[33] .ARM.attributes ARM_ATTRIBUTES 00000000 0eb8e5 000058 00 0 0 0
[34] .symtab SYMTAB 00000000 0eb940 0283c0 10 36 9153 0
[35] .TI.section.flags PROGBITS 00000000 113d00 00002e 00 0 0 0
[36] .strtab STRTAB 00000000 113d2e 0134f7 01 S 0 0 0
[37] .shstrtab STRTAB 00000000 127225 0001d1 01 S 0 0 0
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)

Thanks

Guy

  • 0
    TI__Guru* 84285 points
    I suspect the dump utility is confused about which sections belong to segments.
    Please dump the same file with ofd2000/ofd430/armofd, depending on which toolset you use.:
    ofd2000 --verbose --obj_display=none,segments app.out
  • 0 in reply to Archaeologist
    Genius 4135 points
    Hi, Thanks you.
    You were right - the output from armofd indeed makes much more sense.

    But regarding this - for the A15 which is using the gnu arm-none-eabi tools, the output makes sense but i can see the .data and .text are on the same segment - do you know if this suppose to happen / why? (also there is a case in which the same section can be seen on several segments - no idea why - but in the gnu case it seems that one segment resides in another when looking at the addresses ).

    Also according to ELF docs if memSize > FileSize the left over is supposed to be initialized to zero. - for the TI tools a noload section for example is a non allocated section and thus does not add up to the memSize (and is not associated with any segment) but in another sense it is still getting allocated in memory.
    on the gnu tools a noload section must have the allocate flag (otherwise it will be overlayed) and thus adds to the segment's memSize but it seems gnu tools do not initialize the reset of memSize to zero (it is specifically done only for the bss section). does all of this makes sense ? does the ELF description about the allocate flag and handling memSize>FileSize is only a suggestion and left for compiler/linker implementation choice?

    Thanks
    Guy
  • 0 in reply to Guy Mardiks
    TI__Guru**** 252280 points

    Guy Mardiks said:
    i can see the .data and .text are on the same segment - do you know if this suppose to happen / why?

    If the sections are contiguous in memory, then it is good for them to be in the same segment.  It is likely your loader goes through the file segment by segment.  Fewer segments are better.

    As for the paragraph that starts ...

    Guy Mardiks said:
    Also according to ELF docs if memSize > FileSize the left over is supposed to be initialized to zero.

    I suspect you are getting a bit lost in the details of the ELF format, and how the loader handles it.  Just for now, forget you know anything about ELF.  What is the overarching problem you want to solve?  What is happening now, and how do you want it to change?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4135 points
    Thanks.
    I was just confused since the behavior of TI tools and gnu tools is different even though they both end up creating an ELF format file which (i assumed) suppose to match some common standard, but it seems any developer does how he sees fit.

    Thanks
    Guy
  • 0 in reply to Guy Mardiks
    TI__Guru* 84285 points
    Yes, both the TI tools and the GNU tools are supposed to follow the ELF format standard, which defines certain behavior that must be the same. However, the choice of which sections go into which segments is entirely implementation-specific. GNU tools tend use a minimal set of segments, one which is read-only, one which is read-write, and possibly a stack segment. This works well on general-purpose machines with virtual memory. However, the TI tools tend to create multiple segments because embedded devices often have complicated memory maps and no MMU.
  • 0 in reply to Archaeologist
    Genius 4135 points

    Hi,
    Thanks a lot for the information