c code in other section
c code in other section
Is it possible with to instruct gcc to put a certain c function not in the section .text or .rodata, but in a completely other section, like .kernelinit or something like that?
Re:c code in other section
Not to my knowledge (after searching the GCC manual "option index" for "text" or "sect"). You can of course write up a linker script to do this for you.
May I ask why?
May I ask why?
Every good solution is obvious once you've found it.
Re:c code in other section
Look thru the GCC manual. Find the bit about function and data attributes. Thats what you want.
I'll save you 5 mins:
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Function-Attributes.html#Function-Attributes
I'll save you 5 mins:
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Function-Attributes.html#Function-Attributes
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:c code in other section
that's something used often in kernels, including Linux: declare that some data or some functions do belong to a specific section that you'll remove once initialization has been completed. IIrc, linux uses "__init" modifers (that of course expands to some attribute((...)) stufff).
Code: Select all
// coming out of linux .../init.h
/* These are for everybody (although not all archs will actually
discard it in modules) */
#define __init __attribute__ ((__section__ (".init.text")))
#define __initdata __attribute__ ((__section__ (".init.data")))
#define __exitdata __attribute__ ((__section__(".exit.data")))
#define __exit_call __attribute_used__ __attribute__ ((__section__ (".exitca
ll.exit")))
Re:c code in other section
Thanks for your help! It is indeed meant to discard data and functies that are only needed during startup.
Re:c code in other section
Hehehe... thanks for sparking a nice idea. I haven't thought about that yet...
Every good solution is obvious once you've found it.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:c code in other section
iirc, that's _THE_ reason why people on lkml doesn't want to hear about COFF or something else than ELF for their kernel/module binary files.
Re:c code in other section
I don't read the LKML, after reading their FAQ I felt like throwing up. ::)
Every good solution is obvious once you've found it.
Re:c code in other section
Subscribed once, it's pointless. They send way more email than I've been able to gather in spam by publicly displaying my mail address on two websites (this and slashdot). It also contains loads of crud without point, flamewars at times about senseless specifics and very occasionally a degree of truth.Solar wrote: I don't read the LKML, after reading their FAQ I felt like throwing up. ::)
I agree with them on the ELF point, but not on why you wouldn't use COFF then. IIRC PE could do the trick too.
Re:c code in other section
Plus the GPL/ABI issue, plus the C++ issue, plus the release policy, and at some point I realized it sure as hell isn't the kernel (or the attitude of the people supporting it) why I prefer to run Linux.
Every good solution is obvious once you've found it.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:c code in other section
while you might have other names in sections with COFF file format, the compiler backends usually do not allow you to use "__attribute__((section))" things. At least, when i last tried (which was with DJGPP, i have to admit), i got the compiler frowning and babling a warning rather than doing what it was instructed.
So compiler will be creating .ctors and .dtors sections as it wants to, but it will not allow you to declare a ".textinit" section ...
So compiler will be creating .ctors and .dtors sections as it wants to, but it will not allow you to declare a ".textinit" section ...
Re:c code in other section
Yes, you can do that with PE. I want PE32+ support inside my kernel, although first I'll be supporting ELF64. Of course, ELF is supported nearly everywhere and by all Unix tools, but PE is not... (Linux could "embrace and extend" PE... ). And PE asks what Windows subsystem is in use, etc. It's very Windows specific, and is meant to be "portable" in the sense of portable between Windows versions. But as it turns out, they designed a very capable EXE/OBJ format that could be used elsewhere quite easily, as long as you break the specs and use the Windows fields for your own OS.Candy wrote:Subscribed once, it's pointless. They send way more email than I've been able to gather in spam by publicly displaying my mail address on two websites (this and slashdot). It also contains loads of crud without point, flamewars at times about senseless specifics and very occasionally a degree of truth.Solar wrote: I don't read the LKML, after reading their FAQ I felt like throwing up. ::)
I agree with them on the ELF point, but not on why you wouldn't use COFF then. IIRC PE could do the trick too.
I once subscribed to the LKML, too. What an experience! (Almost as good as the flames on OpenBSD lists). I unsubscribed a few hours later. ;D
Re:c code in other section
If I remember it was "portable" in the sense of platform / architecture
portability. There was a powerpc version of Windows....
You can also extend the PE format without breaking it...
portability. There was a powerpc version of Windows....
You can also extend the PE format without breaking it...
Re:c code in other section
AFAIK the "other" Windows was NT for Alpha, not PowerPC. I don't know if there ever was a "production" release of that, though.Rob wrote: There was a powerpc version of Windows....
Every good solution is obvious once you've found it.
Re:c code in other section
You are totally correct, it was the alpha. My bad. It definitely
has been used in the real world. I'm very sure of that.
has been used in the real world. I'm very sure of that.