This is the mail archive of the 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: [PATCH] MIPS function attributes for interrupt handlers


> -----Original Message-----
> From: Mark Mitchell [] 
> Sent: Tuesday, October 21, 2008 6:24 PM
> To: Thiemo Seufer
> Cc: Weddington, Eric;; 
> Subject: Re: [PATCH] MIPS function attributes for interrupt handlers
> Thiemo Seufer wrote:
> >>> The ifdef goo goes typically in the implementation of ARCH_MYLOCK,
> >>> declaring function entry/attributes etc. is easy to hide 
> in preprocessor
> >>> macros.
> > It is a trivial one-time effort which doesn't compare to 
> writing correct
> > assembler code. So this argument is rather weak, IMHO.
> I've done it, I didn't find it trivial, and I didn't try to handle the
> full generality of CPUs, OSes, ABIs, and so forth.  I guess we're just
> going to have to agree to disagree.

The AVR port is a weird case. We rarely, if ever, have OSes and certainly nothing the size of Linux. There have been only two reasons why AVR users have actually used "naked" ISRs: one is to reduce the size of the generated pro/epilogue, because the AVR port pushes/pops more registers than is generally necessary. I agree that this is a failing of the AVR port and should be fixed, but for one reason or another, it hasn't gotten fixed. The other reason is that some users want to instrument the ISR in some way, before/after the pro/epilogue. I note that both cases are rare. Yes, our users could have written these ISRs in straight assembly, but sometimes they find it easier to create the function shell in C and write inline assembly. To each their own. I do know that in these rare cases, the "naked" attribute comes in handy. And yes, our users are fully cautioned about the hazards of using it.

Whether the MIPS port should have a "naked" attribute or not, is up to the MIPS maintainers and community. The MIPS and AVR ports are (obviously) very different. There are existing attributes that are port-specific in their semantics and implementation (e.g. "signal", "interrupt"). I just would have thought that "naked" would be left up to each port, whether to implement or not, and how to implement. I am just concerned about the statement that the "naked" attribute should not exist for *any* port. 

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