[RFC] Suggested ways to remove the need for xm-go32.h

[RFC] Suggested ways to remove the need for xm-go32.h

[Eli Zaretskii]

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.

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.

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.

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

Comments and discussion are welcome.

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Mark Kettenis]

   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

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Eli Zaretskii]

> Date: Sun, 19 Sep 2004 13:44:28 +0200 (CEST)
> From: Mark Kettenis <kettenis@gnu.org>
> CC: gdb-patches@sources.redhat.com
> 
> 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 think it's a really rare case that a system has an ISO compiler, but
a non-ISO library (last time I saw such a system was back in 1994: it
was a SunOS 4.3 box where I installed GCC).  Nowadays an ISO compiler
goes with an ISO library, and "rb" and friends were mandated by C89,
not the latest C9x.

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

If people prefer this, I don't mind.

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

I have no problems with that, I just thought that Unix users will not
want "gdb.ini".

>    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 don't think this will be good, since Cygwin uses
HAVE_DOS_BASED_FILE_SYSTEM, and its DIRNAME_SEPARATOR is ':'.  More
generally, HAVE_DOS_BASED_FILE_SYSTEM is somewhat orthogonal to the
DIRNAME_SEPARATOR issue.

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Michael Chastain]

"Eli Zaretskii" <eliz@gnu.org> wrote:
> I think it's a really rare case that a system has an ISO compiler, but
> a non-ISO library (last time I saw such a system was back in 1994: it
> was a SunOS 4.3 box where I installed GCC).  Nowadays an ISO compiler
> goes with an ISO library, and "rb" and friends were mandated by C89,
> not the latest C9x.

"rb" and "wb" are mentioned in "man fopen" on these systems:

  alphaev56-dec-osf4.0g
  alphaev68-dec-osf5.1b
  hppa2.0w-hp-hpux11.00
  hppa2.0w-hp-hpux11.11

I'm cool with the wrapper-function idea.

Michael

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Eli Zaretskii]

> Date: Wed, 22 Sep 2004 16:21:24 -0400
> From: Michael Chastain <mec.gnu@mindspring.com>
> Cc: gdb-patches@sources.redhat.com
> 
> "rb" and "wb" are mentioned in "man fopen" on these systems:
> 
>   alphaev56-dec-osf4.0g
>   alphaev68-dec-osf5.1b
>   hppa2.0w-hp-hpux11.00
>   hppa2.0w-hp-hpux11.11

Did you find any systems where "rb" and "wb" are _not_ mentioned?

> I'm cool with the wrapper-function idea.

Thanks for the feedback.

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Michael Chastain]

"Eli Zaretskii" <eliz@gnu.org> wrote:
> Did you find any systems where "rb" and "wb" are _not_ mentioned?

No, I didn't.

Michael

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Corinna Vinschen]

On Sep 19 13:44, Mark Kettenis wrote:
>        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.

That's a good idea, IMHO.  I never really liked the situation that an
application uses different names for config files on different systems.
Using a list of filenames makes all systems equal again :-)

>    3.  CRLF_SOURCE_FILES: Here I suggest to make GDB understand CR-LF
>        style files on all supported systems.  [...]
> 
> Sounds like a good idea to me.

ACK.

Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Christopher Faylor]

On Sat, Sep 18, 2004 at 04:18:31PM +0300, Eli Zaretskii wrote:
>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.

I'd be happy to see this but I see that later in the thread that we
seem to be converging on a wrapper function.

I have a vague dislike for using wrapper functions if you can get away
without using them.  It's one less thing in a backtrace.

Is a wrapper function more better than just doing:

#ifdef USEB
#define READ "rb"
#else
#define READ "r"
#endif

  fopen ("foo", READ)

Or is that an unacceptable use of a macro?  It's similar to how we
handle the similar use of O_BINARY now.  Out of curiousity is O_BINARY
mandated by ISO C?  I suspect not.

MichaelC has indicated which systems support "rb".  Is there any way to
somehow figure out if this is supported for the whole list of supported
targets?  Or can we try going without the wrapper function and move
to a wrapper function when someone complains?

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

I wouldn't mind just maintaining a list of filenames that gdb uses, as
Mark suggests.

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

I think understanding files with CRLF is a good idea.  Doesn't gcc do
this now?

*pause*

Yep.  It does.  We might as well be consistent.

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

This could be determined at configure time couldn't it?  You could
play with the path to see if a colon or semicolon does the desired
thing and then set it appropriately via config.in.

cgf

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Michael Chastain]

