RE: [RFA] Fix troubles with watchpoints in DJGPP

["Pierre Muller" <muller@ics.u-strasbg.fr>]

> -----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