Re: sh3 mcontext change
"Valeriy E. Ushakov" <[email protected]> Sun, 1 Jun 2008 05:57:30 +0400
| Newsgroups | gmane.os.netbsd.ports.sh3,gmane.os.netbsd.devel.toolchain |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]>, > > Valeriy E. Ushakov <[email protected]> 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 -- [email protected] | Zu Grunde kommen http://snark.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen