This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
regarding thread switching capability
- From: "Praveen Srinivasan" <spraveen at ittc dot ku dot edu>
- To: gdb at sources dot redhat dot com
- Cc: rrk at ku dot edu
- Date: Mon, 9 Aug 2004 15:32:01 -0500 (CDT)
- Subject: regarding thread switching capability
Hello,
We are working on enhancing gdb for replaying "recorded" executions of
NPTL based applications. We need the ability to force context switches to
a desired thread as a part of the replay design.
I was going through the gdb-6.0post-0.20040223.19 source (one that comes
with Redhat FC2) and noticed the following in target.h
enum thread_control_capabilities
{
tc_none = 0, /* Default: can't control thread
execution. */
tc_schedlock = 1, /* Can lock the thread scheduler. */
tc_switch = 2 /* Can switch the running thread on
demand. */
};
The lin-lwp init module has the following line..
lin_lwp_ops.to_has_thread_control = tc_schedlock;
which says the linux thread interface will only be able to lock the
scheduler and not switch the running thread on demand.
When I was almost sure that this is the functionality that we need to
provide, I got confused about the thread command that says it can switch
threads. I am assuming that once I hit a breakpoint and switch thread
using the "thread <threadno>" command, it still does ptrace(RESUME_ALL..)
which doesnt force the kernel scheduler to switch to the thread number.
My questions are
1. Does the "thread <threadno>" command force the kernel scheduler to
switch context? (I tried some debugging sessions and this does seem to
happen)
2. In case it doesnt, is there any thread library that is already capable
of switching threads on demand (I mean to_has_thread_control = tc_switch)
so that context switches can be forced.
I request you all to throw some light on this issue.
Thanks in advance
With Best Regards
Praveen