[parisc-linux] HPUX syscall ABI?

[parisc-linux] HPUX syscall ABI?

[Matthew Wilcox]

I've just redefined the Linux syscall ABI again so we can
handle sys_mmap (which takes 6 arguments) cleanly.  I'm now
wondering what the HPUX syscall standard is.  I've searched
http://docs.hp.com:80/dynaweb/hpux11/dtdcen1a/b821/@Generic__BookView
(as mentioned earlier on this mailing list) without success.

For those interested; Linux syscalls now take the syscall number in r20,
take arguments in r26-r21, zero r1, r19-r26, r29 and r31 on exit, preserve
r3-r18, r27(dp) and r30(sp), clobber r2 and return the result in r28.
If it's in the range [-1024,0) then that's an error code, otherwise it's
the result.

ObRant: Why on earth define a register to be caller-saves but not allow it
to contain an argument?  Why force it onto the stack?

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Re: [parisc-linux] HPUX syscall ABI?

[Philipp Rumpf]

> For those interested; Linux syscalls now take the syscall number in r20,
> take arguments in r26-r21, zero r1, r19-r26, r29 and r31 on exit, preserve
> r3-r18, r27(dp) and r30(sp), clobber r2 and return the result in r28.

sounds rather strange but as long as gcc takes it as inline assembly ...

> ObRant: Why on earth define a register to be caller-saves but not allow it
> to contain an argument?  Why force it onto the stack?

An ABI that would specify too many argument registers would force the caller
to load them before the call and the callee to save them again because both
would need the additional argument registers.

Re: [parisc-linux] HPUX syscall ABI?

[Jeffrey A Law]

  In message <19990802053239.N13236@suse.de>you write:
  > > For those interested; Linux syscalls now take the syscall number in r20,
  > > take arguments in r26-r21, zero r1, r19-r26, r29 and r31 on exit, preserv
  > e
  > > r3-r18, r27(dp) and r30(sp), clobber r2 and return the result in r28.
  > 
  > sounds rather strange but as long as gcc takes it as inline assembly ...
  > 
  > > ObRant: Why on earth define a register to be caller-saves but not allow i
  > t
  > > to contain an argument?  Why force it onto the stack?
  > 
  > An ABI that would specify too many argument registers would force the 
caller
  > to load them before the call and the callee to save them again because both
  > would need the additional argument registers.
At function entry the compiler copies all parameters passed in registers into
pseudo-registers.

Those pseudo registers are then subject to normal register allocation.  ie,
the compiler can allocate it into a call saved register, into a stack slot
(and bring it into a register where needed) or into a call clobbered register
and save/restore it around calls based on which of the options minimizes
cost.

In fact, if you examine the PA64 ABI, it uses %r19-%r26 for parameters,
%r28 for the structure value return address and %r29 for the outgoing arg
pointer, %r2 for the return address, %r1 is a scratch for long calls.  That
leaves just %r31 as the only call-clobbered register which is not uses for
passing parameters or not clobbered on the call path itself.

There's no benefit to not using those call clobbered registers for parameter
passing other than to save a little stack space (you have a register flush to
fixed areas in the frame inside varargs/stdarg functions).

jeff

Re: [parisc-linux] HPUX syscall ABI?

[Philipp Rumpf]

>> An ABI that would specify too many argument registers would force the 
>> caller
>> to load them before the call and the callee to save them again because both
>> would need the additional argument registers.
> At function entry the compiler copies all parameters passed in registers into
> pseudo-registers.
> 
> Those pseudo registers are then subject to normal register allocation.  ie,
> the compiler can allocate it into a call saved register, into a stack slot
> (and bring it into a register where needed) or into a call clobbered register
> and save/restore it around calls based on which of the options minimizes
> cost.

Is this gcc-specific ?

> There's no benefit to not using those call clobbered registers for parameter
> passing other than to save a little stack space (you have a register flush to
> fixed areas in the frame inside varargs/stdarg functions).

I can imagine cases for which the PA1.1 ABI is better but of course I am not
sure how frequent they are.  For syscalls we definitely want to avoid having
to look at the user stack as soon as we have PL 0.

	Philipp Rumpf

Re: [parisc-linux] HPUX syscall ABI?

[Jeffrey A Law]

  In message <19990802062141.A23880@suse.de>you write:
  > Is this gcc-specific ?
It's a well known concept.  I would be amazed at any compiler that doesn't
do something similar.


  > I can imagine cases for which the PA1.1 ABI is better but of course I am
  > not sure how frequent they are.
