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