8

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?

djondal
  • 2,521
  • 3
  • 24
  • 40
  • 1
    What linker is that? – Droppy Oct 10 '16 at 12:23
  • The linker is a GCC based linker for tricore microcontroller (tricore-ld). – djondal Oct 10 '16 at 12:24
  • 1
    I think that's important; please edit your tags. – Droppy Oct 10 '16 at 12:25
  • Thanks for your feedback I edited my question. I wish I could create a new tri-core tag but I need at least 1500 reputation points. – djondal Oct 10 '16 at 12:27
  • @djondal: That limit is in place because we don't want people creating random tags "just in case" or other misplaced reasons. It's far harder to clean up a bad tag than to create one, so this is a minimal barrier to entry. And in the case of "tricore", I don't think it would make a useful tag. It appears to be a rather obscure/niche product. – MSalters Oct 10 '16 at 12:39
  • 1
    The Tricore manual is [here](http://www.tasking.com/support/tricore/tc_reference_guide_v2.5.pdf) but I wasn't able to divine any meaning from it. In standard GCC linker scripts, the (expression) is [allowed only for backwards-compatibility and is ignored](https://www.math.utah.edu/docs/info/ld_3.html#SEC13). "P" is not allowed in that case. – jforberg Oct 10 '16 at 12:51

1 Answers1

1

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.

djondal
  • 2,521
  • 3
  • 24
  • 40
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Could you please explain what progbits is? – djondal Oct 20 '16 at 09:17
  • Memory that's initialized from the executable image. Like code and initialized data. `int x = 42;` goes into a progbits section, `int x;` does not. http://stackoverflow.com/questions/9535250/why-is-the-bss-segment-required – Hans Passant Oct 20 '16 at 09:25
  • If I understand correctly, this to differentiate between section containing debug related information and global data from sections containing executable code? – djondal Oct 20 '16 at 09:51
  • Hard to make sense of that comment. You can probably get much more useful answers when edit your question and describe the specific problem you are trying to solve. – Hans Passant Oct 20 '16 at 10:01
  • If found the following explanation : 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. – djondal Oct 20 '16 at 10:03