True, but you could reserve initialized memory space to hold the information and have a post-link tool that extracts the desired information from the ELF header and then stores it in the space you reserved...
More basically, the ELF header might give you some idea if the block of code in question is contiguous - ie, if the scheme is going to be possible provided you can provide the addresses at runtime, or if the compiler/linker is going to need adjustment in order to produce contiguous functions.
Perhaps, but it's way, way, way easier to do this in the linker script. After all keeping track of what's where in memory is what linkers _do_. Those ELF headers were createdy by the linker, and all that information is availably in a trivial manner to the linker script.
--
Grant Edwards grante Yow! Yow! Maybe I should
at have asked for my Neutron
visi.com Bomb in PAISLEY--
Nope. The linkable unit in GCC is a module, not a single function. Hi-Cross separates even functions within a module.
Hi-Cross does not have such a thing. There is a primitive sectionization, but nothing else.
See above.
After sorting, the final output was a sensible binary file in one piece, but the functions that were together in the source in a module, were usually no longer together in the final file, except occasionally. It is pretty clear that there is then no way to put in labels to calculate the size of a function. The code (M86k) is inherently position-independent in small functions, so the only problem was to get the size of the code.
So does the Gnu toolchain if you tell it to. If you use the
-ffunction-sections option, each function goes into it's own section. This means that each function is a linkable unit. [For most purposes, it's the same as putting every function in a separate file.]
When you link, you specify --gc-sections, and only sections (functions) that are referenced will be linked into the output image.
This also means that in the linker script you can specify a separate output section for a particular function if you want to. Once the function is in its own section, finding the size of that section is trivial using the SIZEOF() operator in the linker script.
In all the other toolchains I've used (which I guess weren't all that representative) you could easily accomplish much the same thing if the function was placed in its own file.
[You can also do the same thing with variables: if you use
--data-sections when compiling then unreferenced global variables will not be linked into the output image.]
Hi-Cross sounds like a nasty bit of work.
--
Grant Edwards grante Yow! I had pancake makeup
at for brunch!
visi.com
If we're talking about GCC and the GNU toolchain, the whole discussion is moot: there are plenty of ways to create the desired effect. IMHO, the by far easiest is to sectionize and locate the function to .data, so we do not need to consider position-dependency issues at all and the start-up code does the loading of the function code to RAM.
It is a family of compilers sold for embedded work. The OP question was about C language without specifying a compiler.
AFAIK, Hi-Cross is not alone with this kind of 'innovations' in the mebedded world.
--
Tauno Voipio
tauno voipio (at) iki fi
PS. I learned something of the compiler: my current projects
are all using the GNU toolset.
TV
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.