This is the mail archive of the gdb-patches@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: [RFC] 10/10 non-stop for linux native


A Friday 09 May 2008 20:26:58, Michael Snyder wrote:

> We are extending the envelope here.  Ptrace was not designed
> with non-stop or asynch debugging in mind.

I'm not relying on some unspecified ptrace behaviour
against running lwps that happens to be convenient.

With ptrace, we can inspect and modify inferior processes
while they are stopped, only.  It they are running, we can't
read registers or memory from them.

I'm simply ensuring never to use ptrace against a running
lwp, ever.

The only two "issues" with ptrace here, but those only arose,
because we assumed all lwps were always stopped.

We were always talking to thread-db through the the main lwp of the
thread group (proc-service.c/linux-thread-db.c:proc_handle.pid).
In all-stop that is ok, as all lwps are stopped at that point.  In
non-stop, when some other lwp other then the main lwp gets an
event (a breakpoint, say), since we don't stop all threads,
proc-service would fail -- the main lwp could be running.  But,
we know the event lwp is stopped at that point, so we should have 
proc_services use the event pid -- because we can use ptrace on it.

The other issue is that linux_nat_thread_alive assumed the passed in
ptid is stopped when it is called, because that is always true in all-stop
mode.  Since that is not true in non-stop, I switched the linux
implementation to check if the lwp is alive by "sending" signal 0
instead of relying on ptrace(PEEK_USER).

-- 
Pedro Alves


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