This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Unifying the x86 FPU register sets



> If GDB can easily handle 48 bit registers, I'd prefer just having $fip
> and $fop.  info float and/or info all-registers could print them in
> seg:offset form if desired.

GDB can probably handle 48-bit values.  Your host has to have a `long
long' type, though.

But I don't like the idea of concatenating the offset and segment.
They're two distinct components, with different interpretations.  If
you were trying to concoct a concrete representation of far pointers,
then a series of six bytes would make sense, but it doesn't seem like
a very good way to think about them, or for GDB to present them.

> Jim> We could make the control registers (except $fdoff and $fcoff)
> Jim> sixteen-bit values.  But that makes more work for platforms that
> Jim> do use FSAVE's 32-bit format; I assume those are the majority.
> 
> Is there any reason that we can't have 'holes' in the byte array that
> holds the register values?  We could have 16 bit registers separated
> by 16 bit holes.  

I don't know of any code this would break (aside from the code I just
put in i386-tdep.c to compute reg offsets from sizes, no big deal),
but it feels like we're invoking the wrath of evil spirits.  :(

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]