bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#440068: gnumach: GPT in fp_save, fpu.c:675


From: Thomas Schwinge
Subject: Re: Bug#440068: gnumach: GPT in fp_save, fpu.c:675
Date: Thu, 30 Aug 2007 01:11:23 +0200
User-agent: Mutt/1.5.11

Hello!

On Wed, Aug 29, 2007 at 11:12:14PM +0200, Samuel Thibault wrote:
> Thomas Schwinge, le Wed 29 Aug 2007 22:44:06 +0200, a écrit :
> > Why isn't that patch in upsteam cvs?  Does it need more testing (as this
> > bug report might indicate)?
> 
> Well, the buildd tested it pretty well, and yes, this bug needs to be
> fixed. Then it should be ok to commit. The MMX support is not complete
> however: we need to extend the kernel/user get_state interface so that
> gdb can fetch the mmx registers of another task for instance.

Okay.  What other use cases are there apart from gdb?  If it's only gdb
then we can probably postpone it into a wishlist-task item.


> > > fnsave would be fine.
> > 
> > Also without the ``0 -> 16'' alignment patch?
> 
> Yes. fnsave doesn't have such alignment requirement.

Ah.  Then I mis-interpreted my Intel manuals.


> > > > > looks like there is a bug somewhere in the alignment support of
> > > > > zalloc().
> 
> The only bug I can see here is
> that zalloc() doesn't always correctly align data.

So it's in the rather freshly added zalloc alignment support itself.


> 0->16 is not in
> upstream CVS because upstream CVS always uses fnsave, not fxsave, so
> such alignment is not required there.  Debian's version uses fxsave, so
> it is there (and 0->16 is hence already there).

Understood.


Regards,
 Thomas

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]