This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfa] Update PC without side effect in displaced stepping


On 12/20/2010 09:42 PM, Yao Qi wrote:
> On 12/20/2010 04:04 PM, Mark Kettenis wrote:
>>
>> Sorry, no this isn't right.  On sparc and hppa for example, the
>> effects of write_pc() are needed here, since both the pc and the "next
>> pc" registers need to be updated to make sure all instructions in the
>> copy area get executed.
>>
> 
> I know very little on sparc and hppa.  Thanks for your explanation.

When writing the new patch, I re-consider this problem again.  GDB
doesn't support displaced stepping on sparc and hppa, so it is not
harmful to sparc and hppa when regcache_write_pc is replaced by
regcache_cooked_write_unsigned.
Currently, GDB supports displaced stepping on s390, rs6000 (including
ppc-linux, aix), i386, amd64 and arm.  AFAICS, this replacement in my
original patch is not harmful to these targets.

>> I think you'll have to make sure that if the displaced instructions
>> are Thumb instructions, the copy area gets properly marked as Thumb
>> such that write_pc() can do the right thing on arm as well.
> 
> That works.  If we do so, given an address of an instruction, we have to
> return the mode of original instruction in displaced stepping, and
> return real mode there otherwise.  However, current GDB dose not provide
> interfaces to target-dependent parts to query the state of displaced
> stepping.  Shall we refactor infrun.c a little bit to move some code to
> displace_step.[c|h], and expose them to target-dependent part?

My new patch is drafted in this way, but it looks not better than my
original one, because in my new patch, some state of displaced stepping
has to be exposed to arm-tdep.c in order to return the correct mode (ARM
or Thumb) according to the address of copy area.  Unless we make some
refactor to extract displaced stepping from infrun, this approach makes
code looks ugly.

Given my original patch is clean, and not harmful to existing targets
support displaced stepping, please consider my original patch again.
Comments on promising directions/approaches are welcome.

-- 
Yao (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]