In GCC, the MEMORY command describes the location and size of blocks of memory in the target. The command must be used this way.
MEMORY
{
name [(attr)] : ORIGIN = origin, LENGTH = len
...
}
Now, I have a linker file used by the linker (a GCC based linker for Infineon Tricore microcontrollers, tricore-ld) defining a RAM memory section this way:
MEMORY
{
ram (w!xp): org = 0x70000000, len = 32k
...
}
Could you explain what 'p' means in (w!xp)? What does 'p' mean in general?
The MEMORY command describes the location and size of blocks of memory in the target. You can use it to describe which memory regions may be used by the linker, and which memory regions it must avoid. You can then assign sections to particular memory regions.
A linker memory file contains commands to tell the linker how to allocate the target memory. The linker memory file is usually named flash.
The Linker Script is a text file made up of a series of Linker directives which tell the Linker where the available memory is and how it should be used. Thus, they reflect exactly the memory resources and memory map of the target microcontroller.
Section alignment with the linkerThe linker permits ELF program headers and output sections to be aligned on a four-byte boundary regardless of the maximum alignment of the input sections. This enables armlink to minimize the amount of padding that it inserts into the image.
Not a standard linker script, not unusual for a custom micro-controller target of course. Perhaps forked a long time ago. It however can be easily reverse-engineered, GCC has always used the ELF format for object files. Google "elf section attributes", out pops this hit, pretty helpful here.
So you got alloc, exec, write, progbits. Aha, p == progbits. So (w!xp) surely should be interpreted as "section is writable, not executable, initial data is stored in the executable image".
Nothing very special, that's the traditional .data section in a C program. Compare to .bss, not p.
Info added by OP:
From this presentation on the UNIX ELF Format:
PROGBITS: This holds program contents including code, data, and debugger information.
NOBITS: Like PROGBITS. However, it occupies no space.
SYMTAB and DYNSYM: These hold symbol table.
STRTAB: This is a string table, like the one used in a.out.
REL and RELA: These hold relocation information.
DYNAMIC and HASH: This holds information related to dynamic linking.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With