This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: MI set thread command
On Wed, Sep 08, 2004 at 09:45:30AM +0200, Fabian Cenedese wrote:
> (gdb) s
> Sending packet: $vCont?#49...Ack
> -- test if vCont is supported
> Packet received: vCont;c;s
> Packet vCont (verbose-resume) is NOT supported
> -- why test for single actions if all are necessary? could vCont be expanded?
That's right, it's for future expansion.
> from remote.c
> /* If s, S, c, and C are not all supported, we can't use vCont. Clearing
> BUF will make packet_ok disable the packet. */
I think this could be fixed, since we support running without S and C,
and on some targets even without s. I just didn't have a reason to do
it when I added vCont.
>
>
> Sending packet: $Hc0#db...Ack
> Packet received: OK
> -- select thread with id 0 for cont/step
>
> Sending packet: $S04#b7...Ack
> -- step with signal 04 (SIGILL...?)
> Packet received:
> Can't send signals to this remote system. SIGILL not sent.
> -- nope, signals are not supported on the embedded system
>
> Sending packet: $s#73...Ack
> -- step normal
>
>
> Hc Zero means "pick any thread". Why should this be when I want to
> single-step exactly thread 23 and no other? Does this only work with
> vCont (and not s)?
Correct.
> I then implemented all vCont actions and got to this:
>
>
> ->$vCont;s:d270;c#8d
> <-$S05#b8
You may want to implement T...
>
> ->$g#67
> <-$00000000001649e000164ae0001...
>
>
> So gdb debugs a thread and asks registers, and the registers of course need to
> come from the same thread. Which registers do I need to return now? The ones
> from the last Hgt command? Or the ones from the last vCont;s command? Or
> should they be the same anyway?
This is a little fuzzy in the protocol; might want to take a look at
how gdbserver handles it. I know that if the resume reply specifies
thread:, that sets GDB's idea of where to expect registers from. If it
doesn't, I am not sure what happens.
--
Daniel Jacobowitz