suspect assembly code for gcc 2.95.3 for ppc

suspect assembly code for gcc 2.95.3 for ppc

[Bob Boz]

I have noticed there's been a few problems with variable args and ppc in the
past. I wonder if this one is another case?
This seems to be a problem with va_list, var_arg handing.
Here's the function that uses them and the assembly produced below:

unsigned
foo(unsigned start, ...)
{
    /* ... */
    va_list args;
    /* ... */
    va_start(args, start);
    for(;;) {
 name = va_arg(args, char *);
 if(name == NULL) break;
 /* ... */
    }
    va_end(args);
    /* ... */
}

edited assembly:

foo:
  a0:   94 21 ff 50     stwu    r1,-176(r1)
  a4:   7c 08 02 a6     mflr    r0
  a8:   93 61 00 9c     stw     r27,156(r1)
  ac:   93 81 00 a0     stw     r28,160(r1)
  b0:   93 a1 00 a4     stw     r29,164(r1)
  b4:   93 c1 00 a8     stw     r30,168(r1)
  b8:   93 e1 00 ac     stw     r31,172(r1)
  bc:   90 01 00 b4     stw     r0,180(r1)
  c0:   7c 3f 0b 78     mr      r31,r1

  c4:   3c 00 01 00     lis     r0,256
  c8:   90 9f 00 0c     stw     r4,12(r31)    <====

  cc:   3b 80 00 00     li      r28,0

  d0:   90 1f 00 80     stw     r0,128(r31)
  d4:   39 7f 00 b8     addi    r11,r31,184
  d8:   38 9f 00 08     addi    r4,r31,8

  dc:   3b bf 00 01     addi    r29,r31,1     <====
  e0:   38 1f 00 80     addi    r0,r31,128

  e4:   91 7f 00 84     stw     r11,132(r31)
  e8:   90 9f 00 88     stw     r4,136(r31)
  ec:   7c 7b 1b 78     mr      r27,r3
  f0:   90 bf 00 10     stw     r5,16(r31)
  f4:   90 df 00 14     stw     r6,20(r31)
  f8:   90 ff 00 18     stw     r7,24(r31)
  fc:   91 1f 00 1c     stw     r8,28(r31)
 100:   91 3f 00 20     stw     r9,32(r31)
 104:   91 5f 00 24     stw     r10,36(r31)
 108:   93 bf 00 78     stw     r29,120(r31)
 10c:   90 1f 00 74     stw     r0,116(r31)
 110:   9b 9f 00 70     stb     r28,112(r31)
 114:   9b 9f 00 71     stb     r28,113(r31)

112(r31) is address of "gpr" in args (va_list data structure)
113(r31) is address of "fpr" in args (va_list data structure)
116(r31) is address of "overflow_arg_area" in args (va_list data
structure)
120(r31) is address of "reg_save_area" in args (va_list data structure)

fpr and gpr are set to 0 (r28) -> this does not reflect the comment of
the va_list data structure for PPC (but it works) since the first
register used for the va_list is r4.

overflow_arg_area is set to (r31 + 128) -> i do not know if this value
is correct, but there is something funny with this value since we save
256 in the address 128(r31).
could anyone give us more info about it since we were expecting
something different as an address on the stack?

reg_save_area is set to (r31 + 1), but should be set to (r31 + 12) since
the first register used for the "..." arguments is r4 and since r4 is
saved into memory at the address 12(r31). Due to this "error", we read
something that is not aligned and we read a bad value.

Replacing the 1 to a 12 by hand for this function seems to solve the
problem.

-B

Re: suspect assembly code for gcc 2.95.3 for ppc

[Franz Sirl]

