__attribute__((naked) on x86 would be useful
- From: Mat Hostetter <mat at curl dot com>
- To: gcc at gnu dot org
- Date: 15 Feb 2004 22:04:32 -0500
- Subject: __attribute__((naked) on x86 would be useful
I'm using gcc-3.2.2 on RedHat 9. I work on a compiler that cangenerate C code as one of its back ends.It would be useful for me if gcc's "naked" attribute worked on x86,but right now it is ignored. My main use for this is for some smallmachine-generated assembly language trampolines that implementmultiple inheritance (e.g. offset a "self" parameter and jumpelsewhere), but I've had other uses.I checked the mailing list archives, and the last time someonesuggested adding "naked" to x86, Richard Henderson said:>I will not. I think this is the worst possible extension.>I know it exists for some gcc ports, but even there I think>it is a mistake.>>You *cannot* write correct code to go with __attribute__((naked)).>>If you're trying to use it, and only put one __asm__ in the>function, yes that will work, but why didn't you just define>the *entire* function in assembly?In my case I always do generate one asm per proc, and I can see whysupporting other scenarios would be strange. As Mr. Hendersonsuggests, I currently define the entire function in assembly, but thishas some major drawbacks that would be fixed by supporting the "naked"directive on x86 (as Microsoft's C compiler does):1) Boilerplate. If you look at gcc's assembly output, each proc has some preamble and postamble lines around it, looking something like this: .text .p2align 2,,3 .type my_proc,@functionmy_proc:.Lfe0: .size my_proc,.Lfe0-my_proc Generating assembly code "the right way" requires duplicating all or most of this boilerplate in a top-level asm. Unfortunately, the exact text to use here varies between x86 systems and has changed over the years. It's annoying to maintain this boilerplate, and requires #ifdefs to generate different boilerplate on different platforms. This is "busy work" because gcc always knows exactly what to dump out here on each host. I should be able to leverage that and only worry about the guts of the proc body.2) Name mangling. Some systems put a leading underscore in front of the proc name when generating assembly, some don't. Again I'd like gcc to "do the right thing" for me on each host, rather than having to write #ifdefs.3) Section lossage. The last time I checked, gcc seems to remember the last section directive it dumped out (e.g. ".text", ".rwdata", etc.) and does not emit directives when they would be redundant. That's normally fine, except that when you have a top level asm that changes the section (e.g. I always want my trampolines in the .text section), then gcc doesn't realize you changed it behind its back. The next things in the .s file (such as normal C global variables) are then sometimes left in the wrong section. Working around this is possible but can be a pain for machine-generated code that mixes asm and C. "naked" would of course moot this, because gcc would deal with all the "top-level" asm stuff. I suppose, independently of "naked", gcc should invalidate its "current section" assumptions whenever it emits user asm (?)-Mat