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: Behaviour of default all-stop mode -- Why no one has replied ?


Fine. vCont is properly implemented and most of the things are working fine.
I've a query with single step.
Let's say there are four threads, 1,2,3,4.
Sometimes when I single step, I get a packet from gdb as "vCont;s:1;c".
Accordingly, I insert a break at the next address, and continue all.

1)

(i) Now, even before thread 1 hits the break at the next address, the other thread(s) may hit some other breakpoint and report that. In this case, the single step is not yet 
reached (and therefore not removed). A further continue will make all run, and then thread 1 may hit this single step break, remove it and report it to gdb. What this all means
 is, gdb may get the single step status after quite some time and not immediately after one does "step". Is this OK ?

(ii) There is also another possibility. Some other thread may hit this single step breakpoint, remove the breakpoint and report it than the actual thread 1, which is supposed 
to hit, remove it and report it. If this happens, then the actuaI thread 1 which is supposed to single step will not be single stepped. Is this way of implementation OK ?

2) Another way is, even if other threads hit some other breakpoint or hit this single step breakpoint itself, they do not report it and wait for thread 1 to hit the single step
 and report it. Is this the way to be implemented ?

Expecting your reply.

Thanks,
Suresh


----- Original Message -----
From: "Pedro Alves" 
To: "suresh ds" 
Cc: gdb@sourceware.org
Subject: Re: Behaviour of default all-stop mode -- Why no one has replied ?
Date: Mon, 6 Jul 2009 18:04:19 +0100


On Monday 06 July 2009 15:21:04, suresh ds wrote:
> After some trial and error, I observed that "vCont;c" indicates 
> that 'c'ontinue should be applied to all the threads that do not 
> have any default action specified. Actually, gdb documentation 
> could have been clearer; I read it a few times, tried out a few 
> times, only then understood the vCont behaviour. I saw your mail 
> later with your explanation of vCont which confirms my 
> understanding is correct. Well, anyway, vCont is implemented and 
> things are working fine. But I have a new issue here, given below:
>


> 1) Does gdb support threads with shared text ?

Yes.

> It is common to see different threads calling the same function 
> in which case the function becomes shared code for those threads. 
> Any specific option has to be turned on (in gdb)?

No.

>
> 2) I've mapped gdb threads to hardware threads in a 
> multi-processor MIPS SoC and these hardware threads share the 
> text. Theoritically, this is same as a function shared by 
> different software threads. I've pasted the log below:

