Date: Wed, 06 Feb 2002 22:36:13 -0800 From: Peter Wemm <peter@wemm.org> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Dan Eischen <eischen@vigrid.com>, arch@FreeBSD.ORG Subject: Re: getsetcontext system call Message-ID: <20020207063613.C1C9839F1@overcee.wemm.org> In-Reply-To: <Pine.GSO.4.10.10202062343010.9472-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > On Wed, 6 Feb 2002, Peter Wemm wrote: > > Daniel Eischen wrote: > > > On Wed, 6 Feb 2002, Peter Wemm wrote: > > > > Dan Eischen wrote: > > > > > > > > > Diffs are at: > > > > > > > > > > http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs > > > > > http://people.freebsd.org/~deischen/ucontext/uc-libc.diffs > > > > > > [..] > > > As to set_fpregs(), it looks like it wants to convert an x87 > > > FPU state to an SSE FPU state. The opposite seems to be the > > > case for fill_fpregs(). I'm not exactly sure how and why > > > fill_fpregs() and set_fpregs() are used. Since we make struct > > > fpreg large enough to hold either x87 or SSE FPU state, do we > > > even care about converting between the two different formats > > > any longer? > > > > I think we have to, because xmm state is a superset of the x87 state, and > > we need to not f*ck up defined interface to ptrace(PT_SETFPREGS etc and > > procfs where you supply an entire 'struct fpregs' to these calls. > > OK, what if we leave struct fpreg unchanged? > > > Imagine running a 4.x binary where it does a ptrace(PT_GETFPREGS, &fpregs); > > where '&fpregs' points to the traditional sized structure. You cant just > > change the size of it without doing things like assigning new syscall numbe rs > > to ptrace(2) etc and adding some workaround glue to procfs. > > Right, I don't want to get into that now. Some time later we could > add the format specifier in struct fpreg and teach consumers how to > decipher it. How else could users of ptrace(PT_GETFPREGS, &fpregs) > know what the FP format was? If the format was included in the struct, > then they could figure out on their own which format to use. > > > We may need to do what linux does (SET/SET_FPXREGS) and maybe /proc/*/fpxre gs. > > Ugh. Anyway, I dont see that you can just change 'struct fpregs' that > > easily. The union may have to be moved up higher for x86.. > > Is it OK to leave struct fpreg unchanged for now? To be quite honest, I think that's the right thing to do for now, until it is clear what the "right" thing to do is. ptrace(2) isn't going to survive KSE unscathed, so perhaps we need an enhanced ptrace interface at some point that doesn't suffer from this kind of interface fragility. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020207063613.C1C9839F1>