Port-sh3 archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: sh3 mcontext change
On Mon, May 26, 2008 at 23:19:07 +0400, Valeriy E. Ushakov wrote:
> On Mon, May 26, 2008 at 18:35:24 +0000, Christos Zoulas wrote:
>
> > In article <20080526174637.GE15029%bigmac.stderr.spb.ru@localhost>,
> > Valeriy E. Ushakov <uwe%NetBSD.org@localhost> 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.
>
> As far as I can tell (reading ABI and ISA docs) everything else i
> accounted for (including FPU placeholder) - only GBR is missing.
>
> Linux has an additional sc_ownedfp member in its sigcontext (which
> they use for uc_mcontext), but I guess that corresponds to our _UC_FPU
> flag.
Damn, I knew I was missing something. While it's ok to recycle
_REG_EXPEVT for mcontext and preserve the size, there's another
structure to worry about - struct reg used by ptrace(2).
But as PT_GETREGS/PT_SETREGS are machine-dependent we should be able
to version it easily.
Anything *else* I'm missing?
SY, Uwe
--
uwe%stderr.spb.ru@localhost | Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
Home |
Main Index |
Thread Index |
Old Index