On Thu, 2013-04-11 at 23:38 -0400, Mike Frysinger wrote:
> On Thursday 11 April 2013 22:34:43 John David Anglin wrote:
> > On 11-Apr-13, at 9:55 PM, Mike Frysinger wrote:
> > > On Sunday 07 April 2013 14:48:42 John David Anglin wrote:
> > >> On 7-Apr-13, at 2:39 PM, Mike Frysinger wrote:
> > >>> just to be clear, the only insn you need is:
> > >>> ble 0x100(%sr2, %r0);
> > >>>
> > >>> the kernel docs say sr2 holds the kernel gateway page (so i guess
> > >>> 0x100 is a
> > >>> known offset into that). the docs don't mention r0 that i can see,
> > >>> so i'm
> > >>> guessing it's one of those "always 0" registers ?
> > >>
> > >> Yes. There is also an entry at offset 0xb0 for light-weight-
> > >> syscalls. Currently,
> > >> this implements an atomic CAS operation used for pthread support.
> > >
> > > interesting. sounds like a poor man's vDSO. i'll document this the
> > > new
> > > vdso(7) man page.
> >
> > Not exactly, the code runs on the gateway page which is in kernel space.
> > The main reason for doing the operation in kernel space is to prevent
> > processes from being preempted while executing in the lock region. In
> > general,
> > parisc processes are not preempted on the gateway page. There are
> > some subtleties regarding fault handling.
>
> sure ... the Blackfin arch does a similar thing for providing fast atomic
> primitives to userspace since the ISA can't.
>
> what do you think of this section for vdso(7) ? i might have to split the
> "real" vdso arches from these others since there's a couple now (arm, bfin,
> parisc), and i think there might be more down the line (microblaze).
I've got to say, I really don't think this can be classified as a vdso.
For a vdso, the kernel exports an ELF object that can be linked
dynamically into any elf binary requiring it. The ELF section
information provides full details and so vdso entries can be called by
symbol.
In the parisc gateway page implementation, we have a set of "hidden"
primitives which the executable must know how to call (no self
description like a vdso). This mechanism is identical to the original
intent of the x86 int <n> instruction (an instruction that traps into
the kernel and performs some primitive action but to use it, you have to
know which function corresponds to which value of <n>).
James
> .SS parisc (hppa) functions
> .\" See linux/arch/parisc/kernel/syscall.S
> .\" See linux/Documentation/parisc/registers
> The parisc port has a code page full of utility functions.
> Rather than use the normal ELF aux vector approach, it passes the address of
> the page to the process via the SR2 register.
> This is done to match the way HP-UX works.
>
> Since it's just a raw page of code, there is no ELF information for doing
> symbol lookups or versioning.
> Simply call into the appropriate offset via the branch instruction, e.g.:
> .br
> ble <offset>(%sr2, %r0)
> .if t \{\
> .ft CW
> \}
> .TS
> l l.
> offset function
> _
> 00b0 lws_entry
> 00e0 set_thread_pointer
> 0100 linux_gateway_entry (syscall)
> 0268 syscall_nosys
> 0274 tracesys
> 0324 tracesys_next
> 0368 tracesys_exit
> 03a0 tracesys_sigexit
> 03b8 lws_start
> 03dc lws_exit_nosys
> 03e0 lws_exit
> 03e4 lws_compare_and_swap64
> 03e8 lws_compare_and_swap
> 0404 cas_wouldblock
> 0410 cas_action
> .TE
> .if t \{\
> .in
> .ft P
> \}
>
> > There is support in glibc and libgcc for these calls. The libgcc
> > implementation
> > in linux-atomic.c is very similar to that on arm.
>
> interesting. another arch to add :).
> -mike
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
