Re: [PATCH] MIPS function attributes for interrupt handlers

[Mark Mitchell <mark at codesourcery dot com>]

Richard Sandiford wrote:

> I still disagree, for the reasons given before.  MIPS assembly coders
> already have preprocessor macros to prettify the assembly function
> declaration syntax.  If the only point of the attribute is to write
> out that syntax, I don't think the attribute is a win.

I disagree on that point.  Assembly function declaration syntax is
complex, and varies from OS to OS, and depends on things like whether
the function is hidden, static, etc.  Making this an
architecture-independent attribute seems beneficial, as one of GCC's
core advantages is cross-platform consistency.

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.

> (The reason the manual says what it does is that people used to try
> to use operands with naked function asms, and tripped over problems.
> The "asm with no operands" rule is a recent change (2008-05-23) and
> hasn't yet appeared in any released compiler, so we don't really know
> yet what effect the restriction has on real-world uses.  I bet the
> version of gcc that the MIPS attribute was written for didn't enforce
> this constraint.)

Certainly so, but I'm not sure how this is relevant.  Is your point that
the attribute with the restrictions might not meet the intended use by
whoever first started using it?  If so, I agree -- but independent of
the original users, I still think it seems like a useful attribute.

> I don't think we've ever written down how the attribute interacts
> with other features, such as function profiling.

Indeed, though I think it's implied: if you don't write the right
assembly goo, you won't have profiling, since everything within the body
of the function is your responsibility.  I'm all for making it more
explicit, though.

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