The solaris thread support does the same thing. And that code
uses the more correct regcache_raw_collect() which is partly how
I noticed this.
What's happening here is that if we're only writing one register
we make sure to read in all the other registers first, then we
write the changing register back into the regcache.
This is interrelated with another piece of gdb code history I
was researching last night when I ran across this. Several
platforms used to define CHILD_PREPARE_TO_STORE in order to
deal with interfaces, such as some ptrace() variants, that can
only set the whole set of registers at once.
There are some really nasty cases on Sparc for example, say you
want to write just the stack pointer. We obtain the local and
in registers from the on-stack save area, so if we were not careful
just changing the stack or the frame pointer would cause all of
those other registers to change even though that is not what we
intended. So to do it right, you have to read all the registers
into the regcache, then modify the stack or frame pointer.
This CHILD_PREPARE_TO_STORE macro would get invoked by the
target_prepare_to_store(). If you look at the regcache code it always
does a sequence like this:
target_prepare_to_store ();
memcpy (register_buffer (regcache, regnum), buf,
regcache->descr->sizeof_register[regnum]);
regcache->register_valid_p[regnum] = 1;
target_store_registers (regnum);
So, if necessary, target_prepare_to_store() would make sure the
regcache was fully read in if not already, then it would be safe to
write into the register cache.
But it seems that Mark Kettenis has been trying to transition
away from this deprecated scheme, and instead handle this issue
inside of the store register methods of the individual targets
and native support modules.
In fact, the only platform defining CHILD_PREPARE_TO_STORE is
GNU Hurd on x86, and probably that will eventually be eliminated
as well, and along with it target_prepare_to_store() and all
assosciated hooks.
In any event, the code we are discussing here in the Linux thread_db
code really is needed and it's related to the issues I've discussed
above.
So I think it's ok to apply this :-)