On Thursday 11 April 2002 16:40, Bob Boz wrote:
> I have noticed there's been a few problems with variable args and ppc in
> the past. I wonder if this one is another case?
> This seems to be a problem with va_list, var_arg handing.
> Here's the function that uses them and the assembly produced below:
>
> unsigned
> foo(unsigned start, ...)
> {
>     /* ... */
>     va_list args;
>     /* ... */
>     va_start(args, start);
>     for(;;) {
>  name = va_arg(args, char *);
>  if(name == NULL) break;
>  /* ... */
>     }
>     va_end(args);
>     /* ... */
> }
>
> edited assembly:
>
> foo:
>   a0:   94 21 ff 50     stwu    r1,-176(r1)
>   a4:   7c 08 02 a6     mflr    r0
>   a8:   93 61 00 9c     stw     r27,156(r1)
>   ac:   93 81 00 a0     stw     r28,160(r1)
>   b0:   93 a1 00 a4     stw     r29,164(r1)
>   b4:   93 c1 00 a8     stw     r30,168(r1)
>   b8:   93 e1 00 ac     stw     r31,172(r1)
>   bc:   90 01 00 b4     stw     r0,180(r1)
>   c0:   7c 3f 0b 78     mr      r31,r1
>
>   c4:   3c 00 01 00     lis     r0,256
>   c8:   90 9f 00 0c     stw     r4,12(r31)    <====
>
>   cc:   3b 80 00 00     li      r28,0
>
>   d0:   90 1f 00 80     stw     r0,128(r31)
>   d4:   39 7f 00 b8     addi    r11,r31,184
>   d8:   38 9f 00 08     addi    r4,r31,8
>
>   dc:   3b bf 00 01     addi    r29,r31,1     <====
>   e0:   38 1f 00 80     addi    r0,r31,128
>
>   e4:   91 7f 00 84     stw     r11,132(r31)
>   e8:   90 9f 00 88     stw     r4,136(r31)
>   ec:   7c 7b 1b 78     mr      r27,r3
>   f0:   90 bf 00 10     stw     r5,16(r31)
>   f4:   90 df 00 14     stw     r6,20(r31)
>   f8:   90 ff 00 18     stw     r7,24(r31)
>   fc:   91 1f 00 1c     stw     r8,28(r31)
>  100:   91 3f 00 20     stw     r9,32(r31)
>  104:   91 5f 00 24     stw     r10,36(r31)
>  108:   93 bf 00 78     stw     r29,120(r31)
>  10c:   90 1f 00 74     stw     r0,116(r31)
>  110:   9b 9f 00 70     stb     r28,112(r31)
>  114:   9b 9f 00 71     stb     r28,113(r31)
>
> 112(r31) is address of "gpr" in args (va_list data structure)
> 113(r31) is address of "fpr" in args (va_list data structure)
> 116(r31) is address of "overflow_arg_area" in args (va_list data
> structure)
> 120(r31) is address of "reg_save_area" in args (va_list data structure)
>
> fpr and gpr are set to 0 (r28) -> this does not reflect the comment of
> the va_list data structure for PPC (but it works) since the first
> register used for the va_list is r4.
>
> overflow_arg_area is set to (r31 + 128) -> i do not know if this value
> is correct, but there is something funny with this value since we save
> 256 in the address 128(r31).
> could anyone give us more info about it since we were expecting
> something different as an address on the stack?
>
> reg_save_area is set to (r31 + 1), but should be set to (r31 + 12) since
> the first register used for the "..." arguments is r4 and since r4 is
> saved into memory at the address 12(r31). Due to this "error", we read
> something that is not aligned and we read a bad value.
>
> Replacing the 1 to a 12 by hand for this function seems to solve the
> problem.

I can't reproduce your assembly on powerpc-linux-gnu with gcc-2.95.4, can you 
be more specific what your exact target triple is, which CPU your are 
compiling for and the output of gcc -v?

If I have to guess, I would say you have old or corrupted stdarg.h/va-ppc.h 
include files in your include path.

Franz.

RE: suspect assembly code for gcc 2.95.3 for ppc

[Bob Boz]

Franz,
>
> I can't reproduce your assembly on powerpc-linux-gnu with
> gcc-2.95.4, can you
> be more specific what your exact target triple is, which CPU your are
> compiling for and the output of gcc -v?

I get "powerpc-eabi-gcc" when I try gcc -v however the system is based on
qnx.

>
> If I have to guess, I would say you have old or corrupted
> stdarg.h/va-ppc.h
> include files in your include path.
>
> Franz.

Your guess was right on. I was using an include file that was suplanting
stuff in va-ppc.h (some typedefs and macros). After removing those I now get
assembler code that looks a lot better. This is assuming(and hoping) the
va-ppc.h could be used without any custom modifications for the specific
system we are using. I'll find that out soon though...

Thanks,
 -B

Re: suspect assembly code for gcc 2.95.3 for ppc

[Franz Sirl]

On Monday 15 April 2002 16:46, Bob Boz wrote:
> Franz,
>
> > I can't reproduce your assembly on powerpc-linux-gnu with
> > gcc-2.95.4, can you
> > be more specific what your exact target triple is, which CPU your are
> > compiling for and the output of gcc -v?
>
> I get "powerpc-eabi-gcc" when I try gcc -v however the system is based on
> qnx.

Well, in that case powerpc-eabi-gcc -v :-).

> > If I have to guess, I would say you have old or corrupted
> > stdarg.h/va-ppc.h
> > include files in your include path.
> >
> > Franz.
>
> Your guess was right on. I was using an include file that was suplanting
> stuff in va-ppc.h (some typedefs and macros). After removing those I now
> get assembler code that looks a lot better. This is assuming(and hoping)
> the va-ppc.h could be used without any custom modifications for the
> specific system we are using. I'll find that out soon though...

Well, va-ppc.h and the accompanying code in the compiler have been heavily 
bug-fixed between egcs-1.x and gcc-2.95.1. You may have binaries that rely on 
the bugs... But my experience with the powerpc-linux-gnu transition shows 
these cases are very rare and were by far outweighed by "mysterious unstable 
behaviour" bugs going away due to the fixed varargs code :-).

Franz.