Valeriy E. Ushakov | 26 May 19:46 2008
Picon

sh3 mcontext change

With NetBSD 5.0 looming, I'd like to fix a problem with sh3 mcontext
that's been there since the very beginning - it doesn't have a slot
for GBR register.

Currently kernel doesn't preserve GBR and userland doesn't use it
either - unless you write you own asm code, in which case you lose -
which is bad by itself already.  And GBR is also used by TLS, though
our ld.so doesn't support it yet.

The problem of course is how to change mcontext without breaking ABI
(sizeof(struct mcontext)).  Fortunately, it seems we have a slot we
can steal - we have _REG_EXPEVT slot in gregs and it seems it's
unused.  cpu_setmcontext() in the kernel doesn't set it for obvious
reasons and as far as I can tell no code ever examines it - all kernel
code that is interested in expevt uses trapframe for that.  Userland
code that might be interested in expevt (reason for the trap) already
gets the same info via siginfo.

So i would like to recycle that currently useless slot for GBR and
thus avoid breaking ABI.

Just in case - is there anything I'm missing here?  Any
objections/comments?

SY, Uwe
--

-- 
uwe <at> NetBSD.org                          | NetBSD/toaster:
http://snark.ptc.spbu.ru/~uwe/          | we wish the toaster to be happy too

(Continue reading)

Christos Zoulas | 26 May 20:35 2008

Re: sh3 mcontext change

In article <20080526174637.GE15029 <at> bigmac.stderr.spb.ru>,
Valeriy E. Ushakov <uwe <at> NetBSD.org> wrote:
>With NetBSD 5.0 looming, I'd like to fix a problem with sh3 mcontext
>that's been there since the very beginning - it doesn't have a slot
>for GBR register.
>
>Currently kernel doesn't preserve GBR and userland doesn't use it
>either - unless you write you own asm code, in which case you lose -
>which is bad by itself already.  And GBR is also used by TLS, though
>our ld.so doesn't support it yet.
>
>The problem of course is how to change mcontext without breaking ABI
>(sizeof(struct mcontext)).  Fortunately, it seems we have a slot we
>can steal - we have _REG_EXPEVT slot in gregs and it seems it's
>unused.  cpu_setmcontext() in the kernel doesn't set it for obvious
>reasons and as far as I can tell no code ever examines it - all kernel
>code that is interested in expevt uses trapframe for that.  Userland
>code that might be interested in expevt (reason for the trap) already
>gets the same info via siginfo.
>
>So i would like to recycle that currently useless slot for GBR and
>thus avoid breaking ABI.
>
>Just in case - is there anything I'm missing here?  Any
>objections/comments?

I think that it is best to look at what other OS's put in their context
and make all the fixes at once. We can change the size of the mcontext
if we version get/set/make context and the signal trampoline.

(Continue reading)

Valeriy E. Ushakov | 26 May 21:19 2008
Picon

Re: sh3 mcontext change

On Mon, May 26, 2008 at 18:35:24 +0000, Christos Zoulas wrote:

> In article <20080526174637.GE15029 <at> bigmac.stderr.spb.ru>,
> Valeriy E. Ushakov <uwe <at> NetBSD.org> wrote:
> > With NetBSD 5.0 looming, I'd like to fix a problem with sh3 mcontext
> > that's been there since the very beginning - it doesn't have a slot
> > for GBR register.
> >
> > Currently kernel doesn't preserve GBR and userland doesn't use it
> > either - unless you write you own asm code, in which case you lose -
> > which is bad by itself already.  And GBR is also used by TLS, though
> > our ld.so doesn't support it yet.
> >
> > The problem of course is how to change mcontext without breaking ABI
> > (sizeof(struct mcontext)).  Fortunately, it seems we have a slot we
> > can steal - we have _REG_EXPEVT slot in gregs and it seems it's
> > unused.  cpu_setmcontext() in the kernel doesn't set it for obvious
> > reasons and as far as I can tell no code ever examines it - all kernel
> > code that is interested in expevt uses trapframe for that.  Userland
> > code that might be interested in expevt (reason for the trap) already
> > gets the same info via siginfo.
> >
> > So i would like to recycle that currently useless slot for GBR and
> > thus avoid breaking ABI.
> >
> > Just in case - is there anything I'm missing here?  Any
> > objections/comments?
> 
> I think that it is best to look at what other OS's put in their context
> and make all the fixes at once. We can change the size of the mcontext
(Continue reading)


Gmane