This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin 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: 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


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