Re: [patch] "single step" atomic instruction sequences as a whole.

[Emi SUZUKI <emi-suzuki at tjsys dot co dot jp>]

Hello Luis,

Thank you for your reply.  

* On Wed, 07 Feb 2007 11:10:01 -0200, Luis Machado wrote:
> What's exactly been modified on your patch for single stepping of atomic 
> instruction sequences?

OK, I will explain about them one by one.  

First, I defined the entity of SOFTWARE_SINGLE_STEP_P macro on
rs6000-tdep.c. It returns true if the new function
'rs6000_deal_with_atomic_sequence' returns a non-zero value, say,
skipping an atomic sequence instruction is needed.  

'rs6000_deal_with_atomic_sequence' is derived from Paul's patch to
search the subsequent instructions: it start reading instructions from
PC and returns the address which indicates the end of the atomic
sequence if any is found.  It is also called by 'rs6000_software_single_step' 
to get the address to which a software single-step breakpoint will be
set.  'rs6000_software_single_step' is set to gdbarch by
'set_gdbarch_software_single_step'.  

Note that the gdbarch definition for RS6000 is also used when GDB was
configured for the POWER architectures, so the modification also
effects on ppc*-linux configuration without defining in ppc-linux-tdep.c.  
# I didn't see any differences between the patchs for those two files 
# which you have resent, but point me out if I have missed something.  

By the changes above, GDB sometimes makes the target do software 
single-stepping even if the target environment supports hardware
single-stepping: the basic behavior is the same as what Paul's
patchset does.  

But the function handle_inferior_event, defined in infrun.c, has some
codes based on the assumption that the status of hardware
single-stepping support is not changed during the debugging session.  
So I removed these codes.  

And the thread hopping procedures should be done when the thread other
than the one doing software single-stepping runs on a stop-code for
software single-stepping.  It can also occur while "temporary
software single-stepping" is being done, but handle_inferior_event 
doesn't take those things into consideration.  

So I added the code to save 'singlestep_ptid' in resume, even when
a hardware single-stepping will be done.  It will be compared with
the ptid of the trapped thread for checking if the thread hopping
occured.  

> Does it handle the issues that you have mentioned 
> about thread hopping check?

It should do, logically.  But I have checked only on our hardware.  
I will appreciate if you check it on your environment.  
Maybe I should write a test code for testsuite...

Best regards, 
-- 
Emi SUZUKI