This is the mail archive of the gcc@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]

issues related to implementation of mips16 naked attribute


I would like to move on to figuring out precisely what the issues are .

What rules would make this attribute behave in a proper and understandable way?

Maybe there are limitations that the user would have to be aware of.

My main interest is in LLVM but there is great interest to keep the compiler semantics the same as gcc for most things.

LLVM seems to have more or less decided that the naked attribute is useful and there is a desire to create a clear semantics of it across all targets. There is not any dissenting debate there on it's usefulness.

BTW, the MicroChip Mips C compiler which is for embedded work does support the naked attribute.

http://ww1.microchip.com/downloads/en/DeviceDoc/51686F.pdf

One issue I can see is properly defining the state of the assembler that can be assumed up entry.

For example, the state of .reorder, .noreorder.

There are the .cfi issues which Richard S brought up.

The issues of callee and caller saved registers which Richard S brought up. I would say that naked functions should preserve the ABI. If it can't then at the call site, the appropriate registers should be saved via inline asm.

I would like to see the naked function appear to gcc as any external asm function would. That seems to get rid of most if not all problems.

Reed








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