Re: [Patch]: Re: gas 2.10.91 from 20000920 cvs is broken under hpux (fwd)

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

The following occurs when using the gnu assembler under hpux 10.20.  The
.CALL generated for function calls in pa.c doesn't include the RTNVAL
parameter.  As a result, gas thinks an argument relocation block is
required for any function which has a return.  This may cause almost
all functions to be called through stubs even though there is agreement
between the caller and callee on the argument and return locations.

> > When the function `int f(char *p)' is called recursively, I see the following
> > in md_apply_fix when the function is called:
> > 
> > Breakpoint 1, md_apply_fix (fixP=0x40026f10, valp=0x7b03ab84)
> >     at ./config/tc-hppa.c:4412
> > 4412          if ((fmt == 12 || fmt == 17 || fmt == 22)
> > (gdb) p fixP->fx_pcrel
> > $3 = 1
> > (gdb) p (((obj_symbol_type *) symbol_get_bfdsym (fixP->fx_addsy))->tc_data.ap.hppa_arg_reloc)
> > $4 = 257
> > (gdb) p hppa_fixP->fx_arg_reloc
> > $5 = 256
> > 
> > It doesn't see right that a simple function such as the one above should
> > need an argument relocation stub.  If I change the return type to void, then
> > both values are 256 and no stub is needed.   I haven't been able to 
> > find where the bits for fx_arg_reloc are defined.  Does this seem right?
> 
> There is a problem here but it doesn't appear to be with binutils.  Rather,
> it is with gcc.  The .EXPORT statement generated for the above function is:
> 
>         .EXPORT f,ENTRY,PRIV_LEV=3,ARGW0=GR,RTNVAL=GR
> 
> However, the .CALL generated doesn't include RTNVAL=GR:
> 
>         .CALL ARGW0=GR
> 
> Since the .CALL is missing a RTNVAL=GR, the two don't match and an argument
> relocation stub is being generated for all functions with a return in a GR.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)