Incompatability between APCS and ATPCS

[Nick Clifton]

Hi Scott,

[Re: adding .arm.atpcs section to ATPCS compliant binaries.]

: This scheme works if all object modules linked are compiled with the same
: calling convention.  However I see nothing that guarantees that this is the
: case.  This can introduce difficult to detect bugs into a program.

Indeed it can.  To catch this problem I would suggest that we add code
to the linker to detect when incompatible ABIs are linked together.
The linker already has code to dectect attempts to link together
big-endian and little-endian or interworking and non-interworking
code, so the precedent has been set.

I already have a patched developed to add this feature to the linker,
should we decide that this is the correct solution tot he problem.

: First, the patch is against the mainline I believe?

Correct.

: [Aside: How long are we going to maintain the two separate
: development streams?]

Not much longer, I hope.

: I also don't see how this patch helps gdb detect between buggy and
: non-buggy APCS code.

It doesn't, although a similar solution could be used to distibguish
between buggy and correct implementations of the APCS.

Thanks for the corrections to my patch by the way.  I have
incorporated them into my (un-checked-in) sources here.
 
: The only other thing I would be concerned about is how the compiler
: handled code similar to the following with -matpcs on the command
: line: 
: 
: typedef struct tagFOO {char a; char b;} FOO;
: 
: FOO bar (char a, char b)
: {
:   FOO f;
:   f.a = a;
:   f.b = b;
:   return f;
: }
: 
: int main (int argc, char *argv)
: {
:    printf ("address of FOO.b = 0x%08x\n", &bar('a','b').b);
: }

This is not a problem.  Such code is illegal and produces this error
message from GCC:

  scott.c: In function `main':
  scott.c:13: invalid lvalue in unary `&'

Cheers
	Nick