This is the mail archive of the gdb@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: Implementation of different software breakpoint kinds in gdb server


On 10/18/2012 12:09 PM, Pedro Alves wrote:
> Extending mem-break.c is not the big problem, IMO.  

But we'd probably have to change its interface a bit. So there would be also
changes needed in the architecture specific files like linux-*-low.c.
However, these changes would probably trivial for most architectures because
usually there is only one kind of trap instructions.

> The RSP already supports this, with the mode encoded in the "size" field
of the z0 packet.

That's right, but the RSP does not support specifying kinds/sizes in the
QTDP packets, which are used for adding tracepoints, but that's a different
story. I added a enhancement request on bugzilla today, maybe there will be
some feedback: http://sourceware.org/bugzilla/show_bug.cgi?id=14740

> So we'd need to teach gdbserver to software single-step.  Maybe it's
possible to tell offline all the possible destinations of an instruction, so
we could still leave that logic in gdb, but I suspect not.

It's generally not possible. Of course, some instructions can never cause a
branch, so in these cases we could safely set the "reinsert-breakpoint" at
the next instruction. But some branch instructions read the branch
destination from a register. In this case we can only evaluate the next PC
value when the breakpoint is hit. 

Teaching gdbserver to single-step shouldn't be too hard. As you mentioned,
the logic is already there in gdb. I even found the code to do this in
arm-tdep.c (e.g. arm_get_next_pc). We could use it as a base to implement it
in gdbserver, but we would have some code duplication.

> I don't know whether the current kernel can already do all that for us?
(perf, uprobes, etc?)

I tried uprobes, but it works in a different way. Instead of single
stepping, uprobes simulates (or emulates) the instruction, which was
replaced by the breakpoint. (It executes the instruction out-of-line and
jumps back to the original code. If this is not possible, it just looks at
the original instruction and modifies the registers and memory itself. This
solution has the advantage that it doesn't need to stop other threads while
one thread is single-stepping). Anyway, as far as I know uprobes does not
work on ARM yet. 

Michal Lesniewski



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