This is the mail archive of the gdb@sources.redhat.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]
Other format: [Raw text]

[RFC] i386 SSE registers


Some time ago, I unconditionally enabled the SSE registers in the i386
target.  On (sub-)targets that don't provide these registers[1] we now
have a slight discrepancy.  A native GNU/Linux GDB will set these
registers to some non-zero dummy values.  In all other cases the
registers are left alone, which means that they're initialized to zero
when GDB creates its register cache, and stay that way, unless the
user explicitly sets them to some other value.  I'd like to get rid of
this discrepancy.  However, since this will result in a user-visible
change, and since I'm not very familliar with SIMD programming, I'd
like to hear some opinions first.  Here are the three options I'm
considering:

1. Set the SSE registers to the dummy values that the native GNU/Linux
   GDB provides.

2. Leave the SSE registers alone like we do for the other cases right now.

3. Set the SSE registers explicitly to zero everytime we read the FPU
   registers.

Personally I'm leaning towards option 2, since it allows us to detect
that the SSE registers aren't there by using regcache_valid_p().

Thoughts?

If nobody objects, I'll change the native GNU/Linux GDB around Christmas.

Cheers,

Mark


[1] Either because the underlying OS doesn't (fully) support them, the
    remote protocol doesn't support them or the code is executing on a
    CPU that doesn't support them.


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