This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [RFA] Fix troubles with watchpoints in DJGPP
> -----Message d'origine-----
> De?: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Eli Zaretskii
> Envoyé?: Thursday, May 28, 2009 10:21 AM
> À?: Pierre Muller
> Cc?: gdb-patches@sourceware.org
> Objet?: Re: [RFA] Fix troubles with watchpoints in DJGPP
>
> > From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> > Cc: <gdb-patches@sourceware.org>
> > Date: Wed, 27 May 2009 22:53:31 +0200
> >
> > (gdb) watch gdb_stderr
> > Watchpoint 1: gdb_stderr
> > (gdb) r
> > Starting program:
> e:/cygwin/usr/local/src/gdbcvs/djbuild/gdb/./gdb.exe
> > Watchpoint 1: gdb_stderr
> >
> > Old value = <unreadable>
> > New value = (struct ui_file *) 0x0
> > 0x00001a91 in start ()
> > (gdb) inf watch
> > Num Type Disp Enb Address What
> > 1 watchpoint keep y gdb_stderr
> > breakpoint already hit 1 time
> > (gdb) q
>
> Thanks, but this example is for the second (and the main) problem you
> mention in your original message, the one with watchpoints. You also
> reported another problem:
>
> > > > (bad file descriptor errors when trying to restart
> > > > a ./gdb executable at level 2, meaning inside another gdb
> > > > itself being debugged by gdb).
>
> Can you show an example of these ``bad file descriptor errors''? I
> don't think I ever saw them.
This one is more tricky, I only saw it with 3 levels of gdb.
And maybe watchpoints were needed too...
I will try to find a reproducible way, but it might not be so easy.
> Thanks.
>
> > > > PS-2) Eli,
> > > > do you have anything that could help me debug the
> > > > Bad file descriptor problems, like a library recording
> > > > file opening/closing using the DJGPP file system extensions?
> > >
> > > No, but you can put a breakpoint on the respective library
> functions,
> > > couldn't you?
> >
> > I discovered that there is already something in
> > dbgcom.c, but I wanted to have dup and dup2 calls
> > be monitored also, as the problem seems related to
> > handles of that type... But dup and dup2
> > never generate a call to the FSEXT function,
> > which make it not useful for that :(
>
> First, I meant to actually put a breakpoint on each of the functions
> you are interested in; that doesn't need any FSEXT hooks. And second,
> I don't understand the nature of your problems with FSEXT: dup and
> dup2 do make a copy of the FSEXT hook of the original file descriptor,
> so if the original descriptor was hooked by an FSEXT, the duplicated
> descriptor will be hooked as well. What am I missing?
What I am missing is a FSEXT hook call inside dup
so that I know that the return value of dup is used,
instead with current gdbcom.c code, I will only get a
call to dbg_fsext when this handle is closed, but
at that point, I would have no idea where this handle is coming from!
Pierre