* Potential problem between non-stop and linux-thread-db
@ 2009-10-06 0:46 Michael Snyder
2009-10-06 0:49 ` Pedro Alves
0 siblings, 1 reply; 4+ messages in thread
From: Michael Snyder @ 2009-10-06 0:46 UTC (permalink / raw)
To: gdb
Just something I noticed just now...
linux-thread-db depends on callback functions provided by
gdb_proc_service.c. Some of those callbacks are for instance
/* Stop the lightweight process LWPID within the target process PH. */
ps_err_e
ps_lstop (gdb_ps_prochandle_t ph, lwpid_t lwpid)
{
/* All lightweight processes are stopped when under control of GDB. */
return PS_OK;
}
/* Resume the lightweight process (LWP) LWPID within the target
process PH. */
ps_err_e
ps_lcontinue (gdb_ps_prochandle_t ph, lwpid_t lwpid)
{
/* Pretend we did successfully continue LWPID. GDB will take care
of it later on. */
return PS_OK;
}
These were written under the "all-stop" convention, but the comments
are no longer true, is it not so?
So, async/nonstop guys -- do we need to do anything about this?
Michael
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Potential problem between non-stop and linux-thread-db
2009-10-06 0:46 Potential problem between non-stop and linux-thread-db Michael Snyder
@ 2009-10-06 0:49 ` Pedro Alves
2009-10-06 17:34 ` Michael Snyder
0 siblings, 1 reply; 4+ messages in thread
From: Pedro Alves @ 2009-10-06 0:49 UTC (permalink / raw)
To: gdb; +Cc: Michael Snyder
On Tuesday 06 October 2009 01:42:24, Michael Snyder wrote:
> These were written under the "all-stop" convention, but the comments
> are no longer true, is it not so?
>
> So, async/nonstop guys -- do we need to do anything about this?
AFAIK, these callbacks weren't really used by glibc. Has that
changed recently?
--
Pedro Alves
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Potential problem between non-stop and linux-thread-db
2009-10-06 0:49 ` Pedro Alves
@ 2009-10-06 17:34 ` Michael Snyder
2009-10-06 17:44 ` Pedro Alves
0 siblings, 1 reply; 4+ messages in thread
From: Michael Snyder @ 2009-10-06 17:34 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb
Pedro Alves wrote:
> On Tuesday 06 October 2009 01:42:24, Michael Snyder wrote:
>
>> These were written under the "all-stop" convention, but the comments
>> are no longer true, is it not so?
>>
>> So, async/nonstop guys -- do we need to do anything about this?
>
> AFAIK, these callbacks weren't really used by glibc. Has that
> changed recently?
Probably not. I was just looking at the code, not actually
running or debugging it.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Potential problem between non-stop and linux-thread-db
2009-10-06 17:34 ` Michael Snyder
@ 2009-10-06 17:44 ` Pedro Alves
0 siblings, 0 replies; 4+ messages in thread
From: Pedro Alves @ 2009-10-06 17:44 UTC (permalink / raw)
To: Michael Snyder; +Cc: gdb
On Tuesday 06 October 2009 18:30:58, Michael Snyder wrote:
> Pedro Alves wrote:
> > On Tuesday 06 October 2009 01:42:24, Michael Snyder wrote:
> >
> > AFAIK, these callbacks weren't really used by glibc. Has that
> > changed recently?
>
> Probably not. I was just looking at the code, not actually
> running or debugging it.
Feel free to put a comment there, or let me know if you'd
like me to. In any case, in non-stop mode, at least the current
lwp is always stopped already when we call into thread_db.
It's likely that solaris' thread_db does make use of such
callbacks. I didn't check, but well, they've invented the
interface. We never did merge sol-threads.c and proc-service.c
though, and solaris doesn't support non-stop presently anyway.
--
Pedro Alves
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-10-06 17:44 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-06 0:46 Potential problem between non-stop and linux-thread-db Michael Snyder
2009-10-06 0:49 ` Pedro Alves
2009-10-06 17:34 ` Michael Snyder
2009-10-06 17:44 ` Pedro Alves
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox