__attribute__((section("name"))) usage?

Question

I have ran through code that use _ attribute _((section("name")). I understand that for gcc compiler this allows you to tell the linker to put the object created at a specific section "name" (with "name" absolute address declared in a linker file).

What is the point of doing this instead of just using the .data section?

Solution 1

There are many possible uses. [Edit to add note: this is just a sample of uses I've seen myself or considered, not a complete list.]

The Linux kernel, for instance, marks some code and data sections as used only during kernel bootstrap. These can be jettisoned after the kernel is running, reclaiming the space for other uses.

You can use this to mark code or data values that need patching on a particular processor variant, e.g., with or without a coprocessor.

You can use it to make things live in "special" address spaces that will be burned to PROM or saved on an EEPROM, rather than in ordinary memory.

You can use it to collect together code or data areas for purposes like initialization and cleanup, as with C++ constructors and destructors that run before the program starts and when it ends, or for using shorter addressing modes (I don't know how much that would apply on ARM as I have not written any ARM code myself).

The actual use depends on the linker script(s).

Solution 2

From a usecase point of view, there are lots of different types of .data, like:

• data local to a specific CPU and/or NUMA node
• data shared between contexts (like user/kernelspace, as are the .vdso or vsyscall pages. Or, another example, bootloader and kernel)
• readonly data or other data with specific access mode/type restrictions (say, cacheability or cache residency - the latter can be specificed on some ARM SoCs)
• data that persists "state transitions" (such as hibernation image loads, or crash kernel / fast reboot reinitializations)
• data with specific lifetimes/lifecycles (only used in specific stages during boot or during operation, write-once data)
• data specific to a particular kernel subsystem or particular kernel module
• "code colocated" data (addressing offsets in x64 are plus/minus 2GB so if you want RIP-relative addressing, the data must be within that range of your currently executing code)
• data mapped to some specific hardware register space VA range

So in the end it's often about attributes (the word here used in a more generic sense than what __attribute__(...) allows you to state from within gcc sourcecode. Whether another section is needed and/or useful is ... in the eye of the beholder - the system designer, that is.

The availabiltiy of the section attribute, therefore, allows for flexibility and that is, IMHO, a good thing.

Comments

[artless noise]

Other uses are hot and cold for cache locality. You may also partition functionality, like interrupt handling, scheduling, etc. Even though routine/functionality may be in one 'C' file, the typical execution path can benefit by grouping call stacks. Some code may execute from flash or internal ram. These resource maybe limited, etc.

[tll]

@torek On your last point about collecting code/data areas for initialization/cleanup, this essentially means that I can choose to include code before the program starts, but during runtime instead of compile time? Sort of like a better version of #ifdef?

[torek]

I'm not sure precisely what you're asking here. If you wrote a linker script that included some sections and discarded others, you could include or exclude pieces at link time. Doing stuff at run time requires co-ordinating your linker script and your run-time code, and is much harder.

[tll]

That was a bad question on me. I understand it now when you say this is done during link time. Thank you.