[9fans] extern register

[9fans] extern register

[cinap_lenrek]

the amd64 compiler reserves R14 and R15 for extern register
declarations. these are used by the kernel for the mach
and up pointers, but currently are not preserved during
system calls.

would it make sense to save and restore the two registers
on syscall entry/exit, so userspace programs could make use
of them for per process data?

--
cinap

Re: [9fans] extern register

[erik quanstrom]

On Fri Jul 18 21:58:37 EDT 2014, cinap_lenrek@felloff.net wrote:
> the amd64 compiler reserves R14 and R15 for extern register
> declarations. these are used by the kernel for the mach
> and up pointers, but currently are not preserved during
> system calls.
>
> would it make sense to save and restore the two registers
> on syscall entry/exit, so userspace programs could make use
> of them for per process data?

i think after some experience (i.e. mistakes) the answer is probablly, no.

the compiler needs to know for the kernel that r14 and r15 are special and
not allocate them for the kernel, but what about userland?  what about libraries
that are shared between them? ....

one can work around these problems by compiling all libraries twice, etc.
but these are painful compromises.

in reality, there is only one place in the code that i know of that chews
through 15 or more registers, and that's the alpha drawing code in
libmemdraw.  so the solution of just limiting the compiler to r0-r13
seems to be pretty effective for what we're doing.

- erik

Re: [9fans] extern register

[erik quanstrom]

On Fri Jul 18 22:05:32 EDT 2014, quanstro@quanstro.net wrote:
> On Fri Jul 18 21:58:37 EDT 2014, cinap_lenrek@felloff.net wrote:
> > the amd64 compiler reserves R14 and R15 for extern register
> > declarations. these are used by the kernel for the mach
> > and up pointers, but currently are not preserved during
> > system calls.
> >
> > would it make sense to save and restore the two registers
> > on syscall entry/exit, so userspace programs could make use
> > of them for per process data?
>
> i think after some experience (i.e. mistakes) the answer is probablly, no.
>
> the compiler needs to know for the kernel that r14 and r15 are special and
> not allocate them for the kernel, but what about userland?  what about libraries
> that are shared between them? ....
>
> one can work around these problems by compiling all libraries twice, etc.
> but these are painful compromises.
>
> in reality, there is only one place in the code that i know of that chews
> through 15 or more registers, and that's the alpha drawing code in
> libmemdraw.  so the solution of just limiting the compiler to r0-r13
> seems to be pretty effective for what we're doing.

i realize i didn't quite answer the question as asked.  restoring
the registers is independent of the compiler.  so yes, you're right!  the registers
should be restored.  but at least you know why it's not a disaster that
they are not.

- erik

Re: [9fans] extern register

[cinap_lenrek]

isnt that contradicting what you just said?

--
cinap

Re: [9fans] extern register

[erik quanstrom]

On Fri Jul 18 22:34:43 EDT 2014, cinap_lenrek@felloff.net wrote:
> isnt that contradicting what you just said?

i didn't think so.  restated: you could restore the registers, and that
would be right proper, but it wouldn't make a difference unless you're
using some fancy assembly, or a different compiler; it doesn't give the
compiler more freedom.

- erik

Re: [9fans] extern register

[cinap_lenrek]

so, we say r14 and r15 arent really special for user programs. and its
just a c compiler implementation detail that it doesnt allocate these
registers, but assembly code can freely use them for scratch space
or whatever. extern register will not work in userspace c programs
because syscalls will trash these registers.

makes any sense?

--
cinap

Re: [9fans] extern register

[erik quanstrom]

On Fri Jul 18 22:28:12 EDT 2014, cinap_lenrek@felloff.net wrote:
> so, we say r14 and r15 arent really special for user programs. and its
> just a c compiler implementation detail that it doesnt allocate these
> registers, but assembly code can freely use them for scratch space
> or whatever. extern register will not work in userspace c programs
> because syscalls will trash these registers.
>
> makes any sense?

certainly.

speaking for myself, the model that r14 and r15 are off limits for
esoteric reasons is preferrable, given the quite limited maximum
benefit, to the complications of sneaking by the limitation.

obviously, the mips port avoided this by never needing >28 live
registers at once.

- erik

Re: [9fans] extern register

[Aram Hăvărneanu]

I don't have any opinion on whether R14 and R15 should be saved, but
the justification posted in the top post seems weak.

The stack is already per-process data. One can use _tos for per-proc
data, just like privalloc(2) does.

-- 
Aram Hăvărneanu

