Re: RFA: Add SH Symbian port

[Joern Rennecke <joern dot rennecke at superh dot com>]

> > What for would you want to use a naked function?
> 
> Personally I wouldn't want to use one, but the Symbian OS uses them for 
> various different things, including device drivers and interrupt handlers.

We already have the interrupt, trapa and sp_switch attributes for interrupt
functions.  I know we have some issues with the use of static variables,
but you are welcome to submit patches to fix them.

> > How does this attribute interact with inlinning, sibcall optimizations,
> > c++ thunking, instrumentation, and nested functions?
> 
> It interacts badly with inlining, sibcalls and nesting.  Or at least I 
> assume that it will, it has not been tested with these optimisations. 
> Symbian explicitly disable all optimisations when compiling a naked 
> function.

As I'm sure you are aware, that is not actually possible anymore - we
do some minimal optimization all the time.  There might be more such
changes in the future.

That they try to disable optimizations to make this work is just one
more indication that this attribute is ill-conceived.
Prologues and epilogues are an implementation detail of gcc.  What goes into
them, or not, can change from time to time.
Gcc extensions should have a defined meaning in terms of the semantics of
the program.  The naked function attribute does not have any such meaning,
instead it changes the internals of the compiler, getting you completely
undefined results.
Please define the attributes that ou need in terms of semantics of
the program.

Let's look at what your patch would do to the code generation with a
current snapshot:

- Variadic function handling is suppressed.  That is just daft.  If the
  function is declared variadic, it should better work.  If the attribute
  is incompatible with a particular function signature so that you can't
  emit valid code, generate an error.
- Register saving and restoring is omitted, except that FPSCR is set back
  to the normal mode if you don't also use the interrupt attribute.
  Changing the set of registers that are saved is OK, but you should look
  closely at what you want to do with FPSCR.
- Setting up the frame (i.e. allocating static space on the stack) and
  deallocating it (uncluding deynamic allocations) is disabled.
  This does not make sense, either.  You ask the compiler to allocate
  variables and temporaries on the stack, so you should also leave it to
  the compiler to adjust the stack pointer accordingly.
  If you have some pre-allocated space on the stack that the function may
  reuse, you should specify the size of that space (in an attribute
  argument), and then the prologue can allocate more space if it needs to.
  Regardless, if alloca is being used, a frame pointer is needed, and the
  epilogue must deallocate the frame.
- The return instruction is omitted.  That doesn't make sense, as then
  the program can drop through into a switch table or constant pool.
  Inserting random assembler afterwards is also unsfe, becasue the
  compiler has to know about the distance between the switch table /
  constant pools from the sites where they are used, and the debug
  information also is emitted assuming that the compiler emits the whole
  function.
  What we could do is have some alternate return sequence.
  If you just want jump to a specific symbol at the end, that would be
  a tail call to a nonreturn function with void argument list.