Re: [PATCH] MIPS function attributes for interrupt handlers

[Mark Mitchell <mark@codesourcery.com>]

Richard Sandiford wrote:

>> For example, writing:
>>
>>   void mylock()
>>     __attribute__((hidden))
>>     __attribute__((naked)) {
>>     ARCH_MYLOCK;
>>   }
>>
>> where ARCH_MYLOCK is a macro that expands to the CPU-specific assembly
>> implementation of a locking primitive seems likely to be useful.  Much
>> better than lots of #ifdef __linux__ and #ifdef __mips__ goo in a pure
>> assembler file.
> 
> I'm not convinced by this example.  GCC already provides a much
> more powerful way of doing this: extended asms.  Such an extended
> asm has many benefits over naked functions:

Sure, but it has one serious drawback: you can't use a non-standard
calling convention.

> I agree with what Thiemo said about defining these assembly macros.
> You said in reply that they were hard to write, but the point is that,
> for the ports we're talking about, you don't need to.

I'm sure they exist for MIPS GNU/Linux, for example.  But, I doubt they
exist for all architectures and all operating systems targeted by GCC,
in some convenient location where everyone can find them, under
licensing terms that everyone can use.

My argument here is that we have an opportunity to move towards making
this an architecture-independent feature.  But, if you block that
direction on MIPS, then we can't make it architecture-independent.
Whether or not the feature is most useful on MIPS or not is not the
point; the point is that it may be useful on many architectures, and
having MIPS be consistent is advantageous.

I feel the same way about the interrupt attribute.  Even on machines
where there is no special interrupt calling convention, supporting the
interrupt attribute -- and spelling it in the same way -- is useful,
since it allows people to write interrupt handlers without
conditionalizing for that.

> It just seems to me that we're trying to introduce a feature in the name
> of cross-platform consistency in cases where (a) in the foreseeable
> future, "cross-platform" will mean "across a handful of targets" and
> (b) we already have a better feature that is genuinely cross-platform.
> (I say "foreseeable future" because we can't of course predict what
> people will contribute.)

GCC is always incremental; it's relatively rare that something that
requires target support appears in all ports at once.  So, I agree that
it would take time to get consistency, but I don't see why that's a good
reason not to put this attribute into more ports.

If we really think this attribute is so harmful, we should be
deprecating it and removing it from other ports.  But, as defined now,
it doesn't seem linguistically problematic, and there is a use case for
it.

What is the harm in allowing it for MIPS?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713