* [RFC] i386 SSE registers
@ 2003-12-12 17:06 Mark Kettenis
2003-12-13 18:49 ` Jim Blandy
0 siblings, 1 reply; 3+ messages in thread
From: Mark Kettenis @ 2003-12-12 17:06 UTC (permalink / raw)
To: gdb
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] i386 SSE registers
2003-12-12 17:06 [RFC] i386 SSE registers Mark Kettenis
@ 2003-12-13 18:49 ` Jim Blandy
2003-12-14 15:34 ` Mark Kettenis
0 siblings, 1 reply; 3+ messages in thread
From: Jim Blandy @ 2003-12-13 18:49 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gdb
I'm not sure I understand how the various options you list would
appear to the user. It sounds like, in any proposal, the SSE
registers would just have bogus values when they're not available. Is
there some way that the SSE regs could instead cease to exist
(i.e. "print $xmm0" would give you a void value, 'info regi sse' would
give you an error message)? Or is there some other non-invasive
behavior which would make it clearer to the user what was going on?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] i386 SSE registers
2003-12-13 18:49 ` Jim Blandy
@ 2003-12-14 15:34 ` Mark Kettenis
0 siblings, 0 replies; 3+ messages in thread
From: Mark Kettenis @ 2003-12-14 15:34 UTC (permalink / raw)
To: jimb; +Cc: gdb
From: Jim Blandy <jimb@redhat.com>
Date: 13 Dec 2003 13:46:40 -0500
I'm not sure I understand how the various options you list would
appear to the user. It sounds like, in any proposal, the SSE
registers would just have bogus values when they're not available.
Yup. It's either
1a. All zeroes.
1b. All zeroes, but preserving any explicit (but otherwise pointless)
changes made by the user.
2. Some faked values (presumably corresponding to a freshly
initialized CPU).
Is there some way that the SSE regs could instead cease to exist
(i.e. "print $xmm0" would give you a void value, 'info regi sse'
would give you an error message)? Or is there some other
non-invasive behavior which would make it clearer to the user what
was going on?
You can't solve this via the architecture vector I think. It's
possible to use the same GDB and use it to debug a program on a
machine without SSE and then later on a machine with SSE.
What we could do is add a per-register flag to the register cache that
says whether a register is actually present or not. But that's quite
a bit of work I guess. Don't think we should think about doing
something like that before the legacy stuff has been eradicated.
Mark
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-12-14 15:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-12-12 17:06 [RFC] i386 SSE registers Mark Kettenis
2003-12-13 18:49 ` Jim Blandy
2003-12-14 15:34 ` Mark Kettenis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox