Linker wish list feature: feasable?

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've pretty much accepted that the features of the embedded-system-specific linkers of the 1980s won't ever be restored, but here's something that I wouldn't expect to be all that difficult to do, and could be pretty useful (well, to my warped style of programming, anyway): Allow (via some suitable commandline switch or switches) the linker to manufacture two defined symbols giving the base address and size of each named section it finds. The symbols should come with some appropriately bizzare prefix that keeps them from colliding with user & library functions, of course.

The existing WinAVR linker script manufactures a few of these symbols (as near as I can decypher the script anyway) explicitly, describing the initializers for the .data section, constructor lists, size of .bss, etc), but it's done explicitly, and extending those mechanisms to allow programmers to use some of the same techniques that the environment does requires fiddling with the linker script(s), which is (for good reasons) discouraged.

Internally, the linker knows how big the sections are, and where it's decided to put them. And I can't believe that the systems running the tools can't cope with the handful of extra symbols. How hard would it be to get the linker to cough up programmer-referenceable symbols for the sections?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want this why not do it with your own linker script? Just take a copy of the .x that would be use automatically and the -T a local copy that you have modified to include your private sections together with their start/end labels.

Rather than --section-starts on the command line use "AT" in the linker script to place the section.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
If you want this why not do it with your own linker script? Just take a copy of the .x that would be use automatically and the -T a local copy that you have modified to include your private sections together with their start/end labels.

Rather than --section-starts on the command line use "AT" in the linker script to place the section.

I think it's even easier than that.
An input file that is not an object file is taken to be an addition to the linker script.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

An input file that is not an object file is taken to be an addition to the linker script.

Wow that counts as my "learn something new every day" entry for today!

One other thing I was thinking of was the way in which avr-obcopy can be used to convert this "data" in binary form to linkable ELF and auto-assigns names to it. I'm not sure if it generates both start and end labels or start label plus length?

EDIT: looks possible:

E:\avr[i386_vc]>avr-objcopy -I binary -O elf32-avr foo.bin foo.o

E:\avr[i386_vc]>avr-nm foo.o
0000005e D _binary_foo_bin_end
0000005e A _binary_foo_bin_size
00000000 D _binary_foo_bin_start

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for your responses, but I see I ought to have given a clearer description of what I'm after. I wasn't asking for some clever way for source code to control where the linker places sections; I was suggesting that the linker ought to be able to resolve references that user sourcecode make to the beginning addresses of sections and to the sizes of sections.

Maybe an example... So, here's a function that's part of a library module, whose purpose is to perform some action on every instance of some specific kind of object that the overall application may declare. If I were conversant with the cool software trends, I could describe this as a "Visitor Pattern", I suppose. Anyway, the point is that the service-performing code can literally be built into a precompiled, classic-definition library module, looking someting like this:

#include "thing.h"
#define THINGQTY ( _SECLEN_text_tables_things / sizeof(Thing) )

void serviceThings(void)
{
    Thing *thingTable = (Thing *) _SECBASE_text_tables_things; 
    for (int scan = THINGQTY; 0 <= --scan;)
    {
        thingTable[scan].performService();
    }
}

Now, an application *incorporating* the above library method could be built with an arbitrary collection of user modules that are free to instantiate as many "Thing" structures as they want, kind of like so:

#include "thing.h"
#define THINGATTR __attribute__((section(".text.tables.things")))
// ...
Thing aThing THINGATTR = { /* inits */ };

With the slight modification to the standard liner script that says that all ".text.*" sections will be sorted, the linker will collect up all the instances of Thing structures in however many modules the application has into the text.tables.things section. Effectively, it is as if there were a

Things[] = { {aThing}, {bThing}... };

array built into the library sourcecode.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Levenkay wrote:
Thank you for your responses, but I see I ought to have given a clearer description of what I'm after. I wasn't asking for some clever way for source code to control where the linker places sections; I was suggesting that the linker ought to be able to resolve references that user sourcecode make to the beginning addresses of sections and to the sizes of sections.
I got it.
You can generate your own symbols the same way the linker does.
You don't need to replace the linker script.
An add-on will do the trick.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Beware, behaviour of those add-ons is poorly documented thus prone to change.

I was caught by such change between the '2007 and '2009 editions of WinAVR.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
Beware, behaviour of those add-ons is poorly documented thus prone to change.

I was caught by such change between the '2007 and '2009 editions of WinAVR.

What was the change?

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Michael,

I honestly don't remember. I was pointed onto that change here on avrfreaks - I wouldn't notice otherwise as except for playing I consistently use the 2007 vintage. I was trying to search for that thread but can't find details except of link on this file, which supposedly is result of my then experiments.

OT: These days, I am repeatedly (also in job) confronted with my past (from 2 years ago) work to find out I don't remember and even don't understand (e.g. the comments) and have literally to hack out the detailed working of things. Very embarrassing.

Jan

PS. Levenkay, while searching for the abovementioned thread, I found this one... you might perhaps re-read Joerg's concluding post, especially in context of this present thread... ;-)