Christopher Faylor <me@cgf.cx> wrote:
> MichaelC has indicated which systems support "rb".  Is there any way to
> somehow figure out if this is supported for the whole list of supported
> targets?

That brings up a tough philosophical issue.  Well, okay, part of it
is tough because it implies more work for me.

There isn't a list of supported hosts or supported targets.

The software itself has "list of hosts and targets that somebody, at
some time in the past, contributed at least some work towards."

The gdb-testers@ group records "somebody tested something and reported
results in some way".  That's where the "more work for me" comes in:
devising some standard meta-information for a test run (like a little
XML file, that's what I use in my test bed), and then augmenting the
test suite to generate gdb-test-run.xml on every run, and then having
people mail that in, and then begging more people to report their
results, and then writing "Terf II" to keep track of it all.

The release criteria for gdb is "break main ; run works on unspecified
platforms".

> Or can we try going without the wrapper function and move
> to a wrapper function when someone complains?

For the second question, from a support point of view, I want something
that (a) works on a lot of systems and (b) when it doesn't work on some
system, it's an obvious 1-line patch to work around the problem.  So I
don't like "no wrapper function but then change the code when someone
shows up with a weird system".

To avoid the wrapper function, perhaps probe for the modes at
run time:

  static const char * read_mode = NULL;

  void set_read_mode ()
  {
    FILE * fp = NULL;

    if (read_mode == NULL)
      {
	if ((fp = fopen ("/dev/null", "rb")) != NULL)
	  read_mode = "rb";
	else if ((fp = fopen ("/dev/null", "r")) != NULL)
	  read_mode = "r";
	else
	  some sort of error;
      }

    if (fp != NULL)
      {
	if (fclose(fp) != 0 )
	  error;
      }
  }

Personally I like wrappers for ease of porting.  It doesn't bug me to
see gdb_fopen + fopen on the call stack.

I don't think that "rb" versus "r" can be autoconf'ed.  The gdb
configure script would need to execute a host program to figure out
whether "rb" is supported or not, and that won't work if build != host.
Or maybe I'm wrong about that and there's some way to do it.

Michael

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Corinna Vinschen]

On Sep 23 02:30, Michael Chastain wrote:
> To avoid the wrapper function, perhaps probe for the modes at
> run time:
> 
>   static const char * read_mode = NULL;
> 
>   void set_read_mode ()
>   {
>     FILE * fp = NULL;
> 
>     if (read_mode == NULL)
>       {
> 	if ((fp = fopen ("/dev/null", "rb")) != NULL)
> 	  read_mode = "rb";
> 	else if ((fp = fopen ("/dev/null", "r")) != NULL)
> 	  read_mode = "r";
> 	else
> 	  some sort of error;
>       }
> 
>     if (fp != NULL)
>       {
> 	if (fclose(fp) != 0 )
> 	  error;
>       }
>   }

First I thought that's a good idea, but then again, it requires every
system to support /dev/null.  I'm not sure you'd find a filename which
all systems can agree to.

I guess a wrapper function would be the way to go here.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Eli Zaretskii]

> Date: Thu, 23 Sep 2004 10:03:12 +0200
> From: Corinna Vinschen <vinschen@redhat.com>
> 
> First I thought that's a good idea, but then again, it requires every
> system to support /dev/null.  I'm not sure you'd find a filename which
> all systems can agree to.

I agree; I think it will be downright impossible to find such a file
name.  Native configurations could all use /dev/null, but the remote
embedded targets are another story...

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Andrew Cagney]

>>Date: Thu, 23 Sep 2004 10:03:12 +0200
>>> From: Corinna Vinschen <vinschen@redhat.com>
>>> 
>>> First I thought that's a good idea, but then again, it requires every
>>> system to support /dev/null.  I'm not sure you'd find a filename which
>>> all systems can agree to.
> 
> 
> I agree; I think it will be downright impossible to find such a file
> name.  Native configurations could all use /dev/null, but the remote
> embedded targets are another story...

The question to ask is ``do all hosts on which GDB will run support 
this?''.  Since this stuff is host dependant, the target (native or 
remote) doesn't matter.

Andrew

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Christopher Faylor]

On Thu, Sep 23, 2004 at 02:30:11AM -0400, Michael Chastain wrote:
>Christopher Faylor <me@cgf.cx> wrote:
>> MichaelC has indicated which systems support "rb".  Is there any way to
>> somehow figure out if this is supported for the whole list of supported
>> targets?
>
>That brings up a tough philosophical issue.  Well, okay, part of it
>is tough because it implies more work for me.
>
>There isn't a list of supported hosts or supported targets.

