Re: [PATCH] Remove MAX_REGISTER_SIZE from sol-thread.c

["Frank Ch. Eigler" <fche@redhat.com>]

Hi -

> > [...]  There was one on sourceware.org, but its web interface is no
> > longer operating, and scraps of the database files that are still
> > archived seem not to go up to 14571.  Likewise, no google hits.
> > 
> > So I'm at a loss, can't find orginal supporting data either, and
> > that's a bummer.
> 
> Thank you all the same.

Hold on!  Personal email archives to the rescue.  gdb/14571 was an
internal Cygnus PRMS bug number.  This was solaris 2.5.1 era.  

Here are some excerpts from emails on the topic.  Please excuse the
goofy "autoethnography", I'm just so weirdly gratified to have found
some traces of this old work!

------------------------------------------------------------------------

The problem was caused by sol-thread.c's inability to write to
individual registers in the target.  The updated value got lost in
sol_thread_store_registers before being written out.  The following
patch corrects the problem.

------------------------------------------------------------------------

>Can you send me a pointer to your toy test case?

Argh - I think I zapped it accidentally.  Basically it looked
like this:


void* thread_me(void* arg) { sleep(1); return arg; }

main()
 { 
   thread_t id;
   register int i;
   thr_create(NULL, NULL, thread_me, NULL, <flags>, &id);
   /* breakpoint here */
   i = 0;
   i = 1;
   i = 2;
 }


I fidgeted with the <flags> to get various THR_* combinations.

My desired test was to be unable to change the register variable i by
commands like "p (i=4)" from the debugger, after the breakpoint is
hit.  (Before my patch, I would expect the new value to be clobbered.)
I wanted gdb to go through the sol-thread.c's register-setting function,
but the bugger would not go near it.

------------------------------------------------------------------------

>[...]
>Can you tell me a bit how you figured gdb/14571 out. I am
>seeing more multithread releted bugs and I was hoping you
>could share some hints and methods.

Sure, though I must admin it was just plain ordinary
perseverance rather than any special technique.  As I recall,
I went along steps like these:

- traced backward from the "target halted while in function"
  call to the expression parser
- figured out the mechanism used to make inferior calls
  (that ugly stack frame stuff, and the pre-assembled
  block of instructions)
- convinced myself that the code should work, mostly by
  very slow single-stepping in the region
- found the bunch of routines that get/set inferior
  registers
- figured out weird register caching mechanism
- traced it work through the thread_db & procfs calls; it
  worked for threads fine
- found, by breakpoints, that the PC set in the cache at
  an earlier point was reset to an old value, before control
  was handed to the target - an anomaly
- let a very slow watchpoint run go overnight to find who
  was overwriting the PC slot in the cache
- eureka one morning: watchpoint triggered at around 8 AM. :)
- a bug in the threads/procfs code caused the register cache
  to be invalidated (re-read), if not all registers were
  desired to be updated

It was cool, but as you see, nothing very special in reasoning.
I just eliminated a bunch of possible problems, and learned how
registers, threads, and inferior calls were supposed to work,
and then ultimately found one anomaly.  The watchpoint mechanism
could then (very slowly) find the anomaly's trigger.

------------------------------------------------------------------------


- FChE