This is the mail archive of the email@example.com
mailing list for the Cygwin project. See the Cygwin
home page for more information.
Re: gdb "attach" and sharing thread info between processes
- To: Egor Duda <firstname.lastname@example.org>
- Subject: Re: gdb "attach" and sharing thread info between processes
- From: Chris Faylor <email@example.com>
- Date: Thu, 29 Apr 1999 13:01:22 -0400
- Cc: firstname.lastname@example.org
- References: <email@example.com>
The recently announced gdb 4.18 should have the ability to attach to
a running process and manipulate threads.
You can get the sources from
On Thu, Apr 29, 1999 at 08:36:49PM +0400, Egor Duda wrote:
> I've tried to use gdb "attach" feature to debug cygwin program and
>got INVALID_HANDLE_ERROR in gdb/win32_nat.c. As far, as i see, that's
>due to incorrect value of current_process and current_thread
>variables. They're initialized correctly when gdb starts a debugee
>as a child (through CreateProcess call). But when we're "attach"ing to
>some other process, those variables have wrong values :(
> As for `current_process', this could be easily fixed, by calling
>`OpenProcess' when attaching to debugee. I've patched win32-nat.c and
>managed to watch vars from debugee (before patching,
>ReadProcessMemory() fails with INVALID_HANDLE_ERROR.)
> But threads are different matter... :( MS promise to implement
>OpenThread syscall in Win2000 only, and they say, that the only way to
>get thread handle is to ask a parent process to reveal it. As a
>solution, i would propose to move threads array (threads var declared
>in winsup/debug.cc) from per-process to shared area and implement a
>call to cygwin dll to give away thread handle by processId and
>ThreadId by scanning this thread list.
> With this call gdb will be able to initialize current_thread variable
>properly when attaching to cygwin process.
>So, the question is -- is it a "right way"?