There is a list of targets which have maintainers, though.

>The software itself has "list of hosts and targets that somebody, at
>some time in the past, contributed at least some work towards."

Maybe we're talking about the same thing but if there are inactive
maintainers then we need to know about that don't we?  I know that there
are various levels of maintainership but it seems like you should be
able to poll a quorum of maintainers and get a ruling rather than
assuming that we have to be extremely conservative because people who
have volunteered to be target maintainers are not doing their job.

>The gdb-testers@ group records "somebody tested something and reported
>results in some way".  That's where the "more work for me" comes in:
>devising some standard meta-information for a test run (like a little
>XML file, that's what I use in my test bed), and then augmenting the
>test suite to generate gdb-test-run.xml on every run, and then having
>people mail that in, and then begging more people to report their
>results, and then writing "Terf II" to keep track of it all.

I'm not talking about testing.  I know I am a bad maintainer because
I don't run the test suite on cygwin on a periodic basis.  (and if
there was someone waiting in the wings to take over windows maintainership,
I'd happily pass the baton)  We're talking about making architectural
changes which have a simple "will this work (yes/no)" criteria.  I,
as a bad maintainer, would certainly respond to queries of that nature.

If we have maintainers who can't respond to these types of questions maybe
their targets should be deprecated.  Deprecation is the gdb way after all.

>The release criteria for gdb is "break main ; run works on unspecified
>platforms".
>
>> Or can we try going without the wrapper function and move
>> to a wrapper function when someone complains?
>
>For the second question, from a support point of view, I want something
>that (a) works on a lot of systems and (b) when it doesn't work on some
>system, it's an obvious 1-line patch to work around the problem.  So I
>don't like "no wrapper function but then change the code when someone
>shows up with a weird system".

I thought that fopen not working would be a pretty obvious problem with
a pretty obvious fix.

>Personally I like wrappers for ease of porting.  It doesn't bug me to
>see gdb_fopen + fopen on the call stack.

I certainly understand the utility of wrapper functions.  That's pretty
much all that Cygwin is, after all.

>I don't think that "rb" versus "r" can be autoconf'ed.  The gdb
>configure script would need to execute a host program to figure out
>whether "rb" is supported or not, and that won't work if build != host.
>Or maybe I'm wrong about that and there's some way to do it.

I think you're right.  I don't see how we could tell.  That shoots down
my "check for PATH separator" idea, too, I think.

I guess the thing that sticks in my craw is the continual need to stand
on our heads to accommodate that one theoretical system that just might
not work as required.  So, you have to invent a function called
"fopen_wrapper" which is essentially the same thing as "fopen" and that
leaves a programmer to puzzle out why there is an fopen_wrapper rather
than an fopen.

I pointed out that the way this is handled with open now is to define
O_BINARY as required.  It seems like if we are going to be consistent
that open and fopen should use the same mechanism.  So if we go with the
wrapper function for fopen, I think we should do the same for open.

cgf

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Michael Chastain]

Christopher Faylor <me@cgf.cx> wrote:
> I guess the thing that sticks in my craw is the continual need to stand
> on our heads to accommodate that one theoretical system that just might
> not work as required.

Yes, that bugs me, too.  Especially because the "one theoretical system"
is usually some closed source system with a closed source C compiler for
building gcc.

> There is a list of targets which have maintainers, though.

That's true; I didn't consider the nature of the maintainers list.

> We're talking about making architectural changes which have a simple
> "will this work (yes/no)" criteria.  I, as a bad maintainer, would
> certainly respond to queries of that nature.

The problem is, for a lot of questions, it takes actual work to divine
the answer.  For this question it's possible to look in the man pages.
But other questions require people to actually build and run the
software.  Questions such as: "can we dump the special sourceware
version of expect and tell everyone to use the stock version",
or "do we need all this AIX-specific cruft in the test suite".

> I thought that fopen not working would be a pretty obvious problem with
> a pretty obvious fix.

Ah, I was a bit blind last night.

If gdb has a wrapper-less fopen:

  fp = fopen (filename, "rb");

Then the obvious workaround on host ancient-unknown-unix is
to keep it wrapper-less:

  fp = fopen (filename, "r");

I like wrappers better but it's not a big deal to me, wrapper-less
is fine with me.

Michael

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Christopher Faylor]

On Thu, Sep 23, 2004 at 01:20:48PM -0400, Michael Chastain wrote:
>Christopher Faylor <me@cgf.cx> wrote:
>>I guess the thing that sticks in my craw is the continual need to stand
>>on our heads to accommodate that one theoretical system that just might
>>not work as required.
>
>Yes, that bugs me, too.  Especially because the "one theoretical
>system" is usually some closed source system with a closed source C
>compiler for building gcc.

