Mail Archives: cygwin/1999/08/27/02:00:26
> -----Original Message-----
> From: Mumit Khan [SMTP:khan AT xraylith DOT wisc DOT EDU]
> Sent: Friday, August 27, 1999 14:41
> To: Andrew Dalgleish
> Cc: 'cygwin AT sourceware DOT cygnus DOT com'
> Subject: Re: debugging across fork
>
> Andrew Dalgleish <andrewd AT axonet DOT com DOT au> writes:
> >
> >
> > >
> > > btw, I finally ran the cygwin build and noticed that the balloon
> > > popups don't work when I position the pointer on say a variable.
> > > If it happens to others as well, it's probably a bug and needs
> > > to be reported. Works fine on Unix boxes I've tried.
> > [Andrew Dalgleish]
> > I had noticed that.
> > If you hover over a function name the popup does show the function
> > address.
>
> Ah, it's the old bug where the files are not on C: drive. If the
> source files are on C:, then everything works (functions and vars),
> otherwise nothing. Essentially gdb_loc chokes if files are named
> say //g/foo.c or g:\\foo.c (the actual error is "No source file
> named `xxx' in decode_line_1 deep within the guts).
[Andrew Dalgleish]
My root mount is U:/ (a subst drive), so you are probably correct.
I am now able to commence debugging this problem.
It just took me a while to realize I had to look up the child's
*windows* pid to attach.
For the benefit of those searching the archive, to use gdb attach you
need to run 'ps -l'.
I was hoping to do this, but my main bash window exits after starting
foo.
gdb foo &
(step until after fork)
ps -l
(look up child's windows pid)
gdb foo.exe 123
What did work for me (using Insight) was this:
./foo &
(after foo forks, the parent prints the child id, and the child does a
sleep(60))
ps -l
(look up child's windows pid)
gdb foo.exe 123
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -