On 10/08, Pedro Alves wrote:
>
> On Thursday 07 October 2010 23:59:22, Oleg Nesterov wrote:
> > Hmm. Not sure I understand this... gdb could issue a series of Hc+c
> > after s to do "step a thread and resume all others".
> >
> > But this doesn't matter. Obviously vCont is better and more handy.
>
>
On Thursday 07 October 2010 23:59:22, Oleg Nesterov wrote:
> Hmm. Not sure I understand this... gdb could issue a series of Hc+c
> after s to do "step a thread and resume all others".
>
> But this doesn't matter. Obviously vCont is better and more handy.
Not in all-stop mode. GDB can not send an
On 10/06, Pedro Alves wrote:
>
> On Wednesday 06 October 2010 18:19:53, Oleg Nesterov wrote:
> >
> > Cough. Previously I was told here (on arc...@sourceware.org) that
> > Hc + s/c is enough and I shouldn't worry about vCont;s/c ;)
>
> vCont was introduced because with only 'Hc', 's' and 'c', there'
On Wednesday 06 October 2010 18:19:53, Oleg Nesterov wrote:
> On 10/05, Pedro Alves wrote:
> > "The stub must support @samp{vCont} if it reports support for
> > multiprocess extensions (@pxref{multiprocess extensions})."
>
> Cough. Previously I was told here (on arc...@sourceware.org) that
> Hc +
On 10/05, Pedro Alves wrote:
>
(reordered)
> On Tuesday 05 October 2010 18:27:29, Oleg Nesterov wrote:
>
> > So, I strongly believe gdb is buggy and should be fixed.
>
> Fix your stub to implement vCont;s/c(/S/C).
First of all, I confirm that when I added the (incomplete right
now) support for v
On Tuesday 05 October 2010 19:30:38, Pedro Alves wrote:
> Now, given this, I won't be surprised if you're seeing races
> with ->s, <-OK, ->vCont sequences, as GDB may well be thinking
> that the "OK" is a reply to the vCont.
>
I meant ->s, <-OK, ->vStopped sequences.
--
Pedro Alves
On Tuesday 05 October 2010 18:27:29, Oleg Nesterov wrote:
> The more or less "typical" transcript is:
>
> [... snip ...]
> => s
This is already wrong.
"The stub must support @samp{vCont} if it reports support for
multiprocess extensions (@pxref{multiprocess extensions})."
The stub
On 10/04, Oleg Nesterov wrote:
>
> While trying to understand what does this mean, I hit another bug
> in ugdb.
No, /usr/bin/gdb is buggy.
> A multithreaded tracee can "hang" if gdb simulates
> watchpoints with single-steps + mem-fetch/compare.
It doesn't, but gdb "forgets" about the pending "St
