__attribute__((naked) on x86 would be useful

  • From: Mat Hostetter
  • 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 can
generate 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 small
machine-generated assembly language trampolines that implement
multiple inheritance (e.g. offset a "self" parameter and jump
elsewhere), but I've had other uses.

I checked the mailing list archives, and the last time someone
suggested 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 why
supporting other scenarios would be strange.  As Mr. Henderson
suggests, I currently define the entire function in assembly, but this
has 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,@function
my_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