CODEWITHSUNDEEP
cgcclinker
tll
tll

Reputation: 397

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

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?

Upvotes: 15

Views: 38643

Answers (4)

Darkproduct
Darkproduct

Reputation: 1245

On embedded hardware/micro controllers it is used to read and write data to the flash memory.

This is useful for:

  1. Persistent data even on power cycles.
  2. Overwrite the program in flash and do firmware updates.
  3. Make a read-only data storage.

Here some examples on SO for STM32:

Upvotes: 0

aghast
aghast

Reputation: 15310

Years later, I'm going to add a specific detail because it's worth writing down.

If you create your own section, you can manage it yourself. In particular, you can use preprocessor macros to insert certain data items into your special section. If the only thing that uses that special section is your preprocessor macros, then you have the ability to create a data structure in a distributed fashion.

What does this mean? It means you can write a preprocessor macro like ADD_VAR_TO_SPECIAL_SECTION(...) and concatenate a bunch of different values in random order into what amounts to an array (or just a big old pile, if they aren't all the same type) in your section.

This gives you the ability to create a (randomly-ordered) array of data at compile time. There is no initialization, no registration, no overhead. You just compile and link your code, and all the macros that were in all the different source files have added all their values into one big array.

How can you use this? Create a bunch of "modules." Register the init functions and destroy functions in an ad-hoc array. Process the array at startup time. (You can add some kind of topological sort if you need to.) You don't need to have a master list of modules anywhere, it gets built automatically. Or, create a macro to register unit test functions into a test suite. Again, it creates an ad-hoc list with no "registration" required.

Upvotes: 4

FrankH.
FrankH.

Reputation: 18227

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.

Upvotes: 3

torek
torek

Reputation: 488461

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).

Upvotes: 14

Related Questions