This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: noreturn function attribute and ret asm instruction


On Sun, 2003-09-14 at 10:18, Kristis Makris wrote:
> I am working on a framework with which functions that were compiled for
> the linux kernel can be replaced with newer revisions of them during
> runtime.

OK.  I see what you are trying to do.  This is outside the scope of the
ISO C language standard, and all ABI standards I know of.  However, it
does sound like a reasonable thing for the linux developers to ask from
gcc.

There will need to be some definition work here.  Do you really need all
registers preserved?  The ABI only requires that call-saved registers
and function arguments be preserved.  (And for gcc, global register
variables are preserved.)  It should be safe to clobber any
call-clobbered register, unless perhaps linux is passing info via them
that is hidden to the compiler.  Letting gcc clobber call-clobbered
registers means a bit better performance in the handler.  Preserving
call-clobbered registers means you get the same ABI as an interrupt
handler, which means we can perhaps share some code.  Instead of having
an rte at the end of the function, we would have essentially a sibling
(tail) call.

There will be implementation work needed for all targets that are
supported by linux.  I am not volunteering for this work.  This is
probably the killer part, because you would have to find a volunteer to
do all of this work.  You would need someone familiar with each target,
or willing to learn each target, which makes this quite a bit of work.

The Objective C language needs a somewhat similar feature.  It is
implemented via builtin_save_args and builtin_apply_all.  These are
inefficient features that save and restore lots of register arguments
and stack arguments.  Perhaps this same feature could be used to improve
Objective C support.  I am not familiar enough with Objective C to know
for sure whether this makes any sense though.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]