Re: [9fans] extern register

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On 19 July 2014 02:57, <cinap_lenrek@felloff.net> wrote:

> would it make sense to save and restore the two registers
> on syscall entry/exit, so userspace programs could make use
> of them for per process data?
>

Good question. None of the others need to be saved and restored because
they are defined to be dead on entry to a function,
but you're right that rule doesn't really apply to extern register, and
they could be useful. _tos only works when every process has
at least one stack always at the same fixed virtual address. On the other
hand, a kernel that provides an alternative to that would
also know to save and restore extern registers.

[-- Attachment #2: Type: text/html, Size: 1118 bytes --]

Re: [9fans] extern register

[Aram Hăvărneanu]

On Sat, Jul 19, 2014 at 2:42 PM, Charles Forsyth
<charles.forsyth@gmail.com> wrote:
> _tos only works when every process has
> at least one stack always at the same fixed virtual address.

Isn't this always true?

-- 
Aram Hăvărneanu

Re: [9fans] extern register

[erik quanstrom]

On Sat Jul 19 10:40:49 EDT 2014, aram.h@mgk.ro wrote:
> On Sat, Jul 19, 2014 at 2:42 PM, Charles Forsyth
> <charles.forsyth@gmail.com> wrote:
> > _tos only works when every process has
> > at least one stack always at the same fixed virtual address.
>
> Isn't this always true?

does anyone have a use case for extern register in user space?

come to think of it, extern register is defined to be one register
per mach, which is a bit of a stretch for user space.

- erik

Re: [9fans] extern register

[Aram Hăvărneanu]

On Sat, Jul 19, 2014 at 4:55 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> does anyone have a use case for extern register in user space?

Well Go uses it, but the meaning is different than in the Plan 9
kernel; they reused it for a different storage class.

In Go, there were two external register variables, g and m (now
there is only one for reasons outside the scope of this discussion).
These variables are proc-local as oposed to mach-local. To make a
streched analogy, a proc is to Go as a mach is to the kernel. Both
are some "entities" which can "run" other schedulable entities (Go
now has g's, m's, and p's, so the analogy no longer holds, but that
was the original meaning).

On arm, these variables are kept in registers on all operating
systems. On 386 and amd64, non-Plan 9 systems use a form of TLS to
keep these variables. TLS usually requires libc.so and ld.so
interaction (ugh), so since Go doesn't usually use these, it usually
executes some system call which sets up the base segment registers
to some heap-allocated memory, and then accesses this space using
the segment registers.

On systems which don't have these special system calls, the base
registers are usually initialized by the kernel/libc.so/ld.so with
enough space for some slots, so the access is the same, only without
initialization.

Plan 9 has no such nonsense; the stack is at a fixed, and known
address, so these variables can be kept on the stack. I recently
simplified this for the plan9/386 Go port and made the plan9/amd64
Go port use the same mechanism.

-- 
Aram Hăvărneanu

Re: [9fans] extern register

[cinap_lenrek]

ok, i preserve user R14 and R15 now. also removed the saving and restoring
of DS/ES/FS/GS segment registers... they have no effect in long mode and
there are no 32 bit tasks.

someone write a proof of concept program that communicates with another
process by morsing data on the segment registers by loading them with
NULLSEL and UDSEL :)

--
cinap

Re: [9fans] extern register

[Aram Hăvărneanu]

On Sun, Jul 20, 2014 at 3:42 AM,  <cinap_lenrek@felloff.net> wrote:
> removed the saving and restoring
> of DS/ES/FS/GS segment registers... they have no effect in long mode

Actually FS and GS do work in long mode. Since we don't need them for
TLS, maybe we can do something useful with them.

-- 
Aram Hăvărneanu

Re: [9fans] extern register

[cinap_lenrek]

it doenst matter to runtime what data segment selectors have been
loaded in the segment registers in long mode. we initially load
them with null seletors and then never touch them again.

but the processor *does* check the selectors index when you load
a selector into a segment register!

the reason i removed the saving and restoring is that i can stop
worrying about bad data selectors when devproc or noted sets the ureg
of a process.

we had todo this on 386 because otherwise the process would #GP when
trying to restore the bad selectors. now without restoring the segment
registers, it cant #GP and nothing needs to be checked.

for GS/FS theres new GS_BASE and FS_BASE msr register that the kernel
can set to change GS and FS segment offsets affetcing the offset used
by GS and FS segment prefixes. but the kernel would need to switch
these msrs in and out for each process and provide a interface
for userspace to set ther base. you will need this for something
like linuxemu.

--
cinap