Pedro Alves <palves@redhat.com> writes:
Of a random PC address no, but in gdbserver's case, I think that it
would work, because we need it to step over a breakpoint that is
at the current PC. So we could:
#1 - Get the mode of the current PC from the thread's $cpsr register.
#2 - Get the mode of the next PC by looking at the instruction that is
about to be executed (at current PC). If bx and blx, which change
modes, check the thumb bit of the destination address.
For all other instructions, same mode as the current PC.
We can know the mode of the next PC in this way, but we don't know the
address of the next PC. In fact, we need to know the address of the
next PC first, and then determine the mode of the next PC. Probably, we
need something as below,
1. Teach GDBserver to compute the address of the next PC,
2. Determine the mode of the next PC as you suggested,
3. Add breakpoint_from_pc hook in target_ops, so that the right
breakpoint instruction can be selected.
After thinking about how to teach GDBserver inserting right breakpoint
(arm or thumb) for a while, I reconsider it from a different direction
that it may be unreasonable to run target-side conditional breakpoint for
targets without hardware single step. Pedro also pointed this out here
https://sourceware.org/ml/gdb-patches/2015-04/msg00337.html
In the end I was somewhat convinced that things ended up working.
But I certainly don't object to this patch.
+ /* Although win32-i386 has hardware single step, still disable this
+ feature for win32, because it is quite GNU/Linux specific. */
+ NULL, /* supports_conditional_breakpoints */
TBC, it's not that the feature is GNU/Linux specific (like something
related to system calls or some detail in glibc), but that the support
for conditional breakpoints is baked into linux-low.c instead of
in generic code.
How about writing comments like this?
/* Although win32-i386 has hardware single step, still disable this
feature for win32, because it is implemented in linux-low.c instead
of in generic code. */