This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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: [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é?: Wednesday, May 27, 2009 9:25 PM
> À?: Pierre Muller (IMAP)
> Cc?: gdb-patches@sourceware.org
> Objet?: Re: [RFA] Fix troubles with watchpoints in DJGPP
> 
> > From: "Pierre Muller \(IMAP\)" <muller@ics.u-strasbg.fr>
> > Date: Wed, 27 May 2009 09:48:49 +0200
> >
> >
> >   I also tried to use it but I have several problems,
> > some are probably DJGPP specific
> > (bad file descriptor errors when trying to restart
> > a ./gdb executable at level 2, meaning inside another gdb
> > itself being debugged by gdb).
> 
> Please give me some simple test program and a transcript of a GDB
> session that reproduces this problem.  I debug GDB with itself a lot,
> and I never saw this.

  Compile gdb on current CVS head.

in build/gdb

bash-2.05b$ ./gdb ./gdb
GNU gdb (GDB) 6.8.50.20090524-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i586-pc-msdosdjgpp --target=djgpp".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) watch gdb_tderr
No symbol "gdb_tderr" in current context.
(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

With patch go32-nat.c file:

bash-2.05b$ ./gdb ./gdb
GNU gdb (GDB) 6.8.50.20090524-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i586-pc-msdosdjgpp --target=djgpp".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) watch gdb_stderr
Watchpoint 1: gdb_stderr
(gdb) r
Starting program: e:/cygwin/usr/local/src/gdbcvs/djbuild/gdb/./gdb.exe
Hardware watchpoint 1: gdb_stderr

Old value = (struct ui_file *) 0x0
New value = (struct ui_file *) 0x3aa7dc
captured_main (data=0x3a92d0) at ../../purecvs/gdb/main.c:322
322       gdb_stdlog = gdb_stderr;      /* for moment */
(gdb) inf watch
Num     Type           Disp Enb Address    What
1       hw watchpoint  keep y              gdb_stderr
        breakpoint already hit 1 time
(gdb)q

With the patch, the 'watchpoint' 
is successfully promoted into a 'hardware watchpoint'
thanks to this 
breakpoint_re_set call.

> Also, on what platform (OS and version) is that?
> 
> >   After some debugging, I realized that
> > DJGPP only calls insert_breakpoints ()
> > that does call update_watchpoint with reparse set to one,
> > after pushing go32 target,
> > while with cygwin, the DLL loaded caused a
> > reloading of all breakpoints and triggered a
> > call to update_watchpoint with reparse = 1.
> >
> >
> > This one line patch fixes the problem.
> >
> > Is this patch OK?
> 
> Thanks, but here, too, I would like a simple test program and a
> transcript of a GDB session before and after the patch.

I hope the above is enough for you.
 
> > 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 :(

Pierre


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