>
> (gdb)target remote :
> Remote debugging using :
> Sending packet: $qSupported#37...Ack
> Packet received: Packet qSupported (supported-packets) is NOT supported
> Sending packet: $g#67...Ack
> Packet received: 
> 0000000000000000000000005000000100000000000000a000000000000000100000000000000001000000000087000000000000000000b0ffffffff900ddeed00000000018066ac00000000018066f8ffffffff800b40000000000001806868000000000180676800000000000000010000000000871704000000000087172400000000018068780000000000800000ffffffff800b40400000000000000004000000000080000000000000002d000000000000009538780000000000800000ffffffff800b4000000000000000000100000000000000000000000000000000000000000080ac5000000000008f2e800000000000000001000000000023a9fc000000005000000300000000015be680000000000124f80000000000008000000000000000008024000000000023757800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> Sending packet: $?#3f...Ack
> Packet received: T00thread:4;
> Sending packet: $Hc-1#09...Ack
> Packet received: OK
> Sending packet: $qC#b4...Ack
> Packet received: QC 4
> Sending packet: $qOffsets#4b...Ack
> Packet received: Text=0;Data=0;Bss=0
> [New Thread 4]
> Sending packet: $g#67...Ack
> Packet received: 
> 0000000000000000000000005000000100000000000000a000000000000000100000000000000001000000000087000000000000000000b0ffffffff900ddeed00000000018066ac00000000018066f8ffffffff800b40000000000001806868000000000180676800000000000000010000000000871704000000000087172400000000018068780000000000800000ffffffff800b40400000000000000004000000000080000000000000002d000000000000009538780000000000800000ffffffff800b4000000000000000000100000000000000000000000000000000000000000080ac5000000000008f2e800000000000000001000000000023a9fc000000005000000300000000015be680000000000124f80000000000008000000000000000008024000000000023757800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> 0x00237578 in gdb_break ()
>     at blah..blah..
> 85      blah..blah..
>         in blah..blah..
> Sending packet: $qSymbol::#5b...Ack
> Packet received: Packet qSymbol (symbol-lookup) is NOT supported
> (gdb)b fun
> Breakpoint 1 at 0x200388: file debug_test.c, line 46.
> (gdb)c
> Continuing.
> Sending packet: $Z0,200388,4#4b...Ack
> Packet received: OK
> Packet Z0 (software-breakpoint) is supported
> Sending packet: $vCont?#49...Ack
> Packet received: vCont;c;C;s;S;t;T
> Packet vCont (verbose-resume) is supported
> Sending packet: $vCont;c#a8...Ack
> Packet received: T05thread:7;
> [New Thread 7]
> Sending packet: $g#67...Ack
> Packet received: 
> 000000000000000000000000500000010000000000802c54ffffffffffffffff000000000000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000000000000001ffffffff800b4000000000000180686800000000018067680000000000000001000000000087170700000000008717270000000000000620ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f80000810d688c26ce100000000000008024000000000020038800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> Sending packet: $g#67...Ack
> Packet received: 
> 000000000000000000000000500000010000000000802c54ffffffffffffffff000000000000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000000000000001ffffffff800b4000000000000180686800000000018067680000000000000001000000000087170700000000008717270000000000000620ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f80000810d688c26ce100000000000008024000000000020038800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> [Switching to Thread 7]
> Sending packet: $z0,200388,4#6b...Ack
> Packet received: OK
>
> Breakpoint 1, fun () at debug_test.c:46
> 46      debug_test.c: No such file or directory.
>         in debug_test.c
> (gdb)c
> Continuing.
> Sending packet: $vCont;s:7#29...Ack
> Packet received: T05thread:7;
> Sending packet: $g#67...Ack
> Packet received: 
> 000000000000000000000000500000010000000000000002ffffffffffffffff000000000000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000000000000001ffffffff800b4000000000000180686800000000018067680000000000000001000000000087170700000000008717270000000000000620ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f80000810d688c26ce100000000000008024000000000020038c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> Sending packet: $Z0,200388,4#4b...Ack
> Packet received: OK
> Sending packet: $vCont;c#a8...Ack
> Packet received: T05thread:7;
> Sending packet: $g#67...Ack
> Packet received: 
> 000000000000000000000000500000000000000050000001000000000000000b000000000000000b0000000000800398000000000000000a000000000000000100000000008000000000000000000001ffffffffbef1400000000000008f26b400000000008e07600000000000800000ffffffffffffffff00000000000000010000000000800000ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8000000000000000700000000000000010000000b00000000002cedf000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f800ffffffff8c145b880000000000008024000000000020038800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> Sending packet: $z0,200388,4#6b...Ack
> Packet received: OK
>
> Breakpoint 1, fun () at debug_test.c:46
> 46      in debug_test.c
> (gdb)info b
> Num     Type           Disp Enb Address    What
> 1       breakpoint     keep y   0x00200388 in fun at debug_test.c:46
>         breakpoint already hit 2 times
>
> <=======================================================================>
>
> I want to point out a few things. Here, four threads are running, 
> 4,5,6,7. Thread 7 hits the breakpoint and stops other threads 
> too; gdb also acknowledges this by typing "[Switching to Thread 
> 7]". A further continue gives rise to the foll. sequence (and my 
> comments are intersperced):
>
> (rmios-gdb)c
> Continuing.
> Sending packet: $vCont;s:7#29...Ack
> Packet received: T05thread:7;
>
> <==> At this point, gdb makes Thread 7 to step while indicating 
> nothing for the other threads
>
> Sending packet: $g#67...Ack
> Packet received: blah...blah..
> Sending packet: $Z0,200388,4#4b...Ack
> Packet received: OK
>
> <==> Once Thread 7 single steps, it inserts the breakpoint; Note 
> that other threads have not yet moved, but the breakpoint is 
> already inserted back !!
>
> Sending packet: $vCont;c#a8...Ack
> Packet received: T05thread:7;
>
> <==> Now, gdb makes all threads to continue. But this only makes 
> Thread 7 to continue and other threads are still at the same 
> point, because they came out of exception, and tried to execute 
> the same PC which has the address with breakpoint already 
> inserted back, so they hit the break again without really 
> proceeding.

So now would be a good time to report one of those threads has 
having hit the breakpoint.  Remember that events are serialized to 
GDB.

> Since Thread 7 has already single-stepped, it does not see this 
> break (which it itself inserted), proceeds further, later hits 
> this break again (as the code is in a loop).

This depends on your stub and OS scheduler.  If another thread had 
hit the same breakpoint, then by all means, report that instead.

>
> Ideally, the sequence should have been something like this:
> Sending packet: $vCont;s#29...Ack
> Packet received: blah...blah...
> Sending packet: $Z0,200388,4#4b...Ack
> Packet received: OK
> Sending packet: $g#67...Ack
> Packet received: blah...blah..
> Sending packet: $vCont;c#a8...Ack
> Packet received: T05thread:7;
>
> This will ensure that all threads have single-stepped once, then 
> the break can be inserted and the threads can be proceeded.

Not.  Remember that events are serialized to GDB.  From GDB's and 
the users perspective, the other
threads still haven't reported the breakpoint hit.

>
> Is this a bug in gdb ?

No.

> Is this the default behaviour of gdb, and it is left to the stub 
> to find some workaround for this ??

Yes, and no, but not really a workaround.

> Is there any option which can make this happen cleanly ?

No.  Depends on what you call cleanly though.

> If this is how gdb behaves, then other threads won't proceed at 
> all and just keep hitting the break again and again.

Have the stub report that to GDB.  Eventually the user types enough 
"continue"s to
move all threads passed the breakpoint.  If the user is only 
interested in being
reported of a breakpoint hits in a specific thread, she can set a 
"thread specific breakpoint"
instead.  "break foofunc thread 4", for example.

> Note that the above problem occurs because the threads share the 
> code (text). If they indeed are running different texts, then 
> this problem would not arise at all, which makes me think, does 
> gdb support threads with shared text, in the first place ?

Threads that do not share text is what would be modelled with
multiple process/address-space support, which GDB is only now beginning
to understand.  GDB has been assuming threads share text ever since
multithreading support was added to GDB.

> Please reply.

Ok.

--
Pedro Alves


-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com


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