Re: [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #3

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Fri, 30 Dec 2011 11:38:59 +0100, Mark Kettenis wrote:
> I'm still a little bit worried that Jan's approach is making
> additional assumptions.  The chance that the 2nd instruction of the
> program will be executed again as part of the normal flow is probably
> not much higher than for the 1st instructions,

The patched code does not use the original entry_point_address in any way,
it passes to gdbarch_push_dummy_call already the adjusted address as bp_addr.

This is also the reason why it no longer uses gdb_buffered_insn_length but
just gdbarch_breakpoint_from_pc's bp_len is enough.  We may place the
breakpoint inside the first instruction ("corrupting" it) but as the first
instruction is not used anywhere it does not matter.  The inferior call will
return right to our placed breakpoint address.


> And I know Jan has checked his diff on ia64, but there might be other
> architectures that have the concept of instruction bundles where jumping
> into the middle of a bundle doesn't work.

It is only important entry_point_address + bp_len is still a valid placement
for a breakpoint.  ia64 will place it to the next bundle (+16 bytes) which
will work.

Still I can imagine for example big endian architecture with 32-bit fixed
lenght instructions where any opcode 0xFF?????? is a breakpoint and therefore
its gdbarch_breakpoint_from_pc returns BP_LEN as 1.  But we cannot place
our breakpoint on entry_point_address + 1.  Unaware if such arch exists.
My patch would break such arch.  It also means the current
displaced_step_at_entry_point implementation for displaced stepping would not
work on that arch, if one would try to implemented displaced stepping there.


Thanks,
Jan