On 05/09/12 19:36, Ian Lance Taylor wrote:
On Wed, Sep 5, 2012 at 9:36 AM, David Brown<david.brown@xxxxxxxxxxxx> wrote:
On 05/09/12 07:37, Ian Lance Taylor wrote:
On Tue, Sep 4, 2012 at 10:35 PM, Xin Tong<xerox.time.tech@xxxxxxxxx>
wrote:
any reason why naked functions are not support for x86 ?
No special reason, no.
Ian
Is this something that could easily be moved from target-specific attributes
into more general gcc support? I'm sure the maintainers of ports like the
avr that have a "naked" attribute would be happier if it were a general
feature rather than specific to their port, and I'm sure that other embedded
targets would appreciate it.
However, I have no clue as to whether this is a simple matter of moving code
from a target-specific file to a generic file, or if it needs a lot more
work.
The way GCC is structured, it requires some support from every
backend. A bit of machinery could be moved into target-independent
code, but most of the work is backend-specific. It's not hard,
though.
In general I would support providing this attribute in every backend,
but somebody needs to do the work.
Ian
Is it possible to put the common part into the target-independent code,
and leave the backend-specific parts unimplemented for targets that
don't (yet) support it? That way there would be no need for someone to
write the backend code for targets where "naked" is not important.
I'm just airing ideas here, with little knowledge of the internals of
gcc - of course it is up to the port developers to decide. But as a
user of several gcc ports I sometimes find it frustrating when different
ports support different useful attributes, or have different attributes
and syntaxes for the same purpose (interrupt function attributes is a
prime example) - I can't help feeling that it would be easier for users
and gcc developers if there was more shared code.
(I fully understand how such parallel implementations occur with
out-of-tree development, or that it is faster and easier to add things
to a single target, and how they remain in place for compatibility
reasons - but the end result is suboptimal nonetheless.)
David
