Hacking gdbserver to capture instruction-level code coverage

Hacking gdbserver to capture instruction-level code coverage

[Ron McCall]

Hi,

I have attempted to hack gdbserver 6.5 to log
instruction-level code coverage on a powerpc-linux
system and it seems to work except that examining
variables is broken as a result.  Turning on remote
debugging in gdb and comparing a run using an
unmodified gdbserver and the modified gdbserver seems
to show a difference with the DBAT0 register mapping
in the 'g' packet responses.  It would seem that my
changes have somehow violated something and perhaps
has confused the Linux kernel?

More specifically, I have changed handle_v_cont() in
server.c to do a repeated single step rather than a
continue.  I let the resume_info get built as usual
(and only once), except in the 'c' or 'C' case where I
set resume_info[i].step=1 (since we'll be stepping
repeatedly instead).  Then, at the bottom of the
function, I loop repeatedly, resuming the inferior,
waiting for it to stop, getting the PC of the inferior
and logging it, and then determining whether to repeat
or break out of the loop (based on whether we are
single stepping, continuing or there's a breakpoint at
the current PC location).  After the loop, I free the
resume_info and prepare the resume reply as usual.

Does any of this sound particularly evil?  I can
provide the small patch against the 6.5 source if
anyone needs to see the changes in more detail.

Thanks!
Ron McCall

Re: Hacking gdbserver to capture instruction-level code coverage

[Daniel Jacobowitz]

On Wed, Jun 21, 2006 at 08:28:10AM -0700, Ron McCall wrote:
> I have attempted to hack gdbserver 6.5 to log
> instruction-level code coverage on a powerpc-linux
> system and it seems to work except that examining
> variables is broken as a result.  Turning on remote
> debugging in gdb and comparing a run using an
> unmodified gdbserver and the modified gdbserver seems
> to show a difference with the DBAT0 register mapping
> in the 'g' packet responses.  It would seem that my
> changes have somehow violated something and perhaps
> has confused the Linux kernel?

At this point you've lost me.

The PPC 'g' packet contains r0-r31, f0-f31, pc, ps, cr, lr, ctr, xer,
and fpscr.  The BAT registers aren't involved at all; I don't even
think they're usable from userspace.

> Does any of this sound particularly evil?  I can
> provide the small patch against the 6.5 source if
> anyone needs to see the changes in more detail.

Evil but functional, as long as you're being careful to not lose track
of signals.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Hacking gdbserver to capture instruction-level code coverage

[Ron McCall]

--- Daniel Jacobowitz <drow@false.org> wrote:
> At this point you've lost me.
> 
> The PPC 'g' packet contains r0-r31, f0-f31, pc, ps,
> cr, lr, ctr, xer,
> and fpscr.  The BAT registers aren't involved at
> all; I don't even
> think they're usable from userspace.

Oops, I made a mistake decoding the registers...FPRs
are 64 bits each, not 32 bits!  Gotta go back and
re-examine the correctly decoded registers to see
what's different for real this time.  Thanks for
pointing out that stupid error.

> Evil but functional, as long as you're being careful
> to not lose track
> of signals.

I believe I am not losing any signals except for the
intermediate SIGTRAPs resulting from repeated single
steps (all but the last one).

Ron