Exactly.

>> We're talking about making architectural changes which have a simple
>> "will this work (yes/no)" criteria.  I, as a bad maintainer, would
>> certainly respond to queries of that nature.
>
>The problem is, for a lot of questions, it takes actual work to divine
>the answer.  For this question it's possible to look in the man pages.
>But other questions require people to actually build and run the
>software.  Questions such as: "can we dump the special sourceware
>version of expect and tell everyone to use the stock version",
>or "do we need all this AIX-specific cruft in the test suite".

That's a good point.  For this one particular question, however, it
should be easy to poll people.

>> I thought that fopen not working would be a pretty obvious problem with
>> a pretty obvious fix.
>
>Ah, I was a bit blind last night.
>
>If gdb has a wrapper-less fopen:
>
>  fp = fopen (filename, "rb");
>
>Then the obvious workaround on host ancient-unknown-unix is
>to keep it wrapper-less:
>
>  fp = fopen (filename, "r");
>
>I like wrappers better but it's not a big deal to me, wrapper-less
>is fine with me.

I guess the above assumes that fopen will return NULL and it will be
immediately evident what the problem is.  Hopefully that, at least,
is a good assumption.

cgf

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Joel Brobecker]

> The gdb-testers@ group records "somebody tested something and reported
> results in some way".  That's where the "more work for me" comes in:
> devising some standard meta-information for a test run (like a little
> XML file, that's what I use in my test bed), and then augmenting the
> test suite to generate gdb-test-run.xml on every run, and then having
> people mail that in, and then begging more people to report their
> results, and then writing "Terf II" to keep track of it all.

We actually put this sort of information in our own testsuite reports.
I think the only way for you to collect this information is by having
it automatically collected and inserted at the begining of gdb.sum.

> Personally I like wrappers for ease of porting.  It doesn't bug me to
> see gdb_fopen + fopen on the call stack.

And we have plenty of wrappers already (in libiberty for instance).

> I don't think that "rb" versus "r" can be autoconf'ed.  The gdb
> configure script would need to execute a host program to figure out
> whether "rb" is supported or not, and that won't work if build != host.
> Or maybe I'm wrong about that and there's some way to do it.

I must say I am not convinced that it is such a good idea to support
that setup. I wouldn't bother about this until somebody has a real
interest in that support, and then can step up and maintain it.
In the meantime, we're just letting the best be the enemy of good, and
as a consequence have to find elaborate solutions to problems made more
complex by this requirement.  Intellectually rewarding, but slows down
development.

-- 
Joel

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Daniel Jacobowitz]

On Thu, Sep 23, 2004 at 08:18:02AM -0700, Joel Brobecker wrote:
> > I don't think that "rb" versus "r" can be autoconf'ed.  The gdb
> > configure script would need to execute a host program to figure out
> > whether "rb" is supported or not, and that won't work if build != host.
> > Or maybe I'm wrong about that and there's some way to do it.
> 
> I must say I am not convinced that it is such a good idea to support
> that setup. I wouldn't bother about this until somebody has a real
> interest in that support, and then can step up and maintain it.
> In the meantime, we're just letting the best be the enemy of good, and
> as a consequence have to find elaborate solutions to problems made more
> complex by this requirement.  Intellectually rewarding, but slows down
> development.

For the previous question of testing, I don't think it's a worthwhile
requirement; however, it's a very important requirement for build time. 
I build with --build != --host routinely.  So do a lot of Cygwin folks,
I think.

-- 
Daniel Jacobowitz

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Andrew Cagney]

> On Thu, Sep 23, 2004 at 08:18:02AM -0700, Joel Brobecker wrote:
> 
>>>> > I don't think that "rb" versus "r" can be autoconf'ed.  The gdb
>>>> > configure script would need to execute a host program to figure out
>>>> > whether "rb" is supported or not, and that won't work if build != host.
>>>> > Or maybe I'm wrong about that and there's some way to do it.
>>
>>> 
>>> I must say I am not convinced that it is such a good idea to support
>>> that setup. I wouldn't bother about this until somebody has a real
>>> interest in that support, and then can step up and maintain it.
>>> In the meantime, we're just letting the best be the enemy of good, and
>>> as a consequence have to find elaborate solutions to problems made more
>>> complex by this requirement.  Intellectually rewarding, but slows down
>>> development.

Yes, definitly.

