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

Emi SUZUKI
2007-02-08T13:00:19Z

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