This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Incompatability between APCS and ATPCS


Nick Clifton wrote:
> 
> 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.

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.   Consider
the case of using a precompiled static library from a third party vendor built
with gcc 2.95.2, and a customer building with the latest and greatest gcc.  The
source to the library is not available to the customer.  If a function in the
library returns an aggregate in a memory when gcc expects it in a register, it
will introduce a bug into the program.

This bug is introduced by the toolchain, and will be a true pain in the ass to
detect and debug.  The programmer will have to have knowledge of the calling
convention rules, ARM assembler, and the fact that such a bug or API
incompatibility exists.  Once detected it will be called a bug in the toolchain,
and people are going to ask why we didn't do more to fix it.  Most ARM
programmers don't have this level of expertise, if the mailing lists I read are
any indication.  You could argue they should, but that ain't reality.

This really has nothing to do with the patch, it is just a general concern of
mine.  The patch seems generally ok with me.  I have some minor nits, and a
couple of questions.  

First, the patch is against the mainline I believe? [Aside: How long are we
going to maintain the two separate development streams?]  I also don't see how
this patch helps gdb detect between buggy and non-buggy APCS code.

In the change log for gcc:
>         * arm.c (arm_override_options): If both -matpcs and
>         -mbuggy-return-in-memory are specified, prefer the former.
>         (arm_return_in_memory): If suppport ATPCS allow any structure
                                         ^
>         <= 32 bits in size to be returned in a register.  Otherwise,
>         if providing compatability with previous versions of gcc,
>         disallow small structures containign floats or non
                                            ^^
>         integer-like aggregates.

> Index: gcc/config/arm/arm.c
> ===================================================================

> +   if (TARGET_BUGGY_RETURN_IN_MEMORY && TARGET_ATPCS)
> +     {
> +       warning ("-mbuggy-return-in-memory is overriden by -matpcs.");
> +       target_flags &= ARM_FLAG_BUGGY_RETURN_IN_MEMORY;
> +     }

In this case you want to turn off ARM_FLAG_BUGGY_RETURN_IN_MEMORY without
affecting the other flagss I believe.  If this is the case shouldn't it be:

target_flags &= ~ARM_FLAG_BUGGY_RETURN_IN_MEMORY;

> *************** arm_return_in_memory (type)
> 
> !   /* XXX Not sure what should be done for other aggregates, so put them in
> !      memory. */
>     return 1;
>   }

Are we really unsure here, or is this just the default after all the special
cases have been dealt with?  There is a similar comment in thumb.c as well.

> Index: gcc/invoke.texi
> ===================================================================
> + @item -matpcs
> + @kindex -matpcs
> + @kindex -mno-atpcs
> + Generate code that conforms to the ATPCS (ARM Thumb Procedure Call
> + Standard).  This ABI standard is slightly different from the APCS
> + standard and is incompatible in the way that small structures are
> + returned from a function.  For the APCS a structure like this
> +
> + @smallexample
> + struct @{@ char a; char b; @}@
> + @end smallexample
> +
> + would be returned in memory, whereas for the ATPS it is returned in a
                                                 ^^^^
I think you mean ATPCS here.

> *************** the default for all standard configurati
> *** 4690,4695 ****
> --- 4736,4756 ----
>  ...
> + would be returned in memory, whereas for the ATPS it is returned in a
                                                 ^^^^
I think you mean ATPCS here as well.

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);
}

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]