We've no evidence that we've a real problem here, and hence no evidence 
that a wrapper is needed.  All I see a dig achieving is to flush out 
legacy systems on which GDB no longer builds.  If someone with such a 
legacy system really really needs a modern GDB then I'm sure that 
they'll step up to the challenge of solving this and many other problem.

Lets base this decision on what is, what not might once have been.  And 
lets resist the temptation to add wrapper runtime checks that we can't 
even test (as in with a full working GDB).

> For the previous question of testing, I don't think it's a worthwhile
> requirement; however, it's a very important requirement for build time. 
> I build with --build != --host routinely.  So do a lot of Cygwin folks,
> I think.

You'll need to be more specific.  Which build, which host.  Presumably 
these are all modern hosts and support "rb".

Andrew

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Eli Zaretskii]

> Date: Fri, 24 Sep 2004 11:03:08 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: Michael Chastain <mec.gnu@mindspring.com>, me@cgf.cx,
>         gdb-patches@sources.redhat.com
> 
> We've no evidence that we've a real problem here, and hence no evidence 
> that a wrapper is needed.  All I see a dig achieving is to flush out 
> legacy systems on which GDB no longer builds.  If someone with such a 
> legacy system really really needs a modern GDB then I'm sure that 
> they'll step up to the challenge of solving this and many other problem.

Mark, how do you feel about losing the wrappers?  Would it be okay for
me to do it that way, or do you feel strongly about them?

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Mark Kettenis]

   Date: Sat, 25 Sep 2004 18:40:53 +0200
   From: "Eli Zaretskii" <eliz@gnu.org>

   > Date: Fri, 24 Sep 2004 11:03:08 -0400
   > From: Andrew Cagney <cagney@gnu.org>
   > Cc: Michael Chastain <mec.gnu@mindspring.com>, me@cgf.cx,
   >         gdb-patches@sources.redhat.com
   > 
   > We've no evidence that we've a real problem here, and hence no evidence 
   > that a wrapper is needed.  All I see a dig achieving is to flush out 
   > legacy systems on which GDB no longer builds.  If someone with such a 
   > legacy system really really needs a modern GDB then I'm sure that 
   > they'll step up to the challenge of solving this and many other problem.

   Mark, how do you feel about losing the wrappers?  Would it be okay for
   me to do it that way, or do you feel strongly about them?

I don't feel too strongly about it.  The "b" modifier is mentioned in
the 4.3BSD/Net2 headers, and Ultrix 4.0 also has it.  That's pretty
ancient stuff.  But I'd appreciate it if you, and other people, keep
in the back of your mind that there may still be systems that don't
support the "b" modifier.  So avoid using "b" wherever possible, and
keep using the macro's from include/fopen-*.h.

In the discussion we've had over the past days people have been taling
about supported and unsupported hosts, as if there is some restricted
list of machines that GDB runs on.  While that's currently the case, I
think it's wrong to think about it like that.  Yes, we have a list of
supported *native* hosts, but actually it should be possible to
compile GDB on any system that's POSIX-ish.  If that system isn't on
the list of native host, you wouldn't get the ability to debug native
programs, but you'd still be able to use the remote protocol to debug
programs on another system.  Therefore we should try to make the
generic parts of GDB as portable as we can.  IMHO, compiling GDB on
ancient systems helps to keep us honest about that.  That's why I
recently added back the vax-dec-ultrix4* stuff.

Cheers,

Mark

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Daniel Jacobowitz]

On Fri, Sep 24, 2004 at 11:03:08AM -0400, Andrew Cagney wrote:
> >For the previous question of testing, I don't think it's a worthwhile
> >requirement; however, it's a very important requirement for build time. 
> >I build with --build != --host routinely.  So do a lot of Cygwin folks,
> >I think.
> 
> You'll need to be more specific.  Which build, which host.  Presumably 
> these are all modern hosts and support "rb".

My point was not for "rb" in particular - you're quite right - but just
correcting Joel's statement about the existance of --build/--host
users.  If we had some need to autoconf for this and just default it to
"rb", that would be in practice OK (though autoconf tests with
cross-build defaults are EVIL INCARNATE).

-- 
Daniel Jacobowitz

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Mark Kettenis]

   Date: Thu, 23 Sep 2004 01:05:34 -0400
   From: Christopher Faylor <me@cgf.cx>

   On Sat, Sep 18, 2004 at 04:18:31PM +0300, Eli Zaretskii wrote:
   >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.

   I'd be happy to see this but I see that later in the thread that we
   seem to be converging on a wrapper function.

