Re: Incompatability between APCS and ATPCS

[Richard Earnshaw <rearnsha at arm dot com>]

> : For gcc we need to think a bit more carefully, and probably need to rework 
> : all the machine specific flags (Groan, yet again).  Part of the problem is 
> : that we are running out of bits in TARGET_FLAGS and that not all of the 
> : options we support are truly orthogonal.  Maybe a better approach would be 
> : something more akin to the way the ARM compiler does this.  Eg:
> : 
> : 	-mapcs=[/26|/32][/stack-check|/no-stack-check][/frame|/no-frame][fpreg|/no
> : fpreg]
> : 
> : and 
> : 
> : -matpcs=(...)
> : 
> : But this needs more thought before we dive in.
> 
> Hmm, well I had already started on the implementation of a new command
> line switch (-matpcs).  We do still have enough flags bits left over
> to accomodate this new option, although I agree that at some point, it
> would be nice to rework the switches properly.

I think we should do this sooner rather than later.  ATPCS variant options 
are generally incompatible with APCS variant options.  We should avoid the 
suggestion (even implicitly) that you can mix-and-match as you please.  
Also, if we are going to have to rework the interface eventually, why not 
do it all now?  That way, users see fewer changes in the future.

> I also received a suggestion from the gdb group here that we could
> create a dummy debug section for ATPCS compliant binaries and GDB
> could detect this and 'do the right thing' (tm) somehow.

How would this work for stabs based debugging (eg on an a.out target)?  If 
it won't then we will need the command-line interface as well.

> So below is a patch that implements these features.  

> It also
> implements another new command line switch -mbuggy-return-in-memory to
> enable compatability with prior implementations which did not quite
> this right.

UGGGGG!  No!

1) Is there an identifiable need for such a compatibility flag?
2) If there is, -mbuggy-return-in-memory is an awful name.  It doesn't 
even describe correctly what the flag does (the ABI we generated in the 
past wasn't buggy, it just didn't conform to the APCS).  Something along 
the line of -mgcc-abi=<XXX> would be much cleaner (meaning, support the 
ABI generated by gcc version XXX.  XXX wouldn't have to cover every 
version, just those that mark a transition from one ABI to another.

> This patch also covers the change to arm_return_in_memory() that Scott
> originally submitted a few days ago which started me on all of this in
> the first place. 
> 
> One thing that this patch does not do is implement the GDB side of
> things, maybe somebody else would like to do that ?
> 
> What do you think - should we go with this patch ?

I think we are rushing into it somewhat.  Let's make sure we get the 
design right before we start churning out code (or we will end up with 
even more incompatible versions to support).

Richard