RE: ptrace implementation

["Chris January" <chris at atomice dot net>]

Apologies for the re-post. I didn't realise my first one had got through.

> -----Original Message-----
> From: cygwin-developers-owner@cygwin.com
> [mailto:cygwin-developers-owner@cygwin.com]On Behalf Of Chris January
> Sent: 06 January 2004 14:15
> To: cygwin-developers@cygwin.com
> Subject: RE: ptrace implementation
>
>
> > On Wed, Nov 26, 2003 at 09:47:47AM -0000, Chris January wrote:
> > >I've been thinking for a while of writing a ptrace implementation for
> > >Cygwin. Given I don't have much time it might take a while. I
> > was wondering
> > >if anyone had any comments or ideas before I started?
> >
> > I have been thinking about doing the same thing for some time but I've
> > never done much investigation beyond some half-hearted poking at stuff
> > enough to think that it is doable.
>
> I started working on this and had a problem to solve. Linux uses
> light-weight processes to implement threads so you pass ptrace the pid of
> the thread you want to act upon when you use it. Windows has a different
> concept of threads where threads are contained within a single process.
> To cope with the different paradigm I can either:
> i) get rid of all ptrace operations that modify the process/thread context
> (this is what Solaris does)
> ii) extend ptrace to have a thread_id argument
> Having chosen option ii) I ran into another problem - how can a
> process find
> out the thread ids of another process?
> So I implemented a ptrace operation that lists the threads in the other
> process. Ideally this would return pthread_t's but ptrace_t's only make
> sense within a particular process. To resolve a pthread_t passed to ptrace
> in another process would require first sending it to the process being
> debugging using the commute mechanism and then waiting for the acutal
> Windows thread id to come back. I considered this overhead to be
> too high so
> I at the moment I am simply returning a list of Windows thread ids (as
> opposed to a list of ptrace_t's). Either way my solution breaks
> some of the
> nice encapsulation of the thread list in threads.cc (since I have
> to flatten
> the linked list and look up the Windows thread id of each pthread in the
> list).
> Did that make sense!?
> So, maybe there is a better way to do this? Has anyone any comments or
> suggestions?
> Finally since ptrace is a very OS-specific call what do people
> think about a
> ptrace_linux that would behave more like the Linux version of ptrace
> (emulating the Linux struct user, etc. instead of using Windows'
> CONTEXT as
> I am doing at present). This would make porting Linux programs
> that rely on
> ptrace a lot easier.
>
> Chris
>
>