This is the mail archive of the gdb-patches@sources.redhat.com 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: [RFC] Suggested ways to remove the need for xm-go32.h


   Date: Sat, 18 Sep 2004 16:18:31 +0300
   From: "Eli Zaretskii" <eliz@gnu.org>

   I looked at what xm-go32.h does, and here are my suggestions for
   eliminating the need for it.  If these suggestions are okayed, I will
   post patches to do that, and then xm-go32.h could be removed (as well
   as, I hope, xm-cygwin.h, so Chris, please see if these suggestions are
   okay for Cygwin).

   Currently, xm-go32.h does this:

     . #include's fopen-bin.h
     . #define's GDBINIT_FILENAME to "gdb.ini"
     . #define's CRLF_SOURCE_FILES
     . #define's DIRNAME_SEPARATOR to ';'

   Here's how I propose to deal with each one of these:

   1.  fopen-bin.h: I suggest to modify the default definitions of the
       FOPEN_* macros on defs.h to the ANSI/ISO-compatible "rb", "wb",
       etc. strings that include the "b" modifier.  Since we already
       require ISO C compliance from all the ports, such a default must
       DTRT.  Once the defaults are changed, there should be no need to
       use fopen-bin.h neither in the DJGPP nor in the Cygwin port.

Thus far, we've required a ISO C compliant *compiler*, but not
strictly ISO C compliant *libraries*.  The reasoning behind this is
that it's easy to replace the compiler (with gcc), but not so easy to
replace the system libraries.  I'm not really sure that all supported
systems support the "b" modifier.  So I don't think we can do this.

I think it'd be better to have wrapper functions that try to open the
file using the "b" modifier, and if that fails, retry without.  It's a
bit more work, but it should be more robust.

   2.  GDBINIT_FILENAME: This one is currently used by top.c and
       cli-cmds.c.  The latter uses the definition in a doc string for
       the `source' command, while the former uses GDBINIT_FILENAME for
       the value of the global var gdbinit[] which is then referenced in
       main.c.

       My suggestion is to move the definition of GDBINIT_FILENAME to
       defs.h, conditioned by a suitable DJGPP-specific #ifdef.

       Alternatively, we could make the definition of GDBINIT_FILENAME
       local to top.c, and modify cli-cmds.c to use the global variable
       gdbinit[] instead of the macro.

Why not have a list of files to try?  That would mean we'd always try
"gdb.ini" if ".gdbinit" fails, even on Unix.

   3.  CRLF_SOURCE_FILES: Here I suggest to make GDB understand CR-LF
       style files on all supported systems.  Surely with today's
       proliferation of networked drives and compilers that support CR-LF
       files even on Unix, one can never know whether the source file
       comes from a drive exported by some Windows server or one that was
       edited by some Windows editor that added CR characters to each
       line.  In addition to compilers, other programs support CR-LF
       files on Posix systems; examples include Emacs and Texinfo's Info
       reader.

       If this suggestion is accepted, I suggest to make the code that is
       currently conditioned by #ifdef CRLF_SOURCE_FILES be the only code
       path in the files that use it (event-top.c, source.c, and top.c)
       and remove the conditional itself.

Sounds like a good idea to me.

   4.  DIRNAME_SEPARATOR: The DOS-specific definition can be put either
       in defs.h or local to the only file that uses it (source.c).

We should probably include "filenames.h" and base the definition on
HAVE_DOS_BASED_FILE_SYSTEM.  I'm somewhat in favor of doing that only
locally in source.c.

Mark


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