Re: PA specifies invalid T_ADAFLAGS

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

> "John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:
> 
> > Has the PA indexing situation been reviewed since the above patch was
> > installed?
> 
> Perhaps a testcase exercised against the current 3.1 would help ...
> 
> IIUC, some constructs we have in Ada basically amount to the following kind of
> behavior in C:
> 
> 
>      #include <malloc.h>
> 
>      int lo ()
>      {
>        return 60000;
>      }
> 
>      int
>      main ()
>      {
>        volatile char c;
> 
>        char * b  = malloc (15);
>        char * vb = b - lo();
> 
>        c = vb [lo()];
> 
>        return 0;
>      }

[...]

>         bl lo,%r2
>         copy %r28,%r4
>         .CALL 
>         bl lo,%r2
>         sub %r4,%r28,%r4
>         ldbx %r28(%r4),%r4   <=== Runtime fault here
>         stb %r4,-120(%r30)
> 
>  
>  This dumps core at the ldbx point because the space check is performed
>  against r28 and not r28+r4.

I note that there is still confusion about space register usage and the
PA hpux runtime.  The ldbx instruction is short for

	ldbx %r28(%sr4,%r4),%r4

The space check is done using %r4 against %sr4.  When the space check
is against %sr4, the two most significant bits select one of %sr4, %sr5,
%sr6, or %sr7 to build the final physical address.  In this runtime model,
%sr0, %sr1, %sr2 and %sr3 are only used in special cases and never
for data loads.

The example is not legal C.  However, it will work under hpux if you
keep the base in the same segment as the data.  Under linux, %sr4,
%sr5, %sr6, and %sr7 are all the same, so you don't need to worry
which register gets selected.

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