I still favour the wrapper function, since that's more robust, but I
wouldn't really object if we'd use exactly the same configure magic as
BFD does.  Note that that imposes a burden on the maintainers of
DOS-ish systems to keep it in sync with BFD.

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

   This could be determined at configure time couldn't it?  You could
   play with the path to see if a colon or semicolon does the desired
   thing and then set it appropriately via config.in.

Please note that DIRNAME_SEPARATOR is only used in GDB.  Preferably it
would be the same on all hosts, although it makes sense to follow the
convention of the host platform if there is one.  That's why we have
':' on POSIX-ish systems.  The most important reasone why it's
something different on DOS-ish systems, is that ':' is to specify
drive letters and therefore useless as a sepatator.  Makes me wonder
why cygwin uses ':'.

Mark

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Christopher Faylor]

On Thu, Sep 23, 2004 at 10:58:17PM +0200, Mark Kettenis wrote:
>   Date: Thu, 23 Sep 2004 01:05:34 -0400
>   From: Christopher Faylor <me@cgf.cx>
>
>   On Sat, Sep 18, 2004 at 04:18:31PM +0300, Eli Zaretskii wrote:
>   >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.
>
>   I'd be happy to see this but I see that later in the thread that we
>   seem to be converging on a wrapper function.
>
>I still favour the wrapper function, since that's more robust, but I
>wouldn't really object if we'd use exactly the same configure magic as
>BFD does.  Note that that imposes a burden on the maintainers of
>DOS-ish systems to keep it in sync with BFD.

i.e.,

  dnl See whether we need to use fopen-bin.h rather than fopen-same.h.
  AC_DEFUN([BFD_BINARY_FOPEN],
  [AC_REQUIRE([AC_CANONICAL_SYSTEM])
  case "${host}" in
  changequote(,)dnl
  *-*-msdos* | *-*-go32* | *-*-mingw32* | *-*-cygwin* | *-*-windows*)
  changequote([,])dnl
    AC_DEFINE(USE_BINARY_FOPEN, 1, [Use b modifier when opening binary files?]) ;;
  esac])dnl

Since I've never had to worry about this in binutils, it's probably ok
but, these days, I think it's backwards to put the burden on the
maintainers of the modern systems (i.e., cygwin and DJGPP) at the
expense of the hypothetical ancient ones.  Why not let the Ultrix
maintainer worry about this rather than the cygwin/djgpp maintainers?

>   >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).
>
>   This could be determined at configure time couldn't it?  You could
>   play with the path to see if a colon or semicolon does the desired
>   thing and then set it appropriately via config.in.
>
>Please note that DIRNAME_SEPARATOR is only used in GDB.  Preferably it
>would be the same on all hosts, although it makes sense to follow the
>convention of the host platform if there is one.  That's why we have
>':' on POSIX-ish systems.  The most important reasone why it's
>something different on DOS-ish systems, is that ':' is to specify
>drive letters and therefore useless as a sepatator.  Makes me wonder
>why cygwin uses ':'.

Cygwin is a POSIX emulation and it should be using the same thing as
UNIX.  You can actually use colons (and semicolons for that matter) in
file names in Cygwin, depending on the mount option.

A simple way to see what the preference is would be to poll the PATH
environment variable.  But, then, it's easy enough to must make it ';'
for the one host that needs it by using a similar technique to the
above.

cgf

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Eli Zaretskii]

Thanks to everybody for useful feedback.

Let me try to summarize this discussion.

It sounds like everyone agreed that the solution to GDBINIT_FILENAME
is to have a list of file names and try them in sequence until
succeeded.  I'm okay with that, but I worry a bit whether this won't
break some people who have both .gdbinit and gdb.ini in the same
directory (for example, if some distribution comes with both to be
useful on different systems).  I guess such situations are rare,
though.

I also didn't read any objections to have GDB support both NL-only and
CRLF style source files.

So, unless someone voices objections in the next few days, I'm going
to code these two changes.

About fopen-bin.h: As I said before, I'm okay with writing wrapper
functions, but let me first reply to the few comments raised during
the discussions.

> Date: Thu, 23 Sep 2004 01:05:34 -0400
> From: Christopher Faylor <me@cgf.cx>
> 
> Is a wrapper function more better than just doing:
> 
> #ifdef USEB
> #define READ "rb"
> #else
> #define READ "r"
> #endif
> 
>   fopen ("foo", READ)

We do that now; the problem is, where should USEB or its equivalent be
defined.

A wrapper function will do something like this:

    FILE *fp = fopen (file, "rb");
    if (!fp)
      fp = fopen (file, "r");
    return fp;