Not if you write your compiler in a reasonable way (assuming we're just
discussing how many registers are used).  There are certainly ways the PA32
ABI is more efficient than the PA64 ABI, particularly when calling functions
without prototypes.

FWIW there is another PA32 ABI which appeared on hp's osf system which used
%r21-%r26 for passing parameters.  If you look deep into some of the mach+osf
code you'll find thunks to deal with that gem since we (Utah) used the standard
hpux ABI on our mach+osf port.

jeff

Re: [parisc-linux] HPUX syscall ABI?

[LaMont Jones]

> I've just redefined the Linux syscall ABI again so we can
> handle sys_mmap (which takes 6 arguments) cleanly.  I'm now
> wondering what the HPUX syscall standard is.  I've searched
> http://docs.hp.com:80/dynaweb/hpux11/dtdcen1a/b821/@Generic__BookView
> (as mentioned earlier on this mailing list) without success.

IIRC, r22 has the syscall number, r31 (and sr0) gets trashed branching
to 0.0xc0000004 (they probably get used as part of the return - I'm too
lazy to go look right now, but I'm pretty sure that r31 gets copied into
r2).  Other than that, it's a standard PA1.1 function call: arg0-3 in
r26-21, and arg4-n at sp-52, -56, ...

Was that what you were looking for?
lamont

Re: [parisc-linux] HPUX syscall ABI?

[Matthew Wilcox]

On Mon, Aug 02, 1999 at 12:08:24AM -0600, LaMont Jones wrote:
> > I've just redefined the Linux syscall ABI again so we can
> > handle sys_mmap (which takes 6 arguments) cleanly.  I'm now
> > wondering what the HPUX syscall standard is.  I've searched
> > http://docs.hp.com:80/dynaweb/hpux11/dtdcen1a/b821/@Generic__BookView
> > (as mentioned earlier on this mailing list) without success.
> 
> IIRC, r22 has the syscall number, r31 (and sr0) gets trashed branching
> to 0.0xc0000004 (they probably get used as part of the return - I'm too
> lazy to go look right now, but I'm pretty sure that r31 gets copied into
> r2).  Other than that, it's a standard PA1.1 function call: arg0-3 in
> r26-21, and arg4-n at sp-52, -56, ...
> 
> Was that what you were looking for?

Yep, that's exactly what I need.  Urgh, so I have to grab the arguments
off the user-mode stack before switching to the kernel-mode stack..

What's the greatest number of parameters to an HPUX syscall?
Linux's mmap() has six parameters (and you should see the kludges some
architectures go through to support that.  We're cleaner).

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Re: [parisc-linux] HPUX syscall ABI?

[LaMont Jones]

> Yep, that's exactly what I need.  Urgh, so I have to grab the arguments
> off the user-mode stack before switching to the kernel-mode stack..
> 
> What's the greatest number of parameters to an HPUX syscall?
> Linux's mmap() has six parameters (and you should see the kludges some
> architectures go through to support that.  We're cleaner).

The routine _syscall(), which calls an aribitrary system call for you,
takes 9 arguments:  the system call number followed by 8 args.  While
that's not a complete guarantee, you'ld be in good company if you supported
up to 8 args...

lamont

Re: [parisc-linux] HPUX syscall ABI?

[Jerry Huck]

> Date: Mon, 2 Aug 1999 08:26:12 +0200
> From: Matthew Wilcox <Matthew.Wilcox@genedata.com>
> To: LaMont Jones <lamont@security.hp.com>
> Cc: Matthew Wilcox <Matthew.Wilcox@genedata.com>,
>         parisc-linux@thepuffingroup.com
> Subject: Re: [parisc-linux] HPUX syscall ABI?

... To LaMont's reply Matthew writes:

> Yep, that's exactly what I need.  Urgh, so I have to grab the arguments
> off the user-mode stack before switching to the kernel-mode stack..

Just as an aside, you might want to use the gateway page to do some
fix-ups.  On the gateway page, you can delay the promotion, do some
argument shuffling and other glue code in the user's context, and then
finally gateway to priv 0 (and presumably to some kernel code).  You
could load up all the scratch registers with arguments and then have
the kernel-stack switch code push the arguments after the priv change.

I've always wanted HP-UX to use this type of approach to read as many
arguments (and memory data structures) as can fit in the scratch
region on both call and return.  You can avoid all the high overhead
kernel-user copy code.  Simple things, like "gettimeofday", could pop into
the kernel, get the return values, return to priv 3 near those gateway
pages, write the return values to memory, and return to the caller
without any kernel-user copies.

Jerry Huck
(PA-RISC architecture group)