This assumes that if the `b' qualifier is not supported, `fopen'
either fails for "rb" or silently ignores `b'.

> It's similar to how we handle the similar use of O_BINARY now.

The difference between O_BINARY and "rb" is that the former is defined
in a well-known system header on systems that need it, while there's
no similar macro for the latter.

> Out of curiousity is O_BINARY mandated by ISO C?  I suspect not.

O_BINARY is a Posix thing (ANSI C doesn't know about `open' at all),
so ISO C has nothing to say about it.  But even if you look at the
latest Posix (well, the draft I have here), you will not find O_BINARY
there.  So Posix systems are not allowed to distinguish between text
and binary files.

> >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).
> 
> This could be determined at configure time couldn't it?  You could
> play with the path to see if a colon or semicolon does the desired
> thing and then set it appropriately via config.in.

I don't think it's a good idea.  First, this requires to _run_ a test
program, not just compile/link it, which is bad for cross-compiling.
And second, it sounds silly to me to make an autoconf test for a
single supported port which will _always_ need it.

> On Thu, Sep 23, 2004 at 10:58:17PM +0200, Mark Kettenis wrote:
> >   Date: Thu, 23 Sep 2004 01:05:34 -0400
> >   From: Christopher Faylor <me@cgf.cx>
> >
> >   On Sat, Sep 18, 2004 at 04:18:31PM +0300, Eli Zaretskii wrote:
> >   >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.
> >
> >   I'd be happy to see this but I see that later in the thread that we
> >   seem to be converging on a wrapper function.
> >
> >I still favour the wrapper function, since that's more robust, but I
> >wouldn't really object if we'd use exactly the same configure magic as
> >BFD does.  Note that that imposes a burden on the maintainers of
> >DOS-ish systems to keep it in sync with BFD.
> 
> i.e.,
> 
>   dnl See whether we need to use fopen-bin.h rather than fopen-same.h.
>   AC_DEFUN([BFD_BINARY_FOPEN],
>   [AC_REQUIRE([AC_CANONICAL_SYSTEM])
>   case "${host}" in
>   changequote(,)dnl
>   *-*-msdos* | *-*-go32* | *-*-mingw32* | *-*-cygwin* | *-*-windows*)
>   changequote([,])dnl
>     AC_DEFINE(USE_BINARY_FOPEN, 1, [Use b modifier when opening binary files?]) ;;
>   esac])dnl

That's exactly something I find silly: there's a known fixed list of
configurations that need USE_BINARY_FOPEN to be defined, so why should
we put it in configure.in instead of having it directly in config.in?
(Btw, in our case, the list of configurations that need that will be
much shorter.)

> Since I've never had to worry about this in binutils, it's probably ok
> but, these days, I think it's backwards to put the burden on the
> maintainers of the modern systems (i.e., cygwin and DJGPP) at the
> expense of the hypothetical ancient ones.  Why not let the Ultrix
> maintainer worry about this rather than the cygwin/djgpp maintainers?

Right.  The above was justified 10 years ago, when the systems that
supported the binary flag were the minority, but going the same way
today sounds not such a good idea.

> A simple way to see what the preference is would be to poll the PATH
> environment variable.  But, then, it's easy enough to must make it ';'
> for the one host that needs it by using a similar technique to the
> above.

Exactly!  And for the same reasons as I mentioned above, since only
one well-known system needs DIRNAME_SEPARATOR to be ';', I suggest to
define it in a single place conditioned by that system.

So my preferences are: to use "rb" and "wb" unconditionally, and to
define DIRNAME_SEPARATOR for DJGPP in defs.h.  However, if Mark would
still like wrappers for the former, I'll do it that way.

If anyone has further reservations about that, please speak up.

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Corinna Vinschen]

On Sep 24 12:46, Eli Zaretskii wrote:
> > Out of curiousity is O_BINARY mandated by ISO C?  I suspect not.
> 
> O_BINARY is a Posix thing (ANSI C doesn't know about `open' at all),
> so ISO C has nothing to say about it.  But even if you look at the
> latest Posix (well, the draft I have here), you will not find O_BINARY
> there.  So Posix systems are not allowed to distinguish between text
> and binary files.

That's nothing GDB should be concerned of, probably, but that's definitely
a leak in the definitions.  How much sense does it make to allow "b" in
fopen but no equivalent in the low-level interface :-(

Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Andreas Schwab]

Corinna Vinschen <vinschen@redhat.com> writes:

> That's nothing GDB should be concerned of, probably, but that's definitely
> a leak in the definitions.  How much sense does it make to allow "b" in
> fopen but no equivalent in the low-level interface :-(

Doing the text conversion on the low level creates a heap of problems with
POSIX semantics.  The stdio level is much better suited for this task.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Christopher Faylor]

On Fri, Sep 24, 2004 at 03:36:21PM +0200, Andreas Schwab wrote:
>Corinna Vinschen <vinschen@redhat.com> writes:
>>That's nothing GDB should be concerned of, probably, but that's
>>definitely a leak in the definitions.  How much sense does it make to
>>allow "b" in fopen but no equivalent in the low-level interface :-(
>
>Doing the text conversion on the low level creates a heap of problems
>with POSIX semantics.  The stdio level is much better suited for this
>task.

Yeah, but it makes things pretty tough for a system that has to support
tough, like what happens when you do an fdopen on a file that has been
open()ed with O_TEXT and then do an 'fseek'?

I truly all of this binary/text stuff.  I wish Cygwin had never tried to
continue to advance the distinction.

cgf

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Christopher Faylor]

On Fri, Sep 24, 2004 at 03:53:30PM -0400, Christopher Faylor wrote:
>On Fri, Sep 24, 2004 at 03:36:21PM +0200, Andreas Schwab wrote:
>>Corinna Vinschen <vinschen@redhat.com> writes:
>>>That's nothing GDB should be concerned of, probably, but that's
>>>definitely a leak in the definitions.  How much sense does it make to
>>>allow "b" in fopen but no equivalent in the low-level interface :-(
>>
>>Doing the text conversion on the low level creates a heap of problems
>>with POSIX semantics.  The stdio level is much better suited for this
>>task.
>
>Yeah, but it makes things pretty tough for a system that has to support
>tough, like what happens when you do an fdopen on a file that has been
>open()ed with O_TEXT and then do an 'fseek'?
>
>I truly all of this binary/text stuff.  I wish Cygwin had never tried to
        ^
      detest
>continue to advance the distinction.

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Andreas Schwab]

Christopher Faylor <me@cgf.cx> writes:

> On Fri, Sep 24, 2004 at 03:36:21PM +0200, Andreas Schwab wrote:
>>Corinna Vinschen <vinschen@redhat.com> writes:
>>>That's nothing GDB should be concerned of, probably, but that's
>>>definitely a leak in the definitions.  How much sense does it make to
>>>allow "b" in fopen but no equivalent in the low-level interface :-(
>>
>>Doing the text conversion on the low level creates a heap of problems
>>with POSIX semantics.  The stdio level is much better suited for this
>>task.
>
> Yeah, but it makes things pretty tough for a system that has to support
> tough, like what happens when you do an fdopen on a file that has been
> open()ed with O_TEXT and then do an 'fseek'?

That's what I meant with heap of problems.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Eli Zaretskii]

> Date: Fri, 24 Sep 2004 14:24:06 +0200
> From: Corinna Vinschen <vinschen@redhat.com>
> 
> How much sense does it make to allow "b" in fopen but no equivalent
> in the low-level interface :-(

My take of this is that Posix had no choice: the Posix C-related
standards are a superset of ANSI/ISO C, and ISO mandates "b".

Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Ian Lance Taylor]

Corinna Vinschen <vinschen@redhat.com> writes:

> On Sep 24 12:46, Eli Zaretskii wrote:
> > > Out of curiousity is O_BINARY mandated by ISO C?  I suspect not.
> > 
> > O_BINARY is a Posix thing (ANSI C doesn't know about `open' at all),
> > so ISO C has nothing to say about it.  But even if you look at the
> > latest Posix (well, the draft I have here), you will not find O_BINARY
> > there.  So Posix systems are not allowed to distinguish between text
> > and binary files.
> 
> That's nothing GDB should be concerned of, probably, but that's definitely
> a leak in the definitions.  How much sense does it make to allow "b" in
> fopen but no equivalent in the low-level interface :-(

POSIX and ISO C are different standards.

In a POSIX system there can be no difference between text and binary
files.  So there is no reason for POSIX to specify O_BINARY.

ISO C permits distinctions between text and binary files, since ISO C
is used on non-POSIX systems such as Windows.  So ISO C specifies that
'b' is permitted in fopen and related calls.

POSIX supports but does not require ISO C.  When ISO C is used on
POSIX, fopen and friends ignore the 'b'.

O_BINARY exists because systems like Windows like to have almost-POSIX
interfaces.  O_BINARY was invented so that such systems could continue
to distinguish text and binary files in the almost-POSIX open call.

Ian