Re: [Mingw-users] Re: _WIN32?

Re: [Mingw-users] Re: _WIN32?

[Paul Hilfinger]

ACT, Inc. is also committed to producing or assisting in a MINGW32
port of GDB5, and contributing the necessary patches.  However, I
don't have a timetable for this yet.

In any case, again this argues against removing the _WIN32 conditionals.

Paul Hilfinger

Re: [Mingw-users] Re: _WIN32?

[Andrew Cagney]

> ACT, Inc. is also committed to producing or assisting in a MINGW32
> port of GDB5, and contributing the necessary patches.  However, I
> don't have a timetable for this yet.
> 
> In any case, again this argues against removing the _WIN32 conditionals.

I'm not so sure.  It depends on why/how the tests are there. For instance:


#if defined(_WIN32) || defined(__MSDOS__) || defined(__CYGWIN__):

Remember, GDB is moving away from OS specific tests and towards 
autoconf/feature based tests.  Things like this should be replaced by 
something like WITH_REALLY_TRICKY_FILESYSTEM_SUPPORT test (and 
eventually changed to a runtime switch?).


main.c:
   /* The default command loop.
      The WIN32 Gui calls this main to set up gdb's state, and
      has its own command loop. */
#if !defined _WIN32 || defined __GNUC__
   /* GUIs generally have their own command loop, mainloop, or
      whatever.  This is a good place to gain control because many
      error conditions will end up here via longjmp(). */
The _WIN32 test here is probably for wingdb (and old, long dead, MS 
Windows based GDB) and not for mingw.  There are plenty of other 
examples of the same thing.

For reference, there are ~38 uses of _WIN32 in the sources, ~18 don't 
appear to be accompanied by #ifdef MSDOS, CYGWIN or GO32. It is those 18 
that I think should be deleted.

	Andrew

Re: [Mingw-users] Re: _WIN32?

[Danny Smith]

--- Andrew Cagney <ac131313@cygnus.com> wrote: > > ACT, Inc. is also committed
to producing or assisting in a MINGW32
> > port of GDB5, and contributing the necessary patches.  However, I
> > don't have a timetable for this yet.
> > 
> > In any case, again this argues against removing the _WIN32 conditionals.
> 
> I'm not so sure.  It depends on why/how the tests are there. For instance:
> 
> 
> #if defined(_WIN32) || defined(__MSDOS__) || defined(__CYGWIN__):
> 
> Remember, GDB is moving away from OS specific tests and towards 
> autoconf/feature based tests.  Things like this should be replaced by

> something like WITH_REALLY_TRICKY_FILESYSTEM_SUPPORT test (and 
> eventually changed to a runtime switch?).
> 
> 
> main.c:
>    /* The default command loop.
>       The WIN32 Gui calls this main to set up gdb's state, and
>       has its own command loop. */
> #if !defined _WIN32 || defined __GNUC__
>    /* GUIs generally have their own command loop, mainloop, or
>       whatever.  This is a good place to gain control because many
>       error conditions will end up here via longjmp(). */
> The _WIN32 test here is probably for wingdb (and old, long dead, MS 
> Windows based GDB) and not for mingw.  There are plenty of other 
> examples of the same thing.
> 
> For reference, there are ~38 uses of _WIN32 in the sources, ~18 don't 
> appear to be accompanied by #ifdef MSDOS, CYGWIN or GO32. It is those 18 
> that I think should be deleted.
> 
> 	Andrew
> 
>
In trying to get GDB to work under mingw, I have found the #if(n)def _WIN32 
useful as tags to look for potential trouble spots, but let me ask you to
clarify something:

You are proposing that something like this in inflow.c 

#ifndef _WIN32
  kill (PIDGET (inferior_pid), SIGINT);
#endif

would be replaced with something like this:

#ifndef _N0_KILL_
  kill (PIDGET (inferior_pid), SIGINT);
#endif

with configure defining _NO_KILL for me.

Is that correct?  If so, then I have no objections to replacing the _WIN32
conditionals with something more specific.

Danny

_____________________________________________________________________________
http://store.yahoo.com.au - Yahoo! Store
- It's time you had your business online!

Re: [Mingw-users] Re: _WIN32?

[Andrew Cagney]

For:

> #ifndef _WIN32
>   kill (PIDGET (inferior_pid), SIGINT);
> #endif
> 
> would be replaced with something like this:
> 
> #ifndef _N0_KILL_
> kill (PIDGET (inferior_pid), SIGINT);
> #endif

I'm actually puzzled.  It looks very like someone took a shortcut and, 
instead of implementing new methods, just went through and commented out 
every call to kill().  cf handle_sigio().

Anyway, to answer your question:

> You are proposing that something like this in inflow.c 

Yes, for the most part I would like to strongly encouraging people doing 
WIN32, GO32 and CYGWIN ports to look back over all those #ifdef's and 
see if they are better served by an autoconf feature test. Per my 
earlier e-mail, the obvious oneis to do with how file systems are DOS 
file systems are handled and there, I think things are being replaced 
with a runtime test.

There is also at least one specific case, main.c, where I think the 
_WIN32 test is bogus.

   enjoy,
	Andrew

Re: [Mingw-users] Re: _WIN32?

[Christopher Faylor]

On Thu, May 03, 2001 at 06:24:32PM -0400, Andrew Cagney wrote:
>For:
>
>> #ifndef _WIN32
>>   kill (PIDGET (inferior_pid), SIGINT);
>> #endif
>> 
>> would be replaced with something like this:
>> 
>> #ifndef _N0_KILL_
>> kill (PIDGET (inferior_pid), SIGINT);
>> #endif
>
>I'm actually puzzled.  It looks very like someone took a shortcut and, 
>instead of implementing new methods, just went through and commented out 
>every call to kill().  cf handle_sigio().
>
>Anyway, to answer your question:
>
>> You are proposing that something like this in inflow.c 
>
>Yes, for the most part I would like to strongly encouraging people doing 
>WIN32, GO32 and CYGWIN ports to look back over all those #ifdef's and 
>see if they are better served by an autoconf feature test. Per my 
>earlier e-mail, the obvious oneis to do with how file systems are DOS 
>file systems are handled and there, I think things are being replaced 
>with a runtime test.

FWIW, I strongly agree with this sentiment.  Host conditionals are evil.

Should this be a goal for 5.1?

cgf

Re: [Mingw-users] Re: _WIN32?

[Andrew Cagney]

> FWIW, I strongly agree with this sentiment.  Host conditionals are evil.
> 
> Should this be a goal for 5.1?


Clearly! ;-)

More seriously, I'll just add them to the ARI table so that they can be 
eliminated over time.

	Andrew

Re: [Mingw-users] Re: _WIN32?

[Eli Zaretskii]

> Date: Thu, 03 May 2001 19:11:48 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> > FWIW, I strongly agree with this sentiment.  Host conditionals are evil.
> > 
> > Should this be a goal for 5.1?
> 
> 
> Clearly! ;-)
> 
> More seriously, I'll just add them to the ARI table so that they can be 
> eliminated over time.

If it is decided to Autoconfiscate these tests, I will need help with
this, since I don't know Autoconf (and don't have time to learn it).
I can suggest ways to test each feature, but someone will have to help
me put these tests into Autoconf-ese.

Re: [Mingw-users] Re: _WIN32?

[Eli Zaretskii]

> Date: Thu, 03 May 2001 18:24:32 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> I'm actually puzzled.  It looks very like someone took a shortcut and, 
> instead of implementing new methods, just went through and commented out 
> every call to kill().  cf handle_sigio().

In this case, it might be easier to write a version of kill() that
does nothing (e.g., define a macro).

> Yes, for the most part I would like to strongly encouraging people doing 
> WIN32, GO32 and CYGWIN ports to look back over all those #ifdef's and 
> see if they are better served by an autoconf feature test.

Based on my experience, quite a few of them won't be served better by
an Autoconf test, because it isn't quite clear what to test.  One
notable example is the terminal initialization in
utils.c:init_page_info--how do you test for something whose effect is
on the screen?

So I think some of the tests will have to be left alone.  It is
possible to make them less OS-dependent by defining a set of more
portable macros, along the lines of FILENAME_CMP, but the macro
definitions will need to be system-dependent (see filenames.h for an
example).

If it will help, I can prepare a list which describes all uses of
these system-dependent fragments in GDB sources with the reasons for
each one of them, and publish it here as a base for further
discussions.

> Per my 
> earlier e-mail, the obvious oneis to do with how file systems are DOS 
> file systems are handled and there, I think things are being replaced 
> with a runtime test.

If you mean the FILENAME_CMP and IS_ABSOLUTE_PATH, then these are
compile-time tests.

Re: [Mingw-users] Re: _WIN32?

[Christopher Faylor]

On Fri, May 04, 2001 at 05:19:04AM -0400, Eli Zaretskii wrote:
>> Date: Thu, 03 May 2001 18:24:32 -0400
>> From: Andrew Cagney <ac131313@cygnus.com>
>> 
>> I'm actually puzzled.  It looks very like someone took a shortcut and, 
>> instead of implementing new methods, just went through and commented out 
>> every call to kill().  cf handle_sigio().
>
>In this case, it might be easier to write a version of kill() that
>does nothing (e.g., define a macro).
>
>> Yes, for the most part I would like to strongly encouraging people doing 
>> WIN32, GO32 and CYGWIN ports to look back over all those #ifdef's and 
>> see if they are better served by an autoconf feature test.
>
>Based on my experience, quite a few of them won't be served better by
>an Autoconf test, because it isn't quite clear what to test.  One
>notable example is the terminal initialization in
>utils.c:init_page_info--how do you test for something whose effect is
>on the screen?

You don't necessarily have to test for anything.  We could just add
a TERMINAL_DOES_BLAH conditional which was set only when gdb was being
run under cygwin, or djgpp, or (don't worry we're working on it and
will have something in the next <<undeterminied>> timeframe, really
we will) Windows.  You don't actually have to write an autoconf test
for this.

I suspect that most tests are like this because tests like filename
case insensitivity require running a test on the host, which isn't
possible in a cross-build environment anyway... as everyone here
know...

cgf

Re: [Mingw-users] Re: _WIN32?

[Eli Zaretskii]

> Date: Fri, 4 May 2001 11:44:17 -0400
> From: Christopher Faylor <cgf@redhat.com>
> >
> >> Yes, for the most part I would like to strongly encouraging people doing 
> >> WIN32, GO32 and CYGWIN ports to look back over all those #ifdef's and 
> >> see if they are better served by an autoconf feature test.
> >
> >Based on my experience, quite a few of them won't be served better by
> >an Autoconf test, because it isn't quite clear what to test.  One
> >notable example is the terminal initialization in
> >utils.c:init_page_info--how do you test for something whose effect is
> >on the screen?
> 
> You don't necessarily have to test for anything.  We could just add
> a TERMINAL_DOES_BLAH conditional which was set only when gdb was being
> run under cygwin, or djgpp, or (don't worry we're working on it and
> will have something in the next <<undeterminied>> timeframe, really
> we will) Windows.  You don't actually have to write an autoconf test
> for this.

I agree with that approach, but Andrew was talking about Autoconf.

I'm not against Autoconf where Autoconf makes sense, but I wanted to
point out that some issues are not Autoconfiscated easily.

> I suspect that most tests are like this because tests like filename
> case insensitivity require running a test on the host, which isn't
> possible in a cross-build environment anyway... as everyone here
> know...

Yes, precisely.

Re: [Mingw-users] Re: _WIN32?

[Christopher Faylor]

On Fri, May 04, 2001 at 08:19:10PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 4 May 2001 11:44:17 -0400
>> From: Christopher Faylor <cgf@redhat.com>
>> >
>> >> Yes, for the most part I would like to strongly encouraging people doing 
>> >> WIN32, GO32 and CYGWIN ports to look back over all those #ifdef's and 
>> >> see if they are better served by an autoconf feature test.
>> >
>> >Based on my experience, quite a few of them won't be served better by
>> >an Autoconf test, because it isn't quite clear what to test.  One
>> >notable example is the terminal initialization in
>> >utils.c:init_page_info--how do you test for something whose effect is
>> >on the screen?
>> 
>> You don't necessarily have to test for anything.  We could just add
>> a TERMINAL_DOES_BLAH conditional which was set only when gdb was being
>> run under cygwin, or djgpp, or (don't worry we're working on it and
>> will have something in the next <<undeterminied>> timeframe, really
>> we will) Windows.  You don't actually have to write an autoconf test
>> for this.
>
>I agree with that approach, but Andrew was talking about Autoconf.

So was I.  You could still do this in configure.in.  The alternatives are
having something like:

  #if defined (__CYGWIN__) || defined (__DJGPP__)
  # define FILENAME_CASE_INSENSITIVE
  #endif

of something like (in configure.host):

  case "$host_cpu" in

  i[3456]86-*-cygwin*)
	  gdb_host=cygwin
	  FILENAME_CASE_INSENSITIVE=1
	  ;;

  i[3456]86-*-msdosdjgpp*)
	  gdb_host=go32
	  FILENAME_CASE_INSENSITIVE=1
	  ;;
  esac

  AC_SUBST(FILENAME_CASE_INSENSITIVE)

cgf

Re: [Mingw-users] Re: _WIN32?

[Eli Zaretskii]

> Date: Thu, 03 May 2001 18:24:32 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> Yes, for the most part I would like to strongly encouraging people doing 
> WIN32, GO32 and CYGWIN ports to look back over all those #ifdef's and 
> see if they are better served by an autoconf feature test.

I did that, and identified two classes of reasons for uses of such
#ifdef's:

  - to take care of issues relevant to DOSish file names, which can be
    replaced by macros defined in include/filenames.h;

and

  - to handle other issues which are unrelated to file names.

For the first category, I will publish patches I suggest which remove
all the private GDB macros defined in defs.h, and switch to using the
macros from filenames.h instead.

As for the second category, I will post here the relevant code
fragments and ask for suggestions how to proceed with each one of
them.

DOS/Windows-specific code (was: _WIN32?)

[Eli Zaretskii]

> Date: Mon, 7 May 2001 19:09:53 +0300 (IDT)
> From: Eli Zaretskii <eliz@is.elta.co.il>
> 
> > Date: Thu, 03 May 2001 18:24:32 -0400
> > From: Andrew Cagney <ac131313@cygnus.com>
> > 
> > Yes, for the most part I would like to strongly encouraging people doing 
> > WIN32, GO32 and CYGWIN ports to look back over all those #ifdef's and 
> > see if they are better served by an autoconf feature test.
> 
> I did that, and identified two classes of reasons for uses of such
> #ifdef's:
> 
>   - to take care of issues relevant to DOSish file names, which can be
>     replaced by macros defined in include/filenames.h;
> 
> and
> 
>   - to handle other issues which are unrelated to file names.
> 
> For the first category, I will publish patches I suggest which remove
> all the private GDB macros defined in defs.h, and switch to using the
> macros from filenames.h instead.
> 
> As for the second category, I will post here the relevant code
> fragments and ask for suggestions how to proceed with each one of
> them.

In the following messages I show the code fragments which use MSDOS,
GO32, _WIN32, etc. in #ifdef's.  Each fragment is followed by a short
discussion of possible reasons and solutions.  I would appreciate
opinions and comments as to how best to solve each issue.  TIA.

DOS/Windows-specific code: cli-cmds.c

[Eli Zaretskii]

    * cli-cmds.c:

    /* FIXME: this should be auto-configured!  */
    #ifdef __MSDOS__
    # define CANT_FORK
    #endif

This seems to cry for either an Autoconf test (based on whether the
compiler defines __MSDOS__ or not) or perhaps the whole snippet should
be moved to config/i386/xm-go32.h.


    * cli-cmds.c:shell_escape()

    #ifdef __DJGPP__
      /* Make sure to return to the directory GDB thinks it is, in case the
	 shell command we just ran changed it.  */
      chdir (current_directory);
    #endif

This code is there because the current working directory is a global
notion (as opposed to being private to each process on Posix
systems).  Windows ports, at least the non-Cygwin ones, probably want
this as well.  Suggestions how to test this, anyone?  Should we define
a GLOBAL_CURDIR macro (zero by default)?

Registers are not available in Cygwin

[leonp]

I experience the problem with gdb20010501 under Cygwin. My target is MPC860 
board.
(I had several problems while compiling, such as undefined _WIN32, that I 
solved manually).
Please, look at the following:

(gdb) target ocd wiggler lpt1
Remote target wiggler connected to wiggler lpt1
[Wiggler version b.20, capability 0x1d]
0x000011fc in ?? ()

(gdb) set architecture powerpc:MPC8XX
The target architecture is assumed to be powerpc:MPC8XX

(gdb) set $immr=0xffa00000
Error: read_bdm_registers: Invalid CPU register access attempt failed

I shall be very thankful for any help!!


Leon Pollak
leonp@plris.com

Re: DOS/Windows-specific code: cli-cmds.c

[Christopher Faylor]

On Tue, May 08, 2001 at 02:41:53PM +0300, Eli Zaretskii wrote:
>
>    * cli-cmds.c:
>
>    /* FIXME: this should be auto-configured!  */
>    #ifdef __MSDOS__
>    # define CANT_FORK
>    #endif
>
>This seems to cry for either an Autoconf test (based on whether the
>compiler defines __MSDOS__ or not) or perhaps the whole snippet should
>be moved to config/i386/xm-go32.h.

IMO, it should be moved to xm-go32.h.

>    * cli-cmds.c:shell_escape()
>
>    #ifdef __DJGPP__
>      /* Make sure to return to the directory GDB thinks it is, in case the
>	 shell command we just ran changed it.  */
>      chdir (current_directory);
>    #endif
>
>This code is there because the current working directory is a global
>notion (as opposed to being private to each process on Posix
>systems).  Windows ports, at least the non-Cygwin ones, probably want
>this as well.  Suggestions how to test this, anyone?  Should we define
>a GLOBAL_CURDIR macro (zero by default)?

GLOBAL_CURDIR makes sense to me.

cgf

Re: DOS/Windows-specific code: cli-cmds.c

[Andrew Cagney]

> IMO, it should be moved to xm-go32.h.


Don't forget that the *x* files are going.  config.in/configure.in are 
better.

	Andrew

Re: DOS/Windows-specific code: cli-cmds.c

[Christopher Faylor]

On Tue, May 08, 2001 at 08:51:39PM -0400, Andrew Cagney wrote:
>> IMO, it should be moved to xm-go32.h.
>
>Don't forget that the *x* files are going.  config.in/configure.in are
>better.

Oops.  Right.  Sorry.

cgf

Re: DOS/Windows-specific code: cli-cmds.c

[Eli Zaretskii]

On Tue, 8 May 2001, Andrew Cagney wrote:

> > IMO, it should be moved to xm-go32.h.
> 
> Don't forget that the *x* files are going.  config.in/configure.in are 
> better.

Alternatively, we could simply put it into defs.h.  We have already
quite a few system-dependent defines there.  (Hmm, how about creating
a sysdep.h or something, and moving those defines to that file?)

The downside of configure.in is that it's a lot of fuss for
practically doing the same: you examine some preprocessor macro in the
test program.  Simply testing the same preprocessor macro at GDB
compile time has the same effect.

Re: DOS/Windows-specific code: cli-cmds.c

[Andrew Cagney]

> On Tue, 8 May 2001, Andrew Cagney wrote:
> 
> 
>> > IMO, it should be moved to xm-go32.h.
> 
>> 
>> Don't forget that the *x* files are going.  config.in/configure.in are 
>> better.
> 
> 
> Alternatively, we could simply put it into defs.h.  We have already
> quite a few system-dependent defines there.  (Hmm, how about creating
> a sysdep.h or something, and moving those defines to that file?)
> 
> The downside of configure.in is that it's a lot of fuss for
> practically doing the same: you examine some preprocessor macro in the
> test program.  Simply testing the same preprocessor macro at GDB
> compile time has the same effect.

True. Looking at defs.h most of those will probably be moved to filenames.h.

Anyway, I'll leave it to you can Chris to figure out.  From my point of 
view I'm pretty happy, it flushed out some more of WinGDB.

	Andrew

Re: DOS/Windows-specific code: cli-cmds.c

[Andrew Cagney]

>  * cli-cmds.c:shell_escape()
> 
>     #ifdef __DJGPP__
>       /* Make sure to return to the directory GDB thinks it is, in case the
> 	 shell command we just ran changed it.  */
>       chdir (current_directory);
>     #endif
> 
> This code is there because the current working directory is a global
> notion (as opposed to being private to each process on Posix
> systems).  Windows ports, at least the non-Cygwin ones, probably want
> this as well.  Suggestions how to test this, anyone?  Should we define
> a GLOBAL_CURDIR macro (zero by default)?


GDB, may its self, one day need some similar notion of current directory.

Consider a debug environment containing:

	o	core/lib-gdb
	o	a GUI/MI
	o	a CLI

Should the user entering CLI commands that change the GDB processes 
apparent directory affect the GUI?

	Andrew

Re: DOS/Windows-specific code: cli-cmds.c

[Eli Zaretskii]

On Tue, 8 May 2001, Andrew Cagney wrote:

> >  * cli-cmds.c:shell_escape()
> > 
> >     #ifdef __DJGPP__
> >       /* Make sure to return to the directory GDB thinks it is, in case the
> > 	 shell command we just ran changed it.  */
> >       chdir (current_directory);
> >     #endif
> > 
> > This code is there because the current working directory is a global
> > notion (as opposed to being private to each process on Posix
> > systems).  Windows ports, at least the non-Cygwin ones, probably want
> > this as well.  Suggestions how to test this, anyone?  Should we define
> > a GLOBAL_CURDIR macro (zero by default)?
> 
> 
> GDB, may its self, one day need some similar notion of current directory.
> 
> Consider a debug environment containing:
> 
> 	o	core/lib-gdb
> 	o	a GUI/MI
> 	o	a CLI
> 
> Should the user entering CLI commands that change the GDB processes 
> apparent directory affect the GUI?

Are you saying that it is okay to make the code above be compiled
unconditionally?  (That would involve some additional overhead of
issuing a system call on Posix platforms, but otherwise is a no-op, so
it doesn't hurt too much.)  If this will allow future extensions, I'm
happy with such a change.

Re: DOS/Windows-specific code: cli-cmds.c

[Andrew Cagney]

> GDB, may its self, one day need some similar notion of current directory.
>> 
>> Consider a debug environment containing:
>> 
>> o	core/lib-gdb
>> o	a GUI/MI
>> o	a CLI
>> 
>> Should the user entering CLI commands that change the GDB processes 
>> apparent directory affect the GUI?
> 
> 
> Are you saying that it is okay to make the code above be compiled
> unconditionally?  (That would involve some additional overhead of
> issuing a system call on Posix platforms, but otherwise is a no-op, so
> it doesn't hurt too much.)  If this will allow future extensions, I'm
> happy with such a change.

I'm ok with that code the way it is or compiled unconditionally. 
Personally I'd leave it to the person that takes on the challenge of 
figuring out the exact semantics of the above.

	Andrew

DOS/Windows-specific code: exec.c and symfile.c

[Eli Zaretskii]

    * exec.c:exec_file_attach()

	  scratch_chan = openp (getenv ("PATH"), 1, filename,
		       write_files ? O_RDWR | O_BINARY : O_RDONLY | O_BINARY, 0,
				&scratch_pathname);
    #if defined(__GO32__) || defined(_WIN32) || defined(__CYGWIN__)
	  if (scratch_chan < 0)
	    {
	      char *exename = alloca (strlen (filename) + 5);
	      strcat (strcpy (exename, filename), ".exe");
	      scratch_chan = openp (getenv ("PATH"), 1, exename, write_files ?
		 O_RDWR | O_BINARY : O_RDONLY | O_BINARY, 0, &scratch_pathname);
	    }
    #endif

This snippet wants to find `foo.exe' when `foo' is being specified.
Should we add a #define for executable extensions (defaulting to an
empty string on Unix)?


    * symfile.c:symfile_bfd_open()

      /* Look down path for it, allocate 2nd new malloc'd copy.  */
      desc = openp (getenv ("PATH"), 1, name, O_RDONLY | O_BINARY, 0, &absolute_name);
    #if defined(__GO32__) || defined(_WIN32)
      if (desc < 0)
	{
	  char *exename = alloca (strlen (name) + 5);
	  strcat (strcpy (exename, name), ".exe");
	  desc = openp (getenv ("PATH"), 1, exename, O_RDONLY | O_BINARY,
			0, &absolute_name);
	}
    #endif

This is the same issue as in exec.c:exec_file_attach() above, and
should be solved in the same way.

Re: DOS/Windows-specific code: exec.c and symfile.c

[Elena Zannoni]

Eli Zaretskii writes:
 > 
 >     * exec.c:exec_file_attach()
 > 
 > 	  scratch_chan = openp (getenv ("PATH"), 1, filename,
 > 		       write_files ? O_RDWR | O_BINARY : O_RDONLY | O_BINARY, 0,
 > 				&scratch_pathname);
 >     #if defined(__GO32__) || defined(_WIN32) || defined(__CYGWIN__)
 > 	  if (scratch_chan < 0)
 > 	    {
 > 	      char *exename = alloca (strlen (filename) + 5);
 > 	      strcat (strcpy (exename, filename), ".exe");
 > 	      scratch_chan = openp (getenv ("PATH"), 1, exename, write_files ?
 > 		 O_RDWR | O_BINARY : O_RDONLY | O_BINARY, 0, &scratch_pathname);
 > 	    }
 >     #endif
 > 
 > This snippet wants to find `foo.exe' when `foo' is being specified.
 > Should we add a #define for executable extensions (defaulting to an
 > empty string on Unix)?
 > 

This seems like a good candidate for inclusion in filenames.h.

Elena


 > 
 >     * symfile.c:symfile_bfd_open()
 > 
 >       /* Look down path for it, allocate 2nd new malloc'd copy.  */
 >       desc = openp (getenv ("PATH"), 1, name, O_RDONLY | O_BINARY, 0, &absolute_name);
 >     #if defined(__GO32__) || defined(_WIN32)
 >       if (desc < 0)
 > 	{
 > 	  char *exename = alloca (strlen (name) + 5);
 > 	  strcat (strcpy (exename, name), ".exe");
 > 	  desc = openp (getenv ("PATH"), 1, exename, O_RDONLY | O_BINARY,
 > 			0, &absolute_name);
 > 	}
 >     #endif
 > 
 > This is the same issue as in exec.c:exec_file_attach() above, and
 > should be solved in the same way.
 > 

Re: DOS/Windows-specific code: exec.c and symfile.c

[Andrew Cagney]

> This snippet wants to find `foo.exe' when `foo' is being specified.
> Should we add a #define for executable extensions (defaulting to an
> empty string on Unix)?

Hmm, the makefile already knows about EXEEXT.

	Andrew

Re: DOS/Windows-specific code: exec.c and symfile.c

[Eli Zaretskii]

On Tue, 8 May 2001, Andrew Cagney wrote:

> > This snippet wants to find `foo.exe' when `foo' is being specified.
> > Should we add a #define for executable extensions (defaulting to an
> > empty string on Unix)?
> 
> Hmm, the makefile already knows about EXEEXT.

So how about adding `-DEXE_EXT=\"EXEEXT\"' to DEFS, and then testing
EXE_EXT in the sources?

Alternatively, we could modify openp to always accept an additional
parameter, which is an optional extension (or even a list of possible
extensions), and if it's non-empty, try those extensions in addition
to the original file name.  (That's what openp in Emacs does, btw.)

Re: DOS/Windows-specific code: exec.c and symfile.c

[Christopher Faylor]

On Wed, May 09, 2001 at 01:05:49PM +0300, Eli Zaretskii wrote:
>
>On Tue, 8 May 2001, Andrew Cagney wrote:
>
>> > This snippet wants to find `foo.exe' when `foo' is being specified.
>> > Should we add a #define for executable extensions (defaulting to an
>> > empty string on Unix)?
>> 
>> Hmm, the makefile already knows about EXEEXT.
>
>So how about adding `-DEXE_EXT=\"EXEEXT\"' to DEFS, and then testing
>EXE_EXT in the sources?
>
>Alternatively, we could modify openp to always accept an additional
>parameter, which is an optional extension (or even a list of possible
>extensions), and if it's non-empty, try those extensions in addition
>to the original file name.  (That's what openp in Emacs does, btw.)

I like the additional argument idea.  It would be a little less overhead
to search for a .exe file on systems that use them.

cgf

DOS/Windows-specific code: inflow.c

[Eli Zaretskii]

    * inflow.c:new_tty()

    #if !defined(__GO32__) && !defined(_WIN32)
    #ifdef TIOCNOTTY
      /* Disconnect the child process from our controlling terminal.  On some
	 systems (SVR4 for example), this may cause a SIGTTOU, so temporarily
	 ignore SIGTTOU. */
      tty = open ("/dev/tty", O_RDWR);
      if (tty > 0)
	{
	  void (*osigttou) ();

	  osigttou = (void (*)()) signal (SIGTTOU, SIG_IGN);
	  ioctl (tty, TIOCNOTTY, 0);
	  close (tty);
	  signal (SIGTTOU, osigttou);
	}
    #endif

      /* Now open the specified new terminal.  */

    #ifdef USE_O_NOCTTY
      tty = open (inferior_thisrun_terminal, O_RDWR | O_NOCTTY);
    #else
      tty = open (inferior_thisrun_terminal, O_RDWR);
    #endif
      if (tty == -1)
	{
	  print_sys_errmsg (inferior_thisrun_terminal, errno);
	  _exit (1);
	}

This code assumes too many Posix features.  Should we define
NO_NEW_TTY?


    * inflow.c: pass_signal() [and many more functions that call kill()]

    /* ARGSUSED */
    static void
    pass_signal (int signo)
    {
    #ifndef _WIN32
      kill (PIDGET (inferior_pid), SIGINT);
    #endif
    }

I don't really understand why does the Windows build need to ifdef
away the calls to kill.  In any case, it sounds like providing a no-op
version in win32-nat.c would be a better idea.

Re: DOS/Windows-specific code: inflow.c

[Christopher Faylor]

On Tue, May 08, 2001 at 02:45:43PM +0300, Eli Zaretskii wrote:
>
>    * inflow.c:new_tty()
>
>    #if !defined(__GO32__) && !defined(_WIN32)
>    #ifdef TIOCNOTTY
>      /* Disconnect the child process from our controlling terminal.  On some
>	 systems (SVR4 for example), this may cause a SIGTTOU, so temporarily
>	 ignore SIGTTOU. */
>      tty = open ("/dev/tty", O_RDWR);
>      if (tty > 0)
>	{
>	  void (*osigttou) ();
>
>	  osigttou = (void (*)()) signal (SIGTTOU, SIG_IGN);
>	  ioctl (tty, TIOCNOTTY, 0);
>	  close (tty);
>	  signal (SIGTTOU, osigttou);
>	}
>    #endif
>
>      /* Now open the specified new terminal.  */
>
>    #ifdef USE_O_NOCTTY
>      tty = open (inferior_thisrun_terminal, O_RDWR | O_NOCTTY);
>    #else
>      tty = open (inferior_thisrun_terminal, O_RDWR);
>    #endif
>      if (tty == -1)
>	{
>	  print_sys_errmsg (inferior_thisrun_terminal, errno);
>	  _exit (1);
>	}
>
>This code assumes too many Posix features.  Should we define
>NO_NEW_TTY?

Actually, I think something should define O_NOCTTY to 0.

>    * inflow.c: pass_signal() [and many more functions that call kill()]
>
>    /* ARGSUSED */
>    static void
>    pass_signal (int signo)
>    {
>    #ifndef _WIN32
>      kill (PIDGET (inferior_pid), SIGINT);
>    #endif
>    }
>
>I don't really understand why does the Windows build need to ifdef
>away the calls to kill.  In any case, it sounds like providing a no-op
>version in win32-nat.c would be a better idea.

I don't understand it either.  This should work fine on _WIN32.  Maybe
we should just get rid of the #ifndef.

cgf

Re: DOS/Windows-specific code: inflow.c

[Eli Zaretskii]

> Date: Tue, 8 May 2001 10:52:51 -0400
> From: Christopher Faylor <cgf@redhat.com>
> 
> On Tue, May 08, 2001 at 02:45:43PM +0300, Eli Zaretskii wrote:
> >
> >    * inflow.c:new_tty()
> >
> >    #if !defined(__GO32__) && !defined(_WIN32)
> >    #ifdef TIOCNOTTY
> >      /* Disconnect the child process from our controlling terminal.  On some
> >	 systems (SVR4 for example), this may cause a SIGTTOU, so temporarily
> >	 ignore SIGTTOU. */
> >      tty = open ("/dev/tty", O_RDWR);
> >      if (tty > 0)
> >	{
> >	  void (*osigttou) ();
> >
> >	  osigttou = (void (*)()) signal (SIGTTOU, SIG_IGN);
> >	  ioctl (tty, TIOCNOTTY, 0);
> >	  close (tty);
> >	  signal (SIGTTOU, osigttou);
> >	}
> >    #endif
> >
> >      /* Now open the specified new terminal.  */
> >
> >    #ifdef USE_O_NOCTTY
> >      tty = open (inferior_thisrun_terminal, O_RDWR | O_NOCTTY);
> >    #else
> >      tty = open (inferior_thisrun_terminal, O_RDWR);
> >    #endif
> >      if (tty == -1)
> >	{
> >	  print_sys_errmsg (inferior_thisrun_terminal, errno);
> >	  _exit (1);
> >	}
> >
> >This code assumes too many Posix features.  Should we define
> >NO_NEW_TTY?
> 
> Actually, I think something should define O_NOCTTY to 0.

Are you sure it would be enough?  Is inferior_thisrun_terminal defined
on all platforms?

> >    * inflow.c: pass_signal() [and many more functions that call kill()]
> >
> >    /* ARGSUSED */
> >    static void
> >    pass_signal (int signo)
> >    {
> >    #ifndef _WIN32
> >      kill (PIDGET (inferior_pid), SIGINT);
> >    #endif
> >    }
> >
> >I don't really understand why does the Windows build need to ifdef
> >away the calls to kill.  In any case, it sounds like providing a no-op
> >version in win32-nat.c would be a better idea.
> 
> I don't understand it either.  This should work fine on _WIN32.  Maybe
> we should just get rid of the #ifndef.

I'm all for it.

Re: DOS/Windows-specific code: inflow.c

[Christopher Faylor]

On Tue, May 08, 2001 at 09:15:59PM +0300, Eli Zaretskii wrote:
>> >    #ifdef USE_O_NOCTTY
>> >      tty = open (inferior_thisrun_terminal, O_RDWR | O_NOCTTY);
>> >    #else
>> >      tty = open (inferior_thisrun_terminal, O_RDWR);
>> >    #endif
>> >      if (tty == -1)
>> >	{
>> >	  print_sys_errmsg (inferior_thisrun_terminal, errno);
>> >	  _exit (1);
>> >	}
>> >
>> >This code assumes too many Posix features.  Should we define
>> >NO_NEW_TTY?
>> 
>> Actually, I think something should define O_NOCTTY to 0.
>
>Are you sure it would be enough?  Is inferior_thisrun_terminal defined
>on all platforms?

Judging by the ifdef, yes.  It seems like either part of the ifdef
uses inferior_thisrun_terminal.

cgf

DOS/Windows-specific code: main.c

[Eli Zaretskii]

    * main.c:

    #ifdef __CYGWIN__
    #include <windows.h>		/* for MAX_PATH */
    #include <sys/cygwin.h>		/* for cygwin32_conv_to_posix_path */
    #endif

See the next snippet.

    * main.c:captured_main()

      /* Read and execute $HOME/.gdbinit file, if it exists.  This is done
	 *before* all the command line arguments are processed; it sets
	 global parameters, which are independent of what file you are
	 debugging or what directory you are in.  */
    #ifdef __CYGWIN32__
      {
	char *tmp = getenv ("HOME");

	if (tmp != NULL)
	  {
	    homedir = (char *) alloca (MAX_PATH + 1);
	    cygwin32_conv_to_posix_path (tmp, homedir);
	  }
	else
	  homedir = NULL;
      }
    #else
      homedir = getenv ("HOME");
    #endif

What does cygwin32_conv_to_posix_path do?  Does it convert the
drive-letter braindamage to the /cygdrive/d/foo thingy?  If so, why is
that needed?  Doesn't Cygwin support the native Windows file names
with drive letters?

In any case, this could use FILENAME_MAX instead of MAX_PATH, and then
the previous snippet would not need <windows.h>, since stdio.h is
already included by defs.h.

Re: DOS/Windows-specific code: main.c

[Christopher Faylor]

On Tue, May 08, 2001 at 02:48:05PM +0300, Eli Zaretskii wrote:
>
>    * main.c:
>
>    #ifdef __CYGWIN__
>    #include <windows.h>		/* for MAX_PATH */
>    #include <sys/cygwin.h>		/* for cygwin32_conv_to_posix_path */
>    #endif
>
>See the next snippet.
>
>    * main.c:captured_main()
>
>      /* Read and execute $HOME/.gdbinit file, if it exists.  This is done
>	 *before* all the command line arguments are processed; it sets
>	 global parameters, which are independent of what file you are
>	 debugging or what directory you are in.  */
>    #ifdef __CYGWIN32__
>      {
>	char *tmp = getenv ("HOME");
>
>	if (tmp != NULL)
>	  {
>	    homedir = (char *) alloca (MAX_PATH + 1);
>	    cygwin32_conv_to_posix_path (tmp, homedir);
>	  }
>	else
>	  homedir = NULL;
>      }
>    #else
>      homedir = getenv ("HOME");
>    #endif
>
>What does cygwin32_conv_to_posix_path do?  Does it convert the
>drive-letter braindamage to the /cygdrive/d/foo thingy?

Yes.

>If so, why is that needed?  Doesn't Cygwin support the native Windows
>file names with drive letters?

Actually CYGWIN converts the HOME environment variable to "posix" format
well before the code ever reaches here.  I believe that this code is
to accomodate gdbtk which might change the environment variable back
to MS-DOS format explicitly.  I remember trying to get rid of this
years ago.  Keith Seitz told me that I couldn't do that.

Maybe the solution is to create a "gethome ()" function which is either
a macro or a call to a function in win32-nat.c?

Or, maybe this isn't needed anymore.  Keith do you remember this?  I
think it may have been the first piece of email we ever exchanged.

>In any case, this could use FILENAME_MAX instead of MAX_PATH, and then
>the previous snippet would not need <windows.h>, since stdio.h is
>already included by defs.h.

Yep.

cgf

Re: DOS/Windows-specific code: main.c

[Keith Seitz]

On Tue, 8 May 2001, Christopher Faylor wrote:

> >If so, why is that needed?  Doesn't Cygwin support the native Windows
> >file names with drive letters?
>
> Actually CYGWIN converts the HOME environment variable to "posix" format
> well before the code ever reaches here.  I believe that this code is
> to accomodate gdbtk which might change the environment variable back
> to MS-DOS format explicitly.  I remember trying to get rid of this
> years ago.  Keith Seitz told me that I couldn't do that.

As I recall, HOME used to be set to a windows stye path. We certainly do
not set HOME anywhere. In fact, I see that in several places in gdbtk, we
*explicitly* convert HOME to cygwin/posix path from Windows-style path.

> Or, maybe this isn't needed anymore.  Keith do you remember this?  I
> think it may have been the first piece of email we ever exchanged.

We also used to get NULL from getenv when you do not start it up from a
shell (i.e, you double-click the icon). Perhaps all of this has changed
(for the better) now. I don't think this was gdbtk-specific. It was a
problem looking for gdb.ini on windows.

If cygwin dll _always_ sets HOME (as you imply), then we should be able to
just get rid of all of this. Just need to verify that ~/gdb.ini is found
and loaded on windows (both with a shell and without).

Keith

Re: DOS/Windows-specific code: main.c

[Christopher Faylor]

On Tue, May 08, 2001 at 08:16:20AM -0700, Keith Seitz wrote:
>On Tue, 8 May 2001, Christopher Faylor wrote:
>
>> >If so, why is that needed?  Doesn't Cygwin support the native Windows
>> >file names with drive letters?
>>
>> Actually CYGWIN converts the HOME environment variable to "posix" format
>> well before the code ever reaches here.  I believe that this code is
>> to accomodate gdbtk which might change the environment variable back
>> to MS-DOS format explicitly.  I remember trying to get rid of this
>> years ago.  Keith Seitz told me that I couldn't do that.
>
>As I recall, HOME used to be set to a windows stye path. We certainly do
>not set HOME anywhere. In fact, I see that in several places in gdbtk, we
>*explicitly* convert HOME to cygwin/posix path from Windows-style path.
>
>> Or, maybe this isn't needed anymore.  Keith do you remember this?  I
>> think it may have been the first piece of email we ever exchanged.
>
>We also used to get NULL from getenv when you do not start it up from a
>shell (i.e, you double-click the icon). Perhaps all of this has changed
>(for the better) now. I don't think this was gdbtk-specific. It was a
>problem looking for gdb.ini on windows.
>
>If cygwin dll _always_ sets HOME (as you imply), then we should be able to
>just get rid of all of this. Just need to verify that ~/gdb.ini is found
>and loaded on windows (both with a shell and without).

The DLL doesn't always set HOME.  I think it always expects it to be
inherited from the environment.  We could change this, thouhh, now that
I think of it.

So, it sounds like this code isn't needed.  I'll try deleting it and
building a cygwin version of gdb.

cgf

DOS/Windows-specific code: maint.c

[Eli Zaretskii]

    * maint.c:

    #ifndef _WIN32
    /* ARGSUSED */
    static void
    maintenance_dump_me (char *args, int from_tty)
    {
      if (query ("Should GDB dump core? "))
	{
    #ifdef __DJGPP__
	  /* SIGQUIT by default is ignored, so use SIGABRT instead.  */
	  signal (SIGABRT, SIG_DFL);
	  kill (getpid (), SIGABRT);
    #else
	  signal (SIGQUIT, SIG_DFL);
	  kill (getpid (), SIGQUIT);
    #endif
	}
    }
    #endif

Should we define SIGNAL_TO_DUMP_CORE (default to SIGQUIT)?  It could
then be set to 0 on Windows, and maintenance_dump_me could print a
suitable message ("not supported on this platform" or some such) if
its value is zero.

Btw, why isn't SIGABRT used on Unix here?

    * maint.c:_initialize_maint_cmds()

    #ifndef _WIN32
      add_cmd ("dump-me", class_maintenance, maintenance_dump_me,
	       "Get fatal error; make debugger dump its core.\n\
    GDB sets it's handling of SIGQUIT back to SIG_DFL and then sends\n\
    itself a SIGQUIT signal.",
	       &maintenancelist);
    #endif

See above.  If the changes I suggest are accepted, the ifdef here
could be simply removed.

Re: DOS/Windows-specific code: maint.c

[Kevin Buettner]

On May 8,  2:48pm, Eli Zaretskii wrote:

>     * maint.c:
> 
>     #ifndef _WIN32
>     /* ARGSUSED */
>     static void
>     maintenance_dump_me (char *args, int from_tty)
>     {
>       if (query ("Should GDB dump core? "))
> 	{
>     #ifdef __DJGPP__
> 	  /* SIGQUIT by default is ignored, so use SIGABRT instead.  */
> 	  signal (SIGABRT, SIG_DFL);
> 	  kill (getpid (), SIGABRT);
>     #else
> 	  signal (SIGQUIT, SIG_DFL);
> 	  kill (getpid (), SIGQUIT);
>     #endif
> 	}
>     }
>     #endif
> 
> Should we define SIGNAL_TO_DUMP_CORE (default to SIGQUIT)?  It could
> then be set to 0 on Windows, and maintenance_dump_me could print a
> suitable message ("not supported on this platform" or some such) if
> its value is zero.
>
> Btw, why isn't SIGABRT used on Unix here?

I don't know.  SIGABRT seems like a better (more portable) choice.

With that in mind, why not do the following:

    /* ARGSUSED */
    static void
    maintenance_dump_me (char *args, int from_tty)
    {
      if (query ("Should GDB dump core? "))
        {
    #ifdef SIGABRT
          signal (SIGABRT, SIG_DFL);
          kill (getpid (), SIGABRT);
    #else
          error ("Not supported on this platform.");
    #endif
        }
    }

Note that the _WIN32 ifdef has been removed so that
maintenance_dump_me() will always be defined.

If, for some reason, the above won't work, I think your
SIGNAL_TO_DUMP_CORE suggestion is okay too.

Kevin

Re: DOS/Windows-specific code: maint.c

[Eli Zaretskii]

On Tue, 8 May 2001, Kevin Buettner wrote:

> I don't know.  SIGABRT seems like a better (more portable) choice.
> 
> With that in mind, why not do the following:
> 
>     /* ARGSUSED */
>     static void
>     maintenance_dump_me (char *args, int from_tty)
>     {
>       if (query ("Should GDB dump core? "))
>         {
>     #ifdef SIGABRT
>           signal (SIGABRT, SIG_DFL);
>           kill (getpid (), SIGABRT);
>     #else
>           error ("Not supported on this platform.");
>     #endif
>         }
>     }
> 
> Note that the _WIN32 ifdef has been removed so that
> maintenance_dump_me() will always be defined.

Yes, that looks good to me.

Re: DOS/Windows-specific code: maint.c

[Andrew Cagney]

>  #ifndef _WIN32
>     /* ARGSUSED */
>     static void
>     maintenance_dump_me (char *args, int from_tty)
>     {
>       if (query ("Should GDB dump core? "))
> 	{
>     #ifdef __DJGPP__
> 	  /* SIGQUIT by default is ignored, so use SIGABRT instead.  */
> 	  signal (SIGABRT, SIG_DFL);
> 	  kill (getpid (), SIGABRT);
>     #else
> 	  signal (SIGQUIT, SIG_DFL);
> 	  kill (getpid (), SIGQUIT);
>     #endif
> 	}
>     }
>     #endif

I think this is a bug in DJGPP :-)

On unix, your program gets a SIGQUIT when you type ^\ and it is

expected to dump core.  SIGABRT is what you get when abort() is
called.

The other option is to just call abort() is that always guarenteed to 
dump core?

	Andrew

Re: DOS/Windows-specific code: maint.c

[Eli Zaretskii]

On Wed, 9 May 2001, Andrew Cagney wrote:

> >     #ifdef __DJGPP__
> > 	  /* SIGQUIT by default is ignored, so use SIGABRT instead.  */
> > 	  signal (SIGABRT, SIG_DFL);
> > 	  kill (getpid (), SIGABRT);
> >     #else
> > 	  signal (SIGQUIT, SIG_DFL);
> > 	  kill (getpid (), SIGQUIT);
> >     #endif
> > 	}
> >     }
> >     #endif
> 
> I think this is a bug in DJGPP :-)

No, it's a feature ;-)  DOS/Windows users do not expect a ^\ to abort 
their program, so by default SIGQUIT is ignored.

If you want to stay with SIGQUIT, I can do something in go32-nat.c to get 
the standard Unix behavior.  However, note that there's also the _WIN32 
condition which ifdefs away the whole function.

> The other option is to just call abort() is that always guarenteed to 
> dump core?

That's what I thought; abort() sounds like a more portable way of dumping 
core where core files are supported and doing something similar where 
they aren't.

DOS/Windows-specific code: source.c

[Eli Zaretskii]

    * source.c:openp()

    #ifdef _WIN32
      mode |= O_BINARY;
    #endif

I think this is obsolete and should be removed: defining
CRLF_SOURCE_FILES in xm-whatever should solve the underlying problem.

For those who don't know: the problem here is that find_source_lines
creates a table which records the byte position of each line in a
source file, but many DOS/Windows libraries don't DTRT with byte
offsets unless the file is open in binary mode.  So this issue is
limited to source files, and CRLF_SOURCE_FILES should provide the
solution there for Windows systems.

(Code which wants to open binary files, like in exec.c, already uses
O_BINARY when it calls openp.  Hmm, perhaps solib.c should be fixed to
use O_BINARY when it looks for the libraries.)

Re: DOS/Windows-specific code: source.c

[DJ Delorie]

Eli Zaretskii <eliz@is.elta.co.il> writes:

>     * source.c:openp()
> 
>     #ifdef _WIN32
>       mode |= O_BINARY;
>     #endif
> 
> I think this is obsolete and should be removed: defining
> CRLF_SOURCE_FILES in xm-whatever should solve the underlying problem.

What I do is this:

#ifndef O_BINARY
#define O_BINARY 0
#endif

Put that somewhere global, and then *always* use O_BINARY and don't
worry about it.

Re: DOS/Windows-specific code: source.c

[Christopher Faylor]

On Tue, May 08, 2001 at 12:22:22PM -0400, DJ Delorie wrote:
>Eli Zaretskii <eliz@is.elta.co.il> writes:
>>     * source.c:openp()
>> 
>>     #ifdef _WIN32
>>       mode |= O_BINARY;
>>     #endif
>> 
>>I think this is obsolete and should be removed: defining
>>CRLF_SOURCE_FILES in xm-whatever should solve the underlying problem.
>
>What I do is this:
>
>#ifndef O_BINARY
>#define O_BINARY 0
>#endif
>
>Put that somewhere global, and then *always* use O_BINARY and don't
>worry about it.

gdb does this, too.  It does it in too many (7) places, though.
Shouldn't this be in a header file (defs.h?) somewhere?

cgf

Re: DOS/Windows-specific code: source.c

[Eli Zaretskii]

> Date: Tue, 8 May 2001 14:16:19 -0400
> From: Christopher Faylor <cgf@redhat.com>
> 
> On Tue, May 08, 2001 at 12:22:22PM -0400, DJ Delorie wrote:
> >Eli Zaretskii <eliz@is.elta.co.il> writes:
> >>     * source.c:openp()
> >> 
> >>     #ifdef _WIN32
> >>       mode |= O_BINARY;
> >>     #endif
> >> 
> >>I think this is obsolete and should be removed: defining
> >>CRLF_SOURCE_FILES in xm-whatever should solve the underlying problem.
> >
> >What I do is this:
> >
> >#ifndef O_BINARY
> >#define O_BINARY 0
> >#endif
> >
> >Put that somewhere global, and then *always* use O_BINARY and don't
> >worry about it.
> 
> gdb does this, too.  It does it in too many (7) places, though.
> Shouldn't this be in a header file (defs.h?) somewhere?

Perhaps, but this is not the problem I was trying to solve.  The issue
is whether _any_ platform needs to put O_BINARY into mode in this
case.  Platforms which define O_BINARY to zero don't need to bother
about this, but Windows certainly has a non-zero O_BINARY.

Re: DOS/Windows-specific code: source.c

[DJ Delorie]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> Perhaps, but this is not the problem I was trying to solve.  The issue
> is whether _any_ platform needs to put O_BINARY into mode in this

If it's host-specific code, perhaps.  But it's better if nobody needs
to know whether or not O_BINARY is available; they only need to know
if it's *appropriate*.  If the file is binary, use O_BINARY.  If it is
text, don't.  On platforms where O_BINARY is zero, it does nothing,
but does prevent yet another needless host test.

Re: DOS/Windows-specific code: source.c

[Eli Zaretskii]

On 8 May 2001, DJ Delorie wrote:

> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > Perhaps, but this is not the problem I was trying to solve.  The issue
> > is whether _any_ platform needs to put O_BINARY into mode in this
> 
> If it's host-specific code, perhaps.  But it's better if nobody needs
> to know whether or not O_BINARY is available; they only need to know
> if it's *appropriate*.  If the file is binary, use O_BINARY.  If it is
> text, don't.

This is what GDB does already.  This specific case is special because
_WIN32 build wanted to read text files with O_BINARY, due to the
problems with using byte offsets to record where each line begins.

I suggest removing that snippet, because CRLF_SOURCE_FILES already
solves the same problem in a more elegant way.  The DJGPP port uses
that since at least GDB 4.18, so native Windows ports should also be
happy with it.

Re: DOS/Windows-specific code: source.c

[Christopher Faylor]

On Wed, May 09, 2001 at 01:07:39PM +0300, Eli Zaretskii wrote:
>
>On 8 May 2001, DJ Delorie wrote:
>
>> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
>> > Perhaps, but this is not the problem I was trying to solve.  The issue
>> > is whether _any_ platform needs to put O_BINARY into mode in this
>> 
>> If it's host-specific code, perhaps.  But it's better if nobody needs
>> to know whether or not O_BINARY is available; they only need to know
>> if it's *appropriate*.  If the file is binary, use O_BINARY.  If it is
>> text, don't.
>
>This is what GDB does already.  This specific case is special because
>_WIN32 build wanted to read text files with O_BINARY, due to the
>problems with using byte offsets to record where each line begins.
>
>I suggest removing that snippet, because CRLF_SOURCE_FILES already
>solves the same problem in a more elegant way.  The DJGPP port uses
>that since at least GDB 4.18, so native Windows ports should also be
>happy with it.

Sounds ok to me.

cgf

Re: DOS/Windows-specific code: source.c

[Christopher Faylor]

On Tue, May 08, 2001 at 02:49:19PM +0300, Eli Zaretskii wrote:
>
>    * source.c:openp()
>
>    #ifdef _WIN32
>      mode |= O_BINARY;
>    #endif
>
>I think this is obsolete and should be removed: defining
>CRLF_SOURCE_FILES in xm-whatever should solve the underlying problem.
>
>For those who don't know: the problem here is that find_source_lines
>creates a table which records the byte position of each line in a
>source file, but many DOS/Windows libraries don't DTRT with byte
>offsets unless the file is open in binary mode.  So this issue is
>limited to source files, and CRLF_SOURCE_FILES should provide the
>solution there for Windows systems.
>
>(Code which wants to open binary files, like in exec.c, already uses
>O_BINARY when it calls openp.  Hmm, perhaps solib.c should be fixed to
>use O_BINARY when it looks for the libraries.)

Actually, why not always just use O_BINARY in this file without the
conditional and remove the use of O_BINARY everywhere else?

cgf

Re: DOS/Windows-specific code: source.c

[Eli Zaretskii]

> Date: Tue, 8 May 2001 14:12:46 -0400
> From: Christopher Faylor <cgf@redhat.com>
> 
> On Tue, May 08, 2001 at 02:49:19PM +0300, Eli Zaretskii wrote:
> >
> >    * source.c:openp()
> >
> >    #ifdef _WIN32
> >      mode |= O_BINARY;
> >    #endif
> >
> >I think this is obsolete and should be removed: defining
> >CRLF_SOURCE_FILES in xm-whatever should solve the underlying problem.
> >
> >For those who don't know: the problem here is that find_source_lines
> >creates a table which records the byte position of each line in a
> >source file, but many DOS/Windows libraries don't DTRT with byte
> >offsets unless the file is open in binary mode.  So this issue is
> >limited to source files, and CRLF_SOURCE_FILES should provide the
> >solution there for Windows systems.
> >
> >(Code which wants to open binary files, like in exec.c, already uses
> >O_BINARY when it calls openp.  Hmm, perhaps solib.c should be fixed to
> >use O_BINARY when it looks for the libraries.)
> 
> Actually, why not always just use O_BINARY in this file without the
> conditional and remove the use of O_BINARY everywhere else?

Because it's wrong to read source files in binary mode.

This function is used for opening all kinds of files that GDB needs to
search for.  That includes binaries, libraries, and sources.  You
don't want to see those pesky ^M characters and the trailing ^Z when
ou list the source file inside GDB.

Re: DOS/Windows-specific code: source.c

[Christopher Faylor]

On Tue, May 08, 2001 at 10:26:05PM +0300, Eli Zaretskii wrote:
>> Date: Tue, 8 May 2001 14:12:46 -0400
>> From: Christopher Faylor <cgf@redhat.com>
>> 
>> On Tue, May 08, 2001 at 02:49:19PM +0300, Eli Zaretskii wrote:
>> >
>> >    * source.c:openp()
>> >
>> >    #ifdef _WIN32
>> >      mode |= O_BINARY;
>> >    #endif
>> >
>> >I think this is obsolete and should be removed: defining
>> >CRLF_SOURCE_FILES in xm-whatever should solve the underlying problem.
>> >
>> >For those who don't know: the problem here is that find_source_lines
>> >creates a table which records the byte position of each line in a
>> >source file, but many DOS/Windows libraries don't DTRT with byte
>> >offsets unless the file is open in binary mode.  So this issue is
>> >limited to source files, and CRLF_SOURCE_FILES should provide the
>> >solution there for Windows systems.
>> >
>> >(Code which wants to open binary files, like in exec.c, already uses
>> >O_BINARY when it calls openp.  Hmm, perhaps solib.c should be fixed to
>> >use O_BINARY when it looks for the libraries.)
>> 
>> Actually, why not always just use O_BINARY in this file without the
>> conditional and remove the use of O_BINARY everywhere else?
>
>Because it's wrong to read source files in binary mode.

Not necessarily.  If you are storing CTRL-Zs in the source file, it might
make sense on MS-DOS and Windows.

cgf

Re: DOS/Windows-specific code: source.c

[Eli Zaretskii]

On Tue, 8 May 2001, Christopher Faylor wrote:

> >> Actually, why not always just use O_BINARY in this file without the
> >> conditional and remove the use of O_BINARY everywhere else?
> >
> >Because it's wrong to read source files in binary mode.
> 
> Not necessarily.  If you are storing CTRL-Zs in the source file, it might
> make sense on MS-DOS and Windows.

You can't in practice store ^Z in a text file on DOS/Windows, because
95% of text editors on those systems will stop reading the file when
they see the first ^Z.  Unless you can force everybody to use either
Emacs or Cygwin-compiled editors, you can safely assume any ^Z
character in a text file marks the end of the file, and should not be
displayed.

DOS/Windows-specific code: sparcl-tdep.c

[Eli Zaretskii]

    * sparcl-tdep.c:

    #if (!defined(__GO32__) && !defined(_WIN32)) || defined(__CYGWIN32__)
    #define HAVE_SOCKETS
    #include <sys/time.h>
    #include <sys/socket.h>
    #include <netinet/in.h>
    #include <netdb.h>
    #endif

Looks like an Autoconf test for HAVE_SOCKETS should do here.

Re: DOS/Windows-specific code: sparcl-tdep.c

[Kevin Buettner]

On May 8,  2:49pm, Eli Zaretskii wrote:

>     * sparcl-tdep.c:
> 
>     #if (!defined(__GO32__) && !defined(_WIN32)) || defined(__CYGWIN32__)
>     #define HAVE_SOCKETS
>     #include <sys/time.h>
>     #include <sys/socket.h>
>     #include <netinet/in.h>
>     #include <netdb.h>
>     #endif
> 
> Looks like an Autoconf test for HAVE_SOCKETS should do here.

Why not just add an autoconf test for the sys/socket.h header file and
then do:

    #ifdef HAVE_SYS_SOCKET_H
    #define HAVE_SOCKETS
    #include <sys/time.h>
    #include <sys/socket.h>
    #include <netinet/in.h>
    #include <netdb.h>
    #endif

?

(If you wanted to be paranoid you could test for some of the other
header files as well.)

Kevin

Re: DOS/Windows-specific code: sparcl-tdep.c

[Eli Zaretskii]

On Tue, 8 May 2001, Kevin Buettner wrote:

> On May 8,  2:49pm, Eli Zaretskii wrote:
> 
> >     * sparcl-tdep.c:
> > 
> >     #if (!defined(__GO32__) && !defined(_WIN32)) || defined(__CYGWIN32__)
> >     #define HAVE_SOCKETS
> >     #include <sys/time.h>
> >     #include <sys/socket.h>
> >     #include <netinet/in.h>
> >     #include <netdb.h>
> >     #endif
> > 
> > Looks like an Autoconf test for HAVE_SOCKETS should do here.
> 
> Why not just add an autoconf test for the sys/socket.h header file and
> then do:
> 
>     #ifdef HAVE_SYS_SOCKET_H
>     #define HAVE_SOCKETS
>     #include <sys/time.h>
>     #include <sys/socket.h>
>     #include <netinet/in.h>
>     #include <netdb.h>
>     #endif

Yes, that would be good, I think.

> (If you wanted to be paranoid you could test for some of the other
> header files as well.)

I think sys/sockets.h test should be enough.

Re: DOS/Windows-specific code: sparcl-tdep.c

[Andrew Cagney]

> On May 8,  2:49pm, Eli Zaretskii wrote:
> 
> 
>> * sparcl-tdep.c:
>> 
>> #if (!defined(__GO32__) && !defined(_WIN32)) || defined(__CYGWIN32__)
>> #define HAVE_SOCKETS
>> #include <sys/time.h>
>> #include <sys/socket.h>
>> #include <netinet/in.h>
>> #include <netdb.h>
>> #endif
>> 
>> Looks like an Autoconf test for HAVE_SOCKETS should do here.
> 
> 
> Why not just add an autoconf test for the sys/socket.h header file and
> then do:
> 
>     #ifdef HAVE_SYS_SOCKET_H
>     #define HAVE_SOCKETS
>     #include <sys/time.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> #include <netdb.h>
> #endif

I'm actually wondering why a *-tdep.c file is even playing around with 
sockets!  Normally that code appears in *-rom.c or *-mon.c files.  One 
interesting thing, the code uses UDP so, for ser*.c to ever replace it, 
the ser*.c code would need to gain UDP support.

Anyway, Kevin's suggestion should do the trick.


	Andrew

DOS/Windows-specific code: terminal.h

[Eli Zaretskii]

    * terminal.h:

    #if !defined(_WIN32) && !defined (HAVE_TERMIOS)

    /* Define a common set of macros -- BSD based -- and redefine whatever
       the system offers to make it look like that.  FIXME: serial.h and
       ser-*.c deal with this in a much cleaner fashion; as soon as stuff
       is converted to use them, can get rid of this crap.  */

    #ifdef HAVE_TERMIO

Do _WIN32 platforms define HAVE_TERMIO or HAVE_TERMIOS?  If not,
testing for _WIN32 is redundant, I think.

Re: DOS/Windows-specific code: terminal.h

[Christopher Faylor]

On Tue, May 08, 2001 at 02:50:43PM +0300, Eli Zaretskii wrote:
>
>    * terminal.h:
>
>    #if !defined(_WIN32) && !defined (HAVE_TERMIOS)
>
>    /* Define a common set of macros -- BSD based -- and redefine whatever
>       the system offers to make it look like that.  FIXME: serial.h and
>       ser-*.c deal with this in a much cleaner fashion; as soon as stuff
>       is converted to use them, can get rid of this crap.  */
>
>    #ifdef HAVE_TERMIO
>
>Do _WIN32 platforms define HAVE_TERMIO or HAVE_TERMIOS?  If not,
>testing for _WIN32 is redundant, I think.

Yes.  I agree.

cgf

DOS/Windows-specific code: top.c

[Eli Zaretskii]

    * top.c:

    #ifdef __MSDOS__
    void
    do_chdir_cleanup (void *old_dir)
    {
      chdir (old_dir);
      xfree (old_dir);
    }
    #endif

See the next snippet.

    * top.c:gdb_init()
    
    #ifdef __MSDOS__
      /* Make sure we return to the original directory upon exit, come
	 what may, since the OS doesn't do that for us.  */
      make_final_cleanup (do_chdir_cleanup, xstrdup (current_directory));
    #endif

This is the same issue as with cli-cmds.c:shell_escape(), and the same
solution will do here.


    * top.c:init_history()

    #ifdef __MSDOS__
	  /* No leading dots in file names are allowed on MSDOS.  */
	  history_filename = concat (current_directory, "/_gdb_history", NULL);
    #else
	  history_filename = concat (current_directory, "/.gdb_history", NULL);
    #endif
`

Should we have a NO_LEADING_DOTS_IN_FILENAMES macro?

Re: DOS/Windows-specific code: top.c

[Elena Zannoni]

Eli Zaretskii writes:
 > 
 >     * top.c:
 > 
 >     #ifdef __MSDOS__
 >     void
 >     do_chdir_cleanup (void *old_dir)
 >     {
 >       chdir (old_dir);
 >       xfree (old_dir);
 >     }
 >     #endif
 > 
 > See the next snippet.
 > 
 >     * top.c:gdb_init()
 >     
 >     #ifdef __MSDOS__
 >       /* Make sure we return to the original directory upon exit, come
 > 	 what may, since the OS doesn't do that for us.  */
 >       make_final_cleanup (do_chdir_cleanup, xstrdup (current_directory));
 >     #endif
 > 
 > This is the same issue as with cli-cmds.c:shell_escape(), and the same
 > solution will do here.
 > 
 > 
 >     * top.c:init_history()
 > 
 >     #ifdef __MSDOS__
 > 	  /* No leading dots in file names are allowed on MSDOS.  */
 > 	  history_filename = concat (current_directory, "/_gdb_history", NULL);
 >     #else
 > 	  history_filename = concat (current_directory, "/.gdb_history", NULL);
 >     #endif
 > `
 > 
 > Should we have a NO_LEADING_DOTS_IN_FILENAMES macro?
 > 

I am not familiar with the first issue. But the second one seems to
also be OK for filenames.h.

Elena

DOS/Windows-specific code: utils.c

[Eli Zaretskii]

    * utils.c:

    #ifdef __GO32__
    #include <pc.h>
    #endif

See the next snippet.

    * utils.c:init_page_info()

	  /* These defaults will be used if we are unable to get the correct
	     values from termcap.  */
    #if defined(__GO32__)
	  lines_per_page = ScreenRows ();
	  chars_per_line = ScreenCols ();
    #else
	  lines_per_page = 24;
	  chars_per_line = 80;

    [...]

    #if !defined (MPW) && !defined (_WIN32)
	  /* No termcap under MPW, although might be cool to do something
	     by looking at worksheet or console window sizes. */
	  /* Initialize the screen height and width from termcap.  */
	  {
	    char *termtype = getenv ("TERM");

Looks like using HAVE_TERMCAP (default to 1, 0 on Windows and DJGPP),
and allowing for a GET_SCREEN_SIZE macro which would return the screen
dimensions, should solve this.  Comments?


    * utils.c:quit()

    #ifdef __MSDOS__
      /* No steenking SIGINT will ever be coming our way when the
	 program is resumed.  Don't lie.  */
      fprintf_unfiltered (gdb_stderr, "Quit\n");
    #else
      if (job_control
      /* If there is no terminal switching for this target, then we can't
	 possibly get screwed by the lack of job control.  */
	  || current_target.to_terminal_ours == NULL)
	fprintf_unfiltered (gdb_stderr, "Quit\n");
      else
	fprintf_unfiltered (gdb_stderr,
		   "Quit (expect signal SIGINT when the program is resumed)\n");
    #endif

I'm not sure we should bother about this one.


    * utils.c:

    #if defined(_MSC_VER)		/* should test for wingdb instead? */

    /*
     * Windows translates all keyboard and mouse events 
     * into a message which is appended to the message 
     * queue for the process.
     */

    void
    notice_quit (void)
    {
      int k = win32pollquit ();
      if (k == 1)
	quit_flag = 1;
      else if (k == 2)
	immediate_quit = 1;
    }

I think this should go to win32-nat.c.

Re: DOS/Windows-specific code: utils.c

[Christopher Faylor]

On Tue, May 08, 2001 at 02:53:33PM +0300, Eli Zaretskii wrote:
>    #if !defined (MPW) && !defined (_WIN32)
>	  /* No termcap under MPW, although might be cool to do something
>	     by looking at worksheet or console window sizes. */
>	  /* Initialize the screen height and width from termcap.  */
>	  {
>	    char *termtype = getenv ("TERM");
>
>Looks like using HAVE_TERMCAP (default to 1, 0 on Windows and DJGPP),
>and allowing for a GET_SCREEN_SIZE macro which would return the screen
>dimensions, should solve this.  Comments?

Yep.

>
>    * utils.c:quit()
>
>    #ifdef __MSDOS__
>      /* No steenking SIGINT will ever be coming our way when the
>	 program is resumed.  Don't lie.  */
>      fprintf_unfiltered (gdb_stderr, "Quit\n");
>    #else
>      if (job_control
>      /* If there is no terminal switching for this target, then we can't
>	 possibly get screwed by the lack of job control.  */
>	  || current_target.to_terminal_ours == NULL)
>	fprintf_unfiltered (gdb_stderr, "Quit\n");
>      else
>	fprintf_unfiltered (gdb_stderr,
>		   "Quit (expect signal SIGINT when the program is resumed)\n");
>    #endif
>
>I'm not sure we should bother about this one.
>
>
>    * utils.c:
>
>    #if defined(_MSC_VER)		/* should test for wingdb instead? */
>
>    /*
>     * Windows translates all keyboard and mouse events 
>     * into a message which is appended to the message 
>     * queue for the process.
>     */
>
>    void
>    notice_quit (void)
>    {
>      int k = win32pollquit ();
>      if (k == 1)
>	quit_flag = 1;
>      else if (k == 2)
>	immediate_quit = 1;
>    }
>
>I think this should go to win32-nat.c.

Actually, it should be nuked.  This is wingdb code.  I'll do that right now.

cgf

DOS/Windows-specific code: sh-tdep.c and sh3-rom.c

[Eli Zaretskii]

    * sh-tdep.c:

    #if 0
    #ifdef _WIN32_WCE
    char **sh_register_names = sh3_reg_names;
    #else
    char **sh_register_names = sh_generic_reg_names;
    #endif
    #endif

It seems we could simply remove this, since it's disabled anyway.


    * sh3-rom.c:_initialize_sh3_rom()

    #ifdef _WINDOWS
      /* On windows we can talk through the parallel port too. */
	"Debug on a Hitachi eval board running the SH-3 rom monitor.\n"
	"Specify the serial device it is connected to (e.g. com2).\n"
	"If you want to use the parallel port to download to it, specify that\n"
	"as the second argument. (e.g. lpt1)";
    #else
	"Debug on a Hitachi eval board running the SH-3 rom monitor.\n\
    Specify the serial device it is connected to (e.g. /dev/ttya).";
    #endif

It should be good enough to have a single string here which would tell
that parallel port is only available on Windows.

Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c

[Elena Zannoni]

Eli Zaretskii writes:
 > 
 >     * sh-tdep.c:
 > 
 >     #if 0
 >     #ifdef _WIN32_WCE
 >     char **sh_register_names = sh3_reg_names;
 >     #else
 >     char **sh_register_names = sh_generic_reg_names;
 >     #endif
 >     #endif
 > 
 > It seems we could simply remove this, since it's disabled anyway.
 > 

Ah, yes. Chris wrote that, and I disabled it when I multiarched the
sh. Maybe it can be done now in a different way.

 > 
 >     * sh3-rom.c:_initialize_sh3_rom()
 > 
 >     #ifdef _WINDOWS
 >       /* On windows we can talk through the parallel port too. */
 > 	"Debug on a Hitachi eval board running the SH-3 rom monitor.\n"
 > 	"Specify the serial device it is connected to (e.g. com2).\n"
 > 	"If you want to use the parallel port to download to it, specify that\n"
 > 	"as the second argument. (e.g. lpt1)";
 >     #else
 > 	"Debug on a Hitachi eval board running the SH-3 rom monitor.\n\
 >     Specify the serial device it is connected to (e.g. /dev/ttya).";
 >     #endif
 > 
 > It should be good enough to have a single string here which would tell
 > that parallel port is only available on Windows.
 > 

Yes, that looks like the simplest solution.

Elena

Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c

[Eli Zaretskii]

> From: Elena Zannoni <ezannoni@cygnus.com>
> Date: Tue, 8 May 2001 10:49:02 -0400
> 
> Eli Zaretskii writes:
>  > 
>  >     * sh-tdep.c:
>  > 
>  >     #if 0
>  >     #ifdef _WIN32_WCE
>  >     char **sh_register_names = sh3_reg_names;
>  >     #else
>  >     char **sh_register_names = sh_generic_reg_names;
>  >     #endif
>  >     #endif
>  > 
>  > It seems we could simply remove this, since it's disabled anyway.
>  > 
> 
> Ah, yes. Chris wrote that, and I disabled it when I multiarched the
> sh. Maybe it can be done now in a different way.

Do I understand correctly that this can be removed?

>  >     * sh3-rom.c:_initialize_sh3_rom()
>  > 
>  >     #ifdef _WINDOWS
>  >       /* On windows we can talk through the parallel port too. */
>  > 	"Debug on a Hitachi eval board running the SH-3 rom monitor.\n"
>  > 	"Specify the serial device it is connected to (e.g. com2).\n"
>  > 	"If you want to use the parallel port to download to it, specify that\n"
>  > 	"as the second argument. (e.g. lpt1)";
>  >     #else
>  > 	"Debug on a Hitachi eval board running the SH-3 rom monitor.\n\
>  >     Specify the serial device it is connected to (e.g. /dev/ttya).";
>  >     #endif
>  > 
>  > It should be good enough to have a single string here which would tell
>  > that parallel port is only available on Windows.
> 
> Yes, that looks like the simplest solution.

Thanks, will do.

Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c

[Elena Zannoni]

Eli Zaretskii writes:
 > > From: Elena Zannoni <ezannoni@cygnus.com>
 > > Date: Tue, 8 May 2001 10:49:02 -0400
 > > 
 > > Eli Zaretskii writes:
 > >  > 
 > >  >     * sh-tdep.c:
 > >  > 
 > >  >     #if 0
 > >  >     #ifdef _WIN32_WCE
 > >  >     char **sh_register_names = sh3_reg_names;
 > >  >     #else
 > >  >     char **sh_register_names = sh_generic_reg_names;
 > >  >     #endif
 > >  >     #endif
 > >  > 
 > >  > It seems we could simply remove this, since it's disabled anyway.
 > >  > 
 > > 
 > > Ah, yes. Chris wrote that, and I disabled it when I multiarched the
 > > sh. Maybe it can be done now in a different way.
 > 
 > Do I understand correctly that this can be removed?
 > 

Don't know. I see it comes from config/mips/wince.mt, config/arm/wince.mt,
and config/sh/wince.mt

The arm and mips definitions seem superfluous, because its only use is
in sh-tdep.c, so I would eliminate those, it should have no effect.

Am not sure if the sh wince target (or any of the wince targets) is
still alive.

Elena

Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c

[Christopher Faylor]

On Tue, May 08, 2001 at 02:40:22PM -0400, Elena Zannoni wrote:
>Eli Zaretskii writes:
> > > From: Elena Zannoni <ezannoni@cygnus.com>
> > > Date: Tue, 8 May 2001 10:49:02 -0400
> > > 
> > > Eli Zaretskii writes:
> > >  > 
> > >  >     * sh-tdep.c:
> > >  > 
> > >  >     #if 0
> > >  >     #ifdef _WIN32_WCE
> > >  >     char **sh_register_names = sh3_reg_names;
> > >  >     #else
> > >  >     char **sh_register_names = sh_generic_reg_names;
> > >  >     #endif
> > >  >     #endif
> > >  > 
> > >  > It seems we could simply remove this, since it's disabled anyway.
> > >  > 
> > > 
> > > Ah, yes. Chris wrote that, and I disabled it when I multiarched the
> > > sh. Maybe it can be done now in a different way.
> > 
> > Do I understand correctly that this can be removed?
> > 
>
>Don't know. I see it comes from config/mips/wince.mt, config/arm/wince.mt,
>and config/sh/wince.mt
>
>The arm and mips definitions seem superfluous, because its only use is
>in sh-tdep.c, so I would eliminate those, it should have no effect.
>
>Am not sure if the sh wince target (or any of the wince targets) is
>still alive.

I'd nuke this but leave the wince targets around for a little longer in
case someone actually has the nerve to fix this in the future.

cgf

Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c

[Christopher Faylor]

On Tue, May 08, 2001 at 10:49:02AM -0400, Elena Zannoni wrote:
>Eli Zaretskii writes:
> > 
> >     * sh-tdep.c:
> > 
> >     #if 0
> >     #ifdef _WIN32_WCE
> >     char **sh_register_names = sh3_reg_names;
> >     #else
> >     char **sh_register_names = sh_generic_reg_names;
> >     #endif
> >     #endif
> > 
> > It seems we could simply remove this, since it's disabled anyway.
> > 
>
>Ah, yes. Chris wrote that, and I disabled it when I multiarched the
>sh. Maybe it can be done now in a different way.

You can remove it.  I doubt that the Windows CE builds now anyway.

cgf

Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c

[Andrew Cagney]

> Ah, yes. Chris wrote that, and I disabled it when I multiarched the
>>sh. Maybe it can be done now in a different way.
> 
> 
> You can remove it.  I doubt that the Windows CE builds now anyway.

Contratulations! You've just identified the targets that will be 
obsoleted in 5.2.

	Andrew

Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c

[Christopher Faylor]

On Tue, May 08, 2001 at 09:17:46PM -0400, Andrew Cagney wrote:
>> Ah, yes. Chris wrote that, and I disabled it when I multiarched the
>>>sh. Maybe it can be done now in a different way.
>> 
>> You can remove it.  I doubt that the Windows CE builds now anyway.
>
>Contratulations! You've just identified the targets that will be 
>obsoleted in 5.2.

Yep.  I assumed as much.

cgf

Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c

[Kevin Buettner]

On May 8,  2:54pm, Eli Zaretskii wrote:

>     * sh3-rom.c:_initialize_sh3_rom()
> 
>     #ifdef _WINDOWS
>       /* On windows we can talk through the parallel port too. */
> 	"Debug on a Hitachi eval board running the SH-3 rom monitor.\n"
> 	"Specify the serial device it is connected to (e.g. com2).\n"
> 	"If you want to use the parallel port to download to it, specify that\n"
> 	"as the second argument. (e.g. lpt1)";
>     #else
> 	"Debug on a Hitachi eval board running the SH-3 rom monitor.\n\
>     Specify the serial device it is connected to (e.g. /dev/ttya).";
>     #endif
> 
> It should be good enough to have a single string here which would tell
> that parallel port is only available on Windows.

Perhaps, but it seems to me that the examples provided in the
different help texts are actually useful.  I'm not sure what to
suggest in order to remove the _WINDOWS ifdef from this one.

Kevin

Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c

[Eli Zaretskii]

On Tue, 8 May 2001, Kevin Buettner wrote:

> >     #ifdef _WINDOWS
> >       /* On windows we can talk through the parallel port too. */
> > 	"Debug on a Hitachi eval board running the SH-3 rom monitor.\n"
> > 	"Specify the serial device it is connected to (e.g. com2).\n"
> > 	"If you want to use the parallel port to download to it, specify that\n"
> > 	"as the second argument. (e.g. lpt1)";
> >     #else
> > 	"Debug on a Hitachi eval board running the SH-3 rom monitor.\n\
> >     Specify the serial device it is connected to (e.g. /dev/ttya).";
> >     #endif
> > 
> > It should be good enough to have a single string here which would tell
> > that parallel port is only available on Windows.
> 
> Perhaps, but it seems to me that the examples provided in the
> different help texts are actually useful.

I thought about retaining both examples.  For example:

 	"Debug on a Hitachi eval board running the SH-3 rom monitor.\n"
 	"Specify the serial device it is connected to\n"
        "(e.g., /dev/tty on Unix or com2 on Windows).\n"
 	"On Windows only, you can use the parallel port to download to it,\n" 
        "in which case specify that as the second argument (e.g., lpt1)."

Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c

[Elena Zannoni]

Eli Zaretskii writes:
 > 
 > On Tue, 8 May 2001, Kevin Buettner wrote:
 > 
 > > >     #ifdef _WINDOWS
 > > >       /* On windows we can talk through the parallel port too. */
 > > > 	"Debug on a Hitachi eval board running the SH-3 rom monitor.\n"
 > > > 	"Specify the serial device it is connected to (e.g. com2).\n"
 > > > 	"If you want to use the parallel port to download to it, specify that\n"
 > > > 	"as the second argument. (e.g. lpt1)";
 > > >     #else
 > > > 	"Debug on a Hitachi eval board running the SH-3 rom monitor.\n\
 > > >     Specify the serial device it is connected to (e.g. /dev/ttya).";
 > > >     #endif
 > > > 
 > > > It should be good enough to have a single string here which would tell
 > > > that parallel port is only available on Windows.
 > > 
 > > Perhaps, but it seems to me that the examples provided in the
 > > different help texts are actually useful.
 > 
 > I thought about retaining both examples.  For example:
 > 
 >  	"Debug on a Hitachi eval board running the SH-3 rom monitor.\n"
 >  	"Specify the serial device it is connected to\n"
 >         "(e.g., /dev/tty on Unix or com2 on Windows).\n"
 >  	"On Windows only, you can use the parallel port to download to it,\n" 
 >         "in which case specify that as the second argument (e.g., lpt1)."
 > 

Yes, that was my understanding as well. This is Ok with me. I am going
to make the change today.

Thanks
Elena

DOS/Windows-specific code: ser-tcp.c

[Eli Zaretskii]

    * ser-tcp.c:

    #ifndef __CYGWIN32__
    #include <netinet/tcp.h>
    #endif

Is netinet/tcp.h header specific to Cygwin?  If so, this could be
replaced by a HAVE_NETINET_TCP_H macro set by Autoconf.

Re: DOS/Windows-specific code: ser-tcp.c

[Russ Allbery]

Eli Zaretskii <eliz@is.elta.co.il> writes:

>     * ser-tcp.c:

>     #ifndef __CYGWIN32__
>     #include <netinet/tcp.h>
>     #endif

> Is netinet/tcp.h header specific to Cygwin?  If so, this could be
> replaced by a HAVE_NETINET_TCP_H macro set by Autoconf.

Solaris at least also has that header file.  Whether including it would
cause any problems, I can't say.  It appears to define the TCP header
structure and a variety of constants related to the protocol.

-- 
Russ Allbery (rra@stanford.edu)             < http://www.eyrie.org/~eagle/ >

Re: DOS/Windows-specific code: ser-tcp.c

[Christopher Faylor]

On Tue, May 08, 2001 at 02:54:04PM +0300, Eli Zaretskii wrote:
>
>    * ser-tcp.c:
>
>    #ifndef __CYGWIN32__
>    #include <netinet/tcp.h>
>    #endif
>
>Is netinet/tcp.h header specific to Cygwin?  If so, this could be
>replaced by a HAVE_NETINET_TCP_H macro set by Autoconf.

Btw, you seem to be working with an older version of the sources, Eli.
I changed this __CYGWIN32__ to __CYGWIN__ a while ago.

I noticed a missing defined (__CYGWIN__) in another one of your
messages, too.

cgf

Re: DOS/Windows-specific code: ser-tcp.c

[Eli Zaretskii]

> 
> Btw, you seem to be working with an older version of the sources, Eli.
> I changed this __CYGWIN32__ to __CYGWIN__ a while ago.

That's true.  Unfortunately, I cannot afford resyncing with the CVS
frequently enough, and neither can I download the monster gdb+dejagnu
distros more than once in a long while: it takes about forever via my
dialup connection.  (Btw, the FTP site could use some improvement: it
is very slow.)

I apologize in advance for any inconvenience this might cause to those
of you who review the diffs.

Re: DOS/Windows-specific code: ser-tcp.c

[Christopher Faylor]

On Tue, May 08, 2001 at 06:08:10PM +0300, Eli Zaretskii wrote:
>>Btw, you seem to be working with an older version of the sources, Eli.
>>I changed this __CYGWIN32__ to __CYGWIN__ a while ago.
>
>That's true.  Unfortunately, I cannot afford resyncing with the CVS
>frequently enough, and neither can I download the monster gdb+dejagnu
>distros more than once in a long while: it takes about forever via my
>dialup connection.  (Btw, the FTP site could use some improvement: it
>is very slow.)

The ftp site is a T1.  You should be able to use one of our many mirrors
to greater effect.  They should mirror the snapshots.

cgf

Re: DOS/Windows-specific code: ser-tcp.c

[Eli Zaretskii]

> Date: Tue, 8 May 2001 11:19:04 -0400
> From: Christopher Faylor <cgf@redhat.com>
> 
> >(Btw, the FTP site could use some improvement: it
> >is very slow.)
> 
> The ftp site is a T1.

I don't think the link is the issue, but it's hard to know.

> You should be able to use one of our many mirrors to greater
> effect.

I'll try, thanks.

Re: DOS/Windows-specific code: ser-tcp.c

[Christopher Faylor]

On Tue, May 08, 2001 at 08:30:07PM +0300, Eli Zaretskii wrote:
>> Date: Tue, 8 May 2001 11:19:04 -0400
>> From: Christopher Faylor <cgf@redhat.com>
>> 
>> >(Btw, the FTP site could use some improvement: it
>> >is very slow.)
>> 
>> The ftp site is a T1.
>
>I don't think the link is the issue, but it's hard to know.

The link is pretty much saturated between http, ftp, and mail.

cgf

Re: DOS/Windows-specific code: ser-tcp.c

[Kevin Buettner]

On May 8,  2:54pm, Eli Zaretskii wrote:

>     * ser-tcp.c:
> 
>     #ifndef __CYGWIN32__
>     #include <netinet/tcp.h>
>     #endif
> 
> Is netinet/tcp.h header specific to Cygwin?  If so, this could be
> replaced by a HAVE_NETINET_TCP_H macro set by Autoconf.

I can't comment on the Cygwin part of the question, but it seems
to me like it'd be a good idea to to use HAVE_NETINET_TCP_H.

Kevin

Re: DOS/Windows-specific code: ser-tcp.c [need ruling from Andrew]

[Christopher Faylor]

On Tue, May 08, 2001 at 11:53:22PM -0700, Kevin Buettner wrote:
>On May 8,  2:54pm, Eli Zaretskii wrote:
>
>>     * ser-tcp.c:
>> 
>>     #ifndef __CYGWIN32__
>>     #include <netinet/tcp.h>
>>     #endif
>> 
>> Is netinet/tcp.h header specific to Cygwin?  If so, this could be
>> replaced by a HAVE_NETINET_TCP_H macro set by Autoconf.
>
>I can't comment on the Cygwin part of the question, but it seems
>to me like it'd be a good idea to to use HAVE_NETINET_TCP_H.

netinet/tcp.h is not specific to Cygwin.  The include isn't even required
on Cygwin, AFAICT.  I'll submit a patch to remove it.

Andrew, do I need permission to check in a Cygwin-specific change to a
module that is not technically "mine" if the patch only touches
Cygwin-specific code?

This one is classifiable as an "obvious" fix but I'm just wondering for
future reference.

cgf

Re: DOS/Windows-specific code: ser-tcp.c [need ruling from Andrew]

[Andrew Cagney]

> I can't comment on the Cygwin part of the question, but it seems
>>to me like it'd be a good idea to to use HAVE_NETINET_TCP_H.
> 
> 
> netinet/tcp.h is not specific to Cygwin.  The include isn't even required
> on Cygwin, AFAICT.  I'll submit a patch to remove it.
> 
> Andrew, do I need permission to check in a Cygwin-specific change to a
> module that is not technically "mine" if the patch only touches
> Cygwin-specific code?
> 
> This one is classifiable as an "obvious" fix but I'm just wondering for
> future reference.

I think most host related fixes are ``obvious''.  The maintainers file says:

``

Host/Native:

The Native maintainer is responsible for target specific native
support - typically shared libraries and quirks to procfs/ptrace/...
The Native maintainer works with the Arch and Core maintainers when
resolving more generic problems.

The host maintainer ensures that gdb (including mmalloc) can be built
as a cross debugger on their platform.
''

along with:

``

Makefile.in, configure* ALL
''

Getting something to build (not work) really should just involve obvious 
fixes.  If you find you're adding lots of #if/#elses then I suspect 
alarm bells will go off in your own head - there is something wrong here 
- long before you post the patch.

Besides, configury changes are mostly suck it and see - very iterative 
in nature.

enjoy,
	Andrew

Re: DOS/Windows-specific code: ser-tcp.c

[Andrew Cagney]

>  * ser-tcp.c:
> 
> #ifndef __CYGWIN32__
> #include <netinet/tcp.h>
> #endif
> 
> Is netinet/tcp.h header specific to Cygwin? If so, this could be
> replaced by a HAVE_NETINET_TCP_H macro set by Autoconf.

The lack of it?  Yes that looks to be unique to cygwin.  HAVE_... should 
be sufficient.

	Andrew

DOS/Windows-specific code: values.c

[Eli Zaretskii]

    * values.c:unpack_double()

	  /* Unsigned -- be sure we compensate for signed LONGEST.  */
    #if !defined (_MSC_VER) || (_MSC_VER > 900)
	  return (ULONGEST) unpack_long (type, valaddr);
    #else
	  /* FIXME!!! msvc22 doesn't support unsigned __int64 -> double */
	  return (LONGEST) unpack_long (type, valaddr);
    #endif /* _MSC_VER */

There's _got_ to be a better way to do this!

Re: DOS/Windows-specific code: values.c

[Kevin Buettner]

On May 8,  2:55pm, Eli Zaretskii wrote:

>     * values.c:unpack_double()
> 
> 	  /* Unsigned -- be sure we compensate for signed LONGEST.  */
>     #if !defined (_MSC_VER) || (_MSC_VER > 900)
> 	  return (ULONGEST) unpack_long (type, valaddr);
>     #else
> 	  /* FIXME!!! msvc22 doesn't support unsigned __int64 -> double */
> 	  return (LONGEST) unpack_long (type, valaddr);
>     #endif /* _MSC_VER */
> 
> There's _got_ to be a better way to do this!

Is this even an issue any longer?  I.e, is the version of MSC being
catered to by the above ifdefs still in widespread use?

Kevin

Re: DOS/Windows-specific code: values.c

[Christopher Faylor]

On Tue, May 08, 2001 at 11:58:38PM -0700, Kevin Buettner wrote:
>On May 8,  2:55pm, Eli Zaretskii wrote:
>
>>     * values.c:unpack_double()
>> 
>> 	  /* Unsigned -- be sure we compensate for signed LONGEST.  */
>>     #if !defined (_MSC_VER) || (_MSC_VER > 900)
>> 	  return (ULONGEST) unpack_long (type, valaddr);
>>     #else
>> 	  /* FIXME!!! msvc22 doesn't support unsigned __int64 -> double */
>> 	  return (LONGEST) unpack_long (type, valaddr);
>>     #endif /* _MSC_VER */
>> 
>> There's _got_ to be a better way to do this!
>
>Is this even an issue any longer?  I.e, is the version of MSC being
>catered to by the above ifdefs still in widespread use?

It's a complete non-issue.  I really don't think that gdb is compilable with
MSVC of any version.  I'm removing the conditionals.

cgf

Re: DOS/Windows-specific code: values.c

[Andrew Cagney]

> On May 8,  2:55pm, Eli Zaretskii wrote:
> 
> 
>> * values.c:unpack_double()
>> 
>> /* Unsigned -- be sure we compensate for signed LONGEST.  */
>> #if !defined (_MSC_VER) || (_MSC_VER > 900)
>> return (ULONGEST) unpack_long (type, valaddr);
>> #else
>> /* FIXME!!! msvc22 doesn't support unsigned __int64 -> double */
>> return (LONGEST) unpack_long (type, valaddr);
>> #endif /* _MSC_VER */
>> 
>> There's _got_ to be a better way to do this!
> 
> 
> Is this even an issue any longer?  I.e, is the version of MSC being
> catered to by the above ifdefs still in widespread use?

To follow up Chris's comment.  Yes, the code is dead but for a different 
reason.  This is probably yet another hang over from WinGDB.

	Andrew

DOS/Windows-specific code in sim/

[Eli Zaretskii]

    * sim/callback.c:

    #if defined(__GO32__) || defined (_MSC_VER)
    static int
    os_poll_quit (p)
	 host_callback *p;
    {
    #if defined(__GO32__)
      int kbhit ();
      int getkey ();
      if (kbhit ())
	{
	  int k = getkey ();
	  if (k == 1)
	    {
	      return 1;
	    }
	  else if (k == 2)
	    {
	      return 1;
	    }
	  else 
	    {
	      sim_cb_eprintf (p, "CTRL-A to quit, CTRL-B to quit harder\n");
	    }
	}
    #endif
    #if defined (_MSC_VER)
      /* NB - this will not compile! */
      int k = win32pollquit();
      if (k == 1)
	return 1;
      else if (k == 2)
	return 1;
    #endif
      return 0;
    }
    #else
    #define os_poll_quit 0
    #endif /* defined(__GO32__) || defined(_MSC_VER) */

This is an old code which was changed in utils.c long ago.  Is some
platform still using this?


    * sim/common/sim-signal.c:

    #ifdef _MSC_VER
    #ifndef SIGTRAP
    #define SIGTRAP 5
    #endif
    #ifndef SIGBUS
    #define SIGBUS 10
    #endif
    #ifndef SIGQUIT
    #define SIGQUIT 3
    #endif
    #endif

Does someone know why this is done?  If SIGTRAP etc. are not defined,
the code should simply not reference it.


    * sim/common/sim-types.h:

    #if !defined (SIM_TYPES_H) && defined (_MSC_VER)
    #define SIM_TYPES_H

    /* bit based */

    #define UNSIGNED32(X) (X##ui32)
    #define UNSIGNED64(X) (X##ui64)

    #define SIGNED32(X) (X##i32)
    #define SIGNED64(X) (X##i64)

    typedef signed char signed8;
    typedef signed short signed16;
    typedef signed int signed32;
    typedef signed __int64 signed64;

    typedef unsigned int unsigned8;
    typedef unsigned int unsigned16;
    typedef unsigned int unsigned32;
    typedef unsigned __int64 unsigned64;

    typedef struct { unsigned64 a[2]; } unsigned128;
    typedef struct { signed64 a[2]; } signed128;

    #endif /* _MSC_VER */

Does anyone know why is this ifdef'ed away for MSC?

Re: DOS/Windows-specific code in sim/

[DJ Delorie]

Eli Zaretskii <eliz@is.elta.co.il> writes:
> Does someone know why this is done?  If SIGTRAP etc. are not defined,
> the code should simply not reference it.

The problem is that the simulators generate these signals (the
simulated environment supports them) but they're translated to the
hosts's SIG* values to "standardize" how they're handled by gdb.  If
the sim supports more signals than the host, there needs to be some
fake value they're translated into.

Not that I agree with the technique, but that's how it is...

Re: DOS/Windows-specific code in sim/

[Eli Zaretskii]

> From: DJ Delorie <dj@redhat.com>
> Newsgroups: cygnus.gdb
> Date: 08 May 2001 12:27:05 -0400
> 
> The problem is that the simulators generate these signals (the
> simulated environment supports them) but they're translated to the
> hosts's SIG* values to "standardize" how they're handled by gdb.  If
> the sim supports more signals than the host, there needs to be some
> fake value they're translated into.

Then these define's can (and probably should) be done on all systems.
Like this, for example:

  #ifndef SIGTRAP
  #define SIGTRAP 5
  #endif

Would that be okay?

Re: DOS/Windows-specific code in sim/

[Andrew Cagney]

> Eli Zaretskii <eliz@is.elta.co.il> writes:
> 
>> Does someone know why this is done?  If SIGTRAP etc. are not defined,
>> the code should simply not reference it.
> 
> 
> The problem is that the simulators generate these signals (the
> simulated environment supports them) but they're translated to the
> hosts's SIG* values to "standardize" how they're handled by gdb.  If
> the sim supports more signals than the host, there needs to be some
> fake value they're translated into.
> 
> Not that I agree with the technique, but that's how it is...

The simulator currently passes target signal values across its 
interface. I agree it is silly.

To quote the TODO file:

--

Fix target_signal_from_host() etc.

The name is wrong for starters.  ``target_signal'' should probably be
``gdb_signal''.  ``from_host'' should be ``from_target_signal''.
After that it needs to be multi-arched and made independent of any
host signal numbering.

--

Suprisingly, remote.c got it right (the doco is wrong).  It passes

GDB signals to the remote target.

	Andrew

DOS/Windows-specific code: all the rest

[Eli Zaretskii]

Finally, there were several additional Grep hits, for which I'm unsure
what to do:

  - Some files config/*/*cygwin.h want to be backward compatible to
    old Cygwin versions and use __CYGWIN32__ for that.

  - Many files in rdi-share/ use COMPILING_ON_WINDOWS and
    __CYGWIN32__, partly for backward compatibility.  rdi-share/host.h
    also uses _MSC_VER.

Chris, could you comment on these?

  - There's some sporadic (and probably obsolete by now) support for
    GO32 and Windows in remote-array.c, remote-e7000.c, and
    ser-e7kpc.c.  The latter two seem to use DOS/Windows as their only
    host systems, so perhaps it's okay to leave the #ifdef's alone.

  - ser-ocd.c is Windows- and wiggler-specific.  If someone is going
    to make it less proprietary (see the recent discussion Re: gpl,
    gdb and wigglers.dll), then we should revisit this file after it
    is changed; if not, I'd suggest to leave it alone for now.

  - What's the story with files 29k-share/udi/ ?  udi2go32.c seems to
    be DJGPP-specific, while udi2soc.c and udr.c are the other way
    around: all their code is ifdef'ed away under DJGPP.

  - m32r-rom.c uses _MSC_VER to ifdef away a bunch of functions,
    header files, and commands.  Does anyone know which compiler needs
    that, and why?  (I mean, Windows _does_ support networking,
    right?)

  - nindy-share/ttyflush.c uses _MSC_VER to use _sleep instead of
    sleep.  Again, for which compiler is this needed?

  - should we bother about utils/amd-udi/udi/* files?  Two of them use
    _MSC_VER.

Re: DOS/Windows-specific code: all the rest

[leonp]

At 14:57 08/05/01 +0300, you wrote:
>   - ser-ocd.c is Windows- and wiggler-specific.  If someone is going
>     to make it less proprietary (see the recent discussion Re: gpl,
>     gdb and wigglers.dll), then we should revisit this file after it
>     is changed; if not, I'd suggest to leave it alone for now.

         For now this file doesn't include the ocd support code while 
compiling in Cygwin, because it is included in
#ifdef _WIN32
#endif


Leon Pollak
leonp@plris.com

Re: DOS/Windows-specific code: all the rest

[Christopher Faylor]

On Tue, May 08, 2001 at 03:12:37PM +0200, leonp@plris.com wrote:
>At 14:57 08/05/01 +0300, you wrote:
>>   - ser-ocd.c is Windows- and wiggler-specific.  If someone is going
>>     to make it less proprietary (see the recent discussion Re: gpl,
>>     gdb and wigglers.dll), then we should revisit this file after it
>>     is changed; if not, I'd suggest to leave it alone for now.
>
>         For now this file doesn't include the ocd support code while 
>compiling in Cygwin, because it is included in
>#ifdef _WIN32
>#endif

That would mean that it doesn't build at all, then, currently.  I don't
think that the native windows version of gdb works.

cgf

Re: DOS/Windows-specific code: all the rest

[DJ Delorie]

Eli Zaretskii <eliz@is.elta.co.il> writes:
>   - What's the story with files 29k-share/udi/ ?  udi2go32.c seems to
>     be DJGPP-specific, while udi2soc.c and udr.c are the other way
>     around: all their code is ifdef'ed away under DJGPP.

I wrote those.  UDI required a custom version of go32 that had the UDI
interface libraries linked in, and a custom API between that go32 and
the program.  It was quite a hack.  On unix systems, the UDI interface
always sits on the other side of a socket, and it talks to the
hardware (or simulator) on your behalf.

UDI, btw, has a standard interface for all boards and simulators, so
that one debugger binary works with every target.  You can't just code
something in gdb and be done with it, you *have* to talk to these UDI
modules, which are provided by the vendor.

So, there needs to be one interface for each class of host environment
that UDI drivers exist for.

Re: DOS/Windows-specific code: all the rest

[Eli Zaretskii]

> From: DJ Delorie <dj@redhat.com>
> Newsgroups: cygnus.gdb
> Date: 08 May 2001 12:31:28 -0400
> 
> Eli Zaretskii <eliz@is.elta.co.il> writes:
> >   - What's the story with files 29k-share/udi/ ?  udi2go32.c seems to
> >     be DJGPP-specific, while udi2soc.c and udr.c are the other way
> >     around: all their code is ifdef'ed away under DJGPP.
> 
> I wrote those.  UDI required a custom version of go32 that had the UDI
> interface libraries linked in, and a custom API between that go32 and
> the program.  It was quite a hack.  On unix systems, the UDI interface
> always sits on the other side of a socket, and it talks to the
> hardware (or simulator) on your behalf.
[...] 
> So, there needs to be one interface for each class of host environment
> that UDI drivers exist for.

This sounds as if we could simply remove the #ifdef's from these
files, since each one of them is compiled on exactly one host, and
they are all orthogonal.  Am I missing something?

Re: DOS/Windows-specific code: all the rest

[DJ Delorie]

> This sounds as if we could simply remove the #ifdef's from these
> files, since each one of them is compiled on exactly one host, and
> they are all orthogonal.  Am I missing something?

I don't remember.  That was many many years ago.

[RFA] Remove OS-specific defines (was: _WIN32?)

[Eli Zaretskii]

I'm seeking approval for the following patches.  They remove all the
DOS- and Windows-specific #ifdef's like "#ifdef _WIN32" and use the
portable macros from filenames.h instead.  In addition, they convert
code which used macros private to GDB, such as SLASH_P and ROOTED_P,
to use the macros from filenames.h instead.


2001-05-07  Eli Zaretskii  <eliz@is.elta.co.il>

	* source.c (mod_path, openp): Use HAVE_DOS_BASED_FILE_SYSTEM
	instead of system-specific define's like _WIN32 and __MSDOS__.
	Use IS_DIR_SEPARATOR and IS_ABSOLUTE_PATH instead of SLASH_P and
	ROOTED_P.
	(top-level): #include "filenames.h".

	* solib.c (solib_open): Use IS_DIR_SEPARATOR and IS_ABSOLUTE_PATH
	instead of SLASH_CHAR, ROOTED_P and SLASH_P.
	(top-level): #include "filenames.h".

	* defs.h (SLASH_P, SLASH_CHAR, ROOTED_P): Remove definitions.
	(SLASH_STRING): Define only for _WIN32.

	* completer.c: Use HAVE_DOS_BASED_FILE_SYSTEM instead of
	__MSDOS_.

	* cli/cli-cmds.c (cd_command): Use IS_DIR_SEPARATOR and
	IS_ABSOLUTE_PATH instead of SLASH_P and ROOTED_P.  Replace
	system-specific ifdefs with HAVE_DOS_BASED_FILE_SYSTEM.
	(top-level): #include "filenames.h".


--- gdb/cli/cli-cmds.c~0	Thu Mar 29 01:42:22 2001
+++ gdb/cli/cli-cmds.c	Mon May  7 18:08:40 2001
@@ -23,6 +23,7 @@
 #include "target.h"	 /* For baud_rate, remote_debug and remote_timeout */
 #include "gdb_wait.h"		/* For shell escape implementation */
 #include "gnu-regex.h"		/* Used by apropos_command */
+#include "filenames.h"		/* for DOSish file names */
 
 #ifdef UI_OUT
 #include "ui-out.h"
@@ -292,7 +293,7 @@ cd_command (char *dir, int from_tty)
   if (chdir (dir) < 0)
     perror_with_name (dir);
 
-#if defined(_WIN32) || defined(__MSDOS__)
+#if HAVE_DOS_BASED_FILE_SYSTEM
   /* There's too much mess with DOSish names like "d:", "d:.",
      "d:./foo" etc.  Instead of having lots of special #ifdef'ed code,
      simply get the canonicalized name of the current directory.  */
@@ -300,24 +301,24 @@ cd_command (char *dir, int from_tty)
 #endif
 
   len = strlen (dir);
-  if (SLASH_P (dir[len - 1]))
+  if (IS_DIR_SEPARATOR (dir[len - 1]))
     {
       /* Remove the trailing slash unless this is a root directory
          (including a drive letter on non-Unix systems).  */
       if (!(len == 1)		/* "/" */
-#if defined(_WIN32) || defined(__MSDOS__)
-	  && !(!SLASH_P (*dir) && ROOTED_P (dir) && len <= 3)	/* "d:/" */
+#if HAVE_DOS_BASED_FILE_SYSTEM
+	  && !(len == 3 && dir[1] == ':') /* "d:/" */
 #endif
 	  )
 	len--;
     }
 
   dir = savestring (dir, len);
-  if (ROOTED_P (dir))
+  if (IS_ABSOLUTE_PATH (dir))
     current_directory = dir;
   else
     {
-      if (SLASH_P (current_directory[strlen (current_directory) - 1]))
+      if (IS_DIR_SEPARATOR (current_directory[strlen (current_directory) - 1]))
 	current_directory = concat (current_directory, dir, NULL);
       else
 	current_directory = concat (current_directory, SLASH_STRING, dir, NULL);
@@ -329,17 +330,18 @@ cd_command (char *dir, int from_tty)
   found_real_path = 0;
   for (p = current_directory; *p;)
     {
-      if (SLASH_P (p[0]) && p[1] == '.' && (p[2] == 0 || SLASH_P (p[2])))
+      if (IS_DIR_SEPARATOR (p[0]) && p[1] == '.'
+	  && (p[2] == 0 || IS_DIR_SEPARATOR (p[2])))
 	strcpy (p, p + 2);
-      else if (SLASH_P (p[0]) && p[1] == '.' && p[2] == '.'
-	       && (p[3] == 0 || SLASH_P (p[3])))
+      else if (IS_DIR_SEPARATOR (p[0]) && p[1] == '.' && p[2] == '.'
+	       && (p[3] == 0 || IS_DIR_SEPARATOR (p[3])))
 	{
 	  if (found_real_path)
 	    {
 	      /* Search backwards for the directory just before the "/.."
 	         and obliterate it and the "/..".  */
 	      char *q = p;
-	      while (q != current_directory && !SLASH_P (q[-1]))
+	      while (q != current_directory && !IS_DIR_SEPARATOR (q[-1]))
 		--q;
 
 	      if (q == current_directory)

--- gdb/completer.c~5	Sun May  6 13:10:30 2001
+++ gdb/completer.c	Mon May  7 17:21:02 2001
@@ -66,7 +66,7 @@ static char *gdb_completer_command_word_
    break characters any characters that are commonly used in file
    names, such as '-', '+', '~', etc.  Otherwise, readline displays
    incorrect completion candidates.  */
-#ifdef __MSDOS__
+#if HAVE_DOS_BASED_FILE_SYSTEM
 /* MS-DOS and MS-Windows use colon as part of the drive spec, and most
    programs support @foo style response files.  */
 static char *gdb_completer_file_name_break_characters = " \t\n*|\"';?><@";

--- gdb/defs.h~0	Sat Mar 24 02:00:36 2001
+++ gdb/defs.h	Mon May  7 18:08:48 2001
@@ -1330,34 +1330,14 @@ extern int use_windows;
 #define DIRNAME_SEPARATOR ':'
 #endif
 
-#ifndef SLASH_P
-#if defined(__GO32__)||defined(_WIN32)
-#define SLASH_P(X) ((X)=='\\')
-#else
-#define SLASH_P(X) ((X)=='/')
-#endif
-#endif
-
-#ifndef SLASH_CHAR
-#if defined(__GO32__)||defined(_WIN32)
-#define SLASH_CHAR '\\'
-#else
-#define SLASH_CHAR '/'
-#endif
-#endif
-
 #ifndef SLASH_STRING
-#if defined(__GO32__)||defined(_WIN32)
+#ifdef _WIN32
 #define SLASH_STRING "\\"
 #else
 #define SLASH_STRING "/"
 #endif
 #endif
 
-#ifndef ROOTED_P
-#define ROOTED_P(X) (SLASH_P((X)[0]))
-#endif
-
 /* On some systems, PIDGET is defined to extract the inferior pid from
    an internal pid that has the thread id and pid in seperate bit
    fields.  If not defined, then just use the entire internal pid as

--- gdb/solib.c~0	Tue Mar  6 10:41:56 2001
+++ gdb/solib.c	Mon May  7 18:11:24 2001
@@ -39,6 +39,7 @@
 #include "language.h"
 #include "gdbcmd.h"
 #include "completer.h"
+#include "filenames.h"		/* for DOSish file names */
 
 #include "solist.h"
 
@@ -101,10 +102,14 @@ solib_open (char *in_pathname, char **fo
 {
   int found_file = -1;
   char *temp_pathname = NULL;
+  char *p = in_pathname;
 
-  if (strchr (in_pathname, SLASH_CHAR))
+  while (*p && !IS_DIR_SEPARATOR (*p))
+    p++;
+
+  if (*p)
     {
-      if (! ROOTED_P (in_pathname) || solib_absolute_prefix == NULL)
+      if (! IS_ABSOLUTE_PATH (in_pathname) || solib_absolute_prefix == NULL)
         temp_pathname = in_pathname;
       else
 	{
@@ -112,7 +117,7 @@ solib_open (char *in_pathname, char **fo
 
 	  /* Remove trailing slashes from absolute prefix.  */
 	  while (prefix_len > 0
-		 && SLASH_P (solib_absolute_prefix[prefix_len - 1]))
+		 && IS_DIR_SEPARATOR (solib_absolute_prefix[prefix_len - 1]))
 	    prefix_len--;
 
 	  /* Cat the prefixed pathname together.  */

--- gdb/source.c~0	Tue Mar 27 22:57:04 2001
+++ gdb/source.c	Mon May  7 18:26:20 2001
@@ -40,6 +40,7 @@
 #include "annotate.h"
 #include "gdbtypes.h"
 #include "linespec.h"
+#include "filenames.h"		/* for DOSish file names */
 #ifdef UI_OUT
 #include "ui-out.h"
 #endif
@@ -330,12 +331,12 @@ mod_path (char *dirname, char **which_pa
 	  }
       }
 
-      if (!(SLASH_P (*name) && p <= name + 1)	/* "/" */
-#if defined(_WIN32) || defined(__MSDOS__)
+      if (!(IS_DIR_SEPARATOR (*name) && p <= name + 1)	 /* "/" */
+#if HAVE_DOS_BASED_FILE_SYSTEM
       /* On MS-DOS and MS-Windows, h:\ is different from h: */
-	  && !(!SLASH_P (*name) && ROOTED_P (name) && p <= name + 3)	/* d:/ */
+	  && !(p == name + 3 && name[1] == ':') 	 /* "d:/" */
 #endif
-	  && SLASH_P (p[-1]))
+	  && IS_DIR_SEPARATOR (p[-1]))
 	/* Sigh. "foo/" => "foo" */
 	--p;
       *p = '\0';
@@ -348,7 +349,7 @@ mod_path (char *dirname, char **which_pa
 	      name = current_directory;
 	      goto append;
 	    }
-	  else if (p > name + 1 && SLASH_P (p[-2]))
+	  else if (p > name + 1 && IS_DIR_SEPARATOR (p[-2]))
 	    {
 	      if (p - name == 2)
 		{
@@ -370,11 +371,11 @@ mod_path (char *dirname, char **which_pa
 
       if (name[0] == '~')
 	name = tilde_expand (name);
-#if defined(_WIN32) || defined(__MSDOS__)
-      else if (ROOTED_P (name) && p == name + 2)	/* "d:" => "d:." */
+#if HAVE_DOS_BASED_FILE_SYSTEM
+      else if (IS_ABSOLUTE_PATH (name) && p == name + 2) /* "d:" => "d:." */
 	name = concat (name, ".", NULL);
 #endif
-      else if (!ROOTED_P (name) && name[0] != '$')
+      else if (!IS_ABSOLUTE_PATH (name) && name[0] != '$')
 	name = concat (current_directory, SLASH_STRING, name, NULL);
       else
 	name = savestring (name, p - name);
@@ -530,7 +531,7 @@ openp (char *path, int try_cwd_first, ch
   mode |= O_BINARY;
 #endif
 
-  if (try_cwd_first || ROOTED_P (string))
+  if (try_cwd_first || IS_ABSOLUTE_PATH (string))
     {
       int i;
       filename = string;
@@ -538,12 +539,12 @@ openp (char *path, int try_cwd_first, ch
       if (fd >= 0)
 	goto done;
       for (i = 0; string[i]; i++)
-	if (SLASH_P (string[i]))
+	if (IS_DIR_SEPARATOR (string[i]))
 	  goto done;
     }
 
   /* ./foo => foo */
-  while (string[0] == '.' && SLASH_P (string[1]))
+  while (string[0] == '.' && IS_DIR_SEPARATOR (string[1]))
     string += 2;
 
   alloclen = strlen (path) + strlen (string) + 2;
@@ -581,7 +582,7 @@ openp (char *path, int try_cwd_first, ch
 	}
 
       /* Remove trailing slashes */
-      while (len > 0 && SLASH_P (filename[len - 1]))
+      while (len > 0 && IS_DIR_SEPARATOR (filename[len - 1]))
 	filename[--len] = 0;
 
       strcat (filename + len, SLASH_STRING);
@@ -597,14 +598,14 @@ done:
     {
       if (fd < 0)
 	*filename_opened = (char *) 0;
-      else if (ROOTED_P (filename))
+      else if (IS_ABSOLUTE_PATH (filename))
 	*filename_opened = savestring (filename, strlen (filename));
       else
 	{
 	  /* Beware the // my son, the Emacs barfs, the botch that catch... */
 
 	  *filename_opened = concat (current_directory,
-		 SLASH_P (current_directory[strlen (current_directory) - 1])
+           IS_DIR_SEPARATOR (current_directory[strlen (current_directory) - 1])
 				     ? "" : SLASH_STRING,
 				     filename, NULL);
 	}

Re: [RFA] Remove OS-specific defines (was: _WIN32?)

[Kevin Buettner]

On May 7,  7:10pm, Eli Zaretskii wrote:

> 	* solib.c (solib_open): Use IS_DIR_SEPARATOR and IS_ABSOLUTE_PATH
> 	instead of SLASH_CHAR, ROOTED_P and SLASH_P.
> 	(top-level): #include "filenames.h".

Your changes to solib.c are approved.  (FWIW, I glanced over your
changes to the other files and they look good too.)

> 	* defs.h (SLASH_P, SLASH_CHAR, ROOTED_P): Remove definitions.
> 	(SLASH_STRING): Define only for _WIN32.

Once your changes to the other .c files are approved, I think this
one can be regarded as an obvious change.

Don't forget to also remove the definitions of SLASH_P, SLASH_CHAR, and
ROOTED_P in config/i386/xm-cygwin.h and config/i386/xm-go32.h.

Kevin

Re: [RFA] Remove OS-specific defines (was: _WIN32?)

[Eli Zaretskii]

> Date: Mon, 7 May 2001 10:38:55 -0700
> From: Kevin Buettner <kevinb@cygnus.com>
> 
> On May 7,  7:10pm, Eli Zaretskii wrote:
> 
> > 	* solib.c (solib_open): Use IS_DIR_SEPARATOR and IS_ABSOLUTE_PATH
> > 	instead of SLASH_CHAR, ROOTED_P and SLASH_P.
> > 	(top-level): #include "filenames.h".
> 
> Your changes to solib.c are approved.  (FWIW, I glanced over your
> changes to the other files and they look good too.)

Thanks for reviewing them so soon.

> Don't forget to also remove the definitions of SLASH_P, SLASH_CHAR, and
> ROOTED_P in config/i386/xm-cygwin.h and config/i386/xm-go32.h.

Yes, it's in the pipeline ;-)  I just wanted to hear from Chris, at
the very least, before futzing with his files.

Btw, is it perhaps a good idea to add to gdbint.texinfo some
guidelines about writing portable code which handles file names,
including the list of these macros?  Andrew?

Re: [RFA] Remove OS-specific defines (was: _WIN32?)

[Andrew Cagney]

>> Don't forget to also remove the definitions of SLASH_P, SLASH_CHAR, and
>> ROOTED_P in config/i386/xm-cygwin.h and config/i386/xm-go32.h.

I think these changes are straightforward (er obvious) and definitly a 
good thing.


> Yes, it's in the pipeline ;-)  I just wanted to hear from Chris, at
> the very least, before futzing with his files.
> 
> Btw, is it perhaps a good idea to add to gdbint.texinfo some
> guidelines about writing portable code which handles file names,
> including the list of these macros?  Andrew?

Yes, and yes.

	Andrew

Re: [Mingw-users] Re: _WIN32?

[Paul Hilfinger]

>   Date: Thu, 03 May 2001 16:40:59 -0400
>   From: Andrew Cagney <ac131313@cygnus.com>

>   Remember, GDB is moving away from OS specific tests and towards 
>   autoconf/feature based tests.  Things like this should be replaced by 
>   something like WITH_REALLY_TRICKY_FILESYSTEM_SUPPORT test (and 
>   eventually changed to a runtime switch?).

Has anyone considered going even further, and eliminating explicit
conditionals in .c files in favor of host/target-dependent #defines?  
It's not always possible, of course, but I can see something like

    if ((b->type == bp_catch_load)
#if defined(SOLIB_HAVE_LOAD_EVENT)
	&& (!SOLIB_HAVE_LOAD_EVENT (inferior_pid)
	    || ((b->dll_pathname != NULL)
		&& (strcmp (b->dll_pathname, 
			    SOLIB_LOADED_LIBRARY_PATHNAME (inferior_pid)) 
		    != 0)))
#endif
      )

turning instead into

     if (b->type == bp_catch_load) 
         && SOLIB_MAY_HAVE_LOADED (inferior_pid, b->dll_pathname))

>   For reference, there are ~38 uses of _WIN32 in the sources, ~18 don't 
>   appear to be accompanied by #ifdef MSDOS, CYGWIN or GO32. It is those 18 
>   that I think should be deleted.

Is there any particular rush?  There are apparently a couple of groups who
intend to spruce up the WIN32 stuff and get it working in GDB5.  Why don't
we just agree that part of their sprucing up effort should be the removal of 
these unsightly _WIN32 conditionalizations?

Paul Hilfinger

Re: [Mingw-users] Re: _WIN32?

[Andrew Cagney]

> Has anyone considered going even further, and eliminating explicit
> conditionals in .c files in favor of host/target-dependent #defines?  
> It's not always possible, of course, but I can see something like

Multi-arch is largely already doing this on the target side.
On the host side, as Eli just pointed out, things sometimes are ok but 
other times (e.g. terminal handling) can get tricky.

>  For reference, there are ~38 uses of _WIN32 in the sources, ~18 don't 
>> appear to be accompanied by #ifdef MSDOS, CYGWIN or GO32. It is those 18 
>> that I think should be deleted.
> 
> 
> Is there any particular rush?  There are apparently a couple of groups who
> intend to spruce up the WIN32 stuff and get it working in GDB5.  Why don't
> we just agree that part of their sprucing up effort should be the removal of 
> these unsightly _WIN32 conditionalizations?

Largely, no rush.  There is, however, the bit of code main.c that is 
getting up my nose.  Per earlier e-mail, to the best of my knowledge it 
is a hang over from WinGDB so should be deleted.  Hmm,

1.130        (sac      15-Jan-95):   /* The default command loop. 
1.130        (sac      15-Jan-95):      The WIN32 Gui calls this main to set up gdb's state, and 
1.130        (sac      15-Jan-95):      has its own command loop. */
1.130        (sac      15-Jan-95): #if !defined (WIN32)

so it has nothing to do with mingw.  I'll delete it.

	Andrew

Re: [Mingw-users] Re: _WIN32?

[Eli Zaretskii]

> Date: Thu, 03 May 2001 16:40:59 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> #if defined(_WIN32) || defined(__MSDOS__) || defined(__CYGWIN__):
> 
> Remember, GDB is moving away from OS specific tests and towards 
> autoconf/feature based tests.  Things like this should be replaced by 
> something like WITH_REALLY_TRICKY_FILESYSTEM_SUPPORT test (and 
> eventually changed to a runtime switch?).

What do you envision the runtime switch will test?

These conditionals define behavior that depends on the system where
the GDB executable runs.  Since any given GDB binary is by definition
produced for only one type of platform, all the features of that
platform are known at compile time, and there's no need to test
anything at run time.

In other words, gdb.exe compiled on Windows will only run on Windows,
so we can know in advance all the features which will or will not work
when it runs.  And similarly for gdb produced for running on
GNU/Linux.

Re: [Mingw-users] Re: _WIN32?

[Danny Smith]

>> 
>> You don't necessarily have to test for anything.  We could just add
>> a TERMINAL_DOES_BLAH conditional which was set only when gdb was being
>> run under cygwin, or djgpp, or (don't worry we're working on it and
>> will have something in the next <<undeterminied>> timeframe, really
>> we will) Windows.  You don't actually have to write an autoconf test
>> for this.
>
>I agree with that approach, but Andrew was talking about Autoconf.

So was I.  You could still do this in configure.in.  The alternatives are
having something like:

  #if defined (__CYGWIN__) || defined (__DJGPP__)
  # define FILENAME_CASE_INSENSITIVE
  #endif

of something like (in configure.host):

  case "$host_cpu" in

  i[3456]86-*-cygwin*)
	  gdb_host=cygwin
	  FILENAME_CASE_INSENSITIVE=1
	  ;;

  i[3456]86-*-msdosdjgpp*)
	  gdb_host=go32
	  FILENAME_CASE_INSENSITIVE=1
	  ;;
  esac

  AC_SUBST(FILENAME_CASE_INSENSITIVE)

cgf


Please be patient.  I have very little experience with multiplatform
configurations, none with autoconfigury  I am one of these folk:

>>(don't worry we're working on it and
>> will have something in the next <<undeterminied>> timeframe, really
>> we will) Windows. 

 and I am getting a bit confused by some of this discussion, and what I should
do.  For me examples teach.

Here is an example of what I would like to add:

In event-loop.c, a clock is needed. Posix uses gettimeofday. Here is how I
would provide that clock for w32:

/*  winbase.h definitions */
typedef struct _FILETIME {
	unsigned long dwLowDateTime;
	unsigned long dwHighDateTime;
} FILETIME;
void __stdcall GetSystemTimeAsFileTime(FILETIME*);

/*time from 1 Jan 1601 to 1 Jan 1970 in 100ns units */
#define _W32_FT_OFFSET (116444736000000000LL) 

typedef union {
	long long ns100; /*time since 1 Jan 1601 in 100ns units */
	FILETIME ft;
	} w32_ftv;

void nt_gettimeofday(struct timeval* p, struct timezone* tz /* IGNORED */){
	w32_ftv _now; 
	GetSystemTimeAsFileTime( &(_now.ft) );
        p->tv_usec=(long)((_now.ns100 / 10LL) % 1000000LL );
	p->tv_sec= (long)((_now.ns100-_W32_FT_OFFSET)/10000000LL);
return;

 
Now, how would you like me to put this into event-loop.c.
An example please,  either on this list or privately

_____________________________________________________________________________
http://store.yahoo.com.au - Yahoo! Store
- It's time you had your business online!

Re: [Mingw-users] Re: _WIN32?

[Christopher Faylor]

On Sun, May 06, 2001 at 08:56:48AM +1000, Danny Smith wrote:
>Please be patient.  I have very little experience with multiplatform
>configurations, none with autoconfigury  I am one of these folk:
>
>>>(don't worry we're working on it and will have something in the next
>>><<undeterminied>> timeframe, really we will) Windows.
>
>and I am getting a bit confused by some of this discussion, and what I
>should do.  For me examples teach.

Possibly reading the gdb archives might be helpful, then.

It is difficult to rectify confusion if you are only making an assertion
of confusion without actually saying what you are confused about.

If you have a question during a discussion, then please ask it.

>Here is an example of what I would like to add:
>
>In event-loop.c, a clock is needed.  Posix uses gettimeofday.  Here is
>how I would provide that clock for w32:
>
>/* winbase.h definitions */ typedef struct _FILETIME { unsigned long
>dwLowDateTime; unsigned long dwHighDateTime; } FILETIME; void __stdcall
>GetSystemTimeAsFileTime(FILETIME*);
>
>/*time from 1 Jan 1601 to 1 Jan 1970 in 100ns units */ #define
>_W32_FT_OFFSET (116444736000000000LL)
>
>typedef union { long long ns100; /*time since 1 Jan 1601 in 100ns units
>*/ FILETIME ft; } w32_ftv;
>
>void nt_gettimeofday(struct timeval* p, struct timezone* tz /* IGNORED
>*/){ w32_ftv _now; GetSystemTimeAsFileTime( &(_now.ft) );
>p->tv_usec=(long)((_now.ns100 / 10LL) % 1000000LL ); p->tv_sec=
>(long)((_now.ns100-_W32_FT_OFFSET)/10000000LL); return;
>
>
>Now, how would you like me to put this into event-loop.c.  An example
>please, either on this list or privately

I may be wrong but I don't believe that anyone wants to be involved in
telling you what to do step by step along the way.

Your first step is to visit the gdb web page at
http://sources.redhat.com/gdb/  and check out all of the information
there.

Once you are sure that you have mastered all of the intracies of
submitting patches that are outlined on this pages and the pages that it
references, you should start submitting patches in the proscribed
manner.  People will then offer suggestions about your patches and
you will refine them based on your suggestions.

If I were you, I would encapsulate everything as much as possible.
Rather than make changes to 27 different gdb functions, create
compatibility functions and put them in win32-nat.c, controlled by a
defined (_WIN32) && !defined (__CYGWIN__) conditional.  I think that it
is appropriate to use system-specific defines in something like
win32-nat.c.  I wouldn't deny a patch which contained this kind of
change (modulo Andrew's oversight, of course).

I'm not sure what you are expecting from reading the above.  If you are
implying that you will be including things like the definition for
FILETIME in gdb somewhere, that is clearly wrong.  Your formatting is
also not GNU compliant.  It will have to conform to the rest of gdb if
you want to get it accepted.

It looks like you could just name the function above gettimeofday and
that would satisfy gdb's gettimeofday requirement.  You'll need to put
the prototypes for this function into something that is included by gdb,
though.  I'm not sure what header file would be appropriate for that.
That is something that you'll have to research.

We were talking about the fact that there may be places in gdb which
are currently under _WIN32 control which should actually be under something
like FILESYSTEM_USES_COLON control, or something like that.  Those are
the things that should be set in configure.host, IMO.

cgf

Re: [Mingw-users] Re: _WIN32?

[Eli Zaretskii]

On Sat, 5 May 2001, Christopher Faylor wrote:

> If I were you, I would encapsulate everything as much as possible.
> Rather than make changes to 27 different gdb functions, create
> compatibility functions and put them in win32-nat.c, controlled by a
> defined (_WIN32) && !defined (__CYGWIN__) conditional.

It can also make sense to put this in libiberty, although that would
complicate the patch acceptance.  However, gettimeofday is a very
important function, and if MinGW indeed lacks it, its implementation
shouldn't be private to GDB, IMHO.

> We were talking about the fact that there may be places in gdb which
> are currently under _WIN32 control which should actually be under something
> like FILESYSTEM_USES_COLON control, or something like that.  Those are
> the things that should be set in configure.host, IMO.

I suggest to use the macros from include/filenames.h as much as
possible.  They are used in Binutils and elsewhere in GDB, so there
shouldbe no need to reinvent them.

I will shortly submit a patch that switches some of the #ifdef's to
use filenames.h.

Re: [Mingw-users] Re: _WIN32?

[Eli Zaretskii]

On Sun, 6 May 2001, =?iso-8859-1?q?Danny=20Smith?= wrote:

> In event-loop.c, a clock is needed. Posix uses gettimeofday. Here is how I
> would provide that clock for w32:

Does MinGW indeed lacks gettimeofday?  I'd be surprised.

Re: [Mingw-users] Re: _WIN32?

[Danny Smith]

--- Eli Zaretskii <eliz@is.elta.co.il> wrote: > 
> On Sun, 6 May 2001, =?iso-8859-1?q?Danny=20Smith?= wrote:
> 
> > In event-loop.c, a clock is needed. Posix uses gettimeofday. Here is how I
> > would provide that clock for w32:
> 
> Does MinGW indeed lacks gettimeofday?  I'd be surprised.

Mingw has _ftime in CRT, but not gettimeofday.  Basically C runtime consists
only what is in msvcrt.dll, with the exception of a few add-ons (like the stuff
in dirent.h) and oldname wrappers.

Danny


_____________________________________________________________________________
http://store.yahoo.com.au - Yahoo! Store
- It's time you had your business online!

Re: _WIN32?

[Christopher Faylor]

On Mon, Apr 30, 2001 at 01:05:17PM -0400, Andrew Cagney wrote:
>Christopher Faylor wrote:
>
>>         _WIN32          Pure WIN32 support 'gcc -mno-cygwin' --
>>                         don't know if it even builds.  _WIN32 is
>>                         now no longer defined by gcc.
>
>So, can I delete this one? :-)

I don't know.  Someone used to maintain a non-cygwin Windows version of
gdb.  I don't know if it even builds, like I said.  I'm not even sure
how to configure it.

Perhaps the people at mingw-users@lists.sourceforge.net know the answer
to this?  I've Cc'ed them.

cgf

Re: [Mingw-users] Re: _WIN32?

[Danny Smith]

--- Christopher Faylor <cgf@redhat.com> wrote: > On Mon, Apr 30, 2001 at
01:05:17PM -0400, Andrew Cagney wrote:
> >Christopher Faylor wrote:
> >
> >>         _WIN32          Pure WIN32 support 'gcc -mno-cygwin' --
> >>                         don't know if it even builds.  _WIN32 is
> >>                         now no longer defined by gcc.
> >
> >So, can I delete this one? :-)
> 
> I don't know.  Someone used to maintain a non-cygwin Windows version of
> gdb.  I don't know if it even builds, like I said.  I'm not even sure
> how to configure it.
> 
> Perhaps the people at mingw-users@lists.sourceforge.net know the answer
> to this?  I've Cc'ed them.
> 
> cgf
> 

The last non-cygwin windows version of gdb that I know of is 4.18 which Mumit
made available here: 
ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/ports

The diff file for that port is dated May 1999.

I have just started work on gdb 5.0 for mingw. I have not gotten far, mainly
because of lack of time.  Has anyone else made progress.

Danny

_____________________________________________________________________________
http://store.yahoo.com.au - Yahoo! Store
- It's time you had your business online!

Re: [Mingw-users] Re: _WIN32?

[Christopher Faylor]

On Tue, May 01, 2001 at 09:19:39AM +1000, Danny Smith wrote:
>
>--- Christopher Faylor <cgf@redhat.com> wrote: > On Mon, Apr 30, 2001 at
>01:05:17PM -0400, Andrew Cagney wrote:
>> >Christopher Faylor wrote:
>> >
>> >>         _WIN32          Pure WIN32 support 'gcc -mno-cygwin' --
>> >>                         don't know if it even builds.  _WIN32 is
>> >>                         now no longer defined by gcc.
>> >
>> >So, can I delete this one? :-)
>> 
>> I don't know.  Someone used to maintain a non-cygwin Windows version of
>> gdb.  I don't know if it even builds, like I said.  I'm not even sure
>> how to configure it.
>> 
>> Perhaps the people at mingw-users@lists.sourceforge.net know the answer
>> to this?  I've Cc'ed them.
>
>The last non-cygwin windows version of gdb that I know of is 4.18 which Mumit
>made available here: 
> ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/ports
>
>The diff file for that port is dated May 1999.
>
>I have just started work on gdb 5.0 for mingw. I have not gotten far, mainly
>because of lack of time.  Has anyone else made progress.

If you are at least considering this, then it sounds like the _WIN32 conditionals
in gdb sources should not be removed.

I assume that they will be required if you build a no-cygwin version of gdb,
correct?

cgf

Re: [Mingw-users] Re: _WIN32?

[Danny Smith]

--- Christopher Faylor <cgf@redhat.com> wrote: > On Tue, May 01, 2001 at
09:19:39AM +1000, Danny Smith wrote:
> >
> >--- Christopher Faylor <cgf@redhat.com> wrote: > On Mon, Apr 30, 2001 at
> >01:05:17PM -0400, Andrew Cagney wrote:
> >> >Christopher Faylor wrote:
> >> >
> >> >>         _WIN32          Pure WIN32 support 'gcc -mno-cygwin' --
> >> >>                         don't know if it even builds.  _WIN32 is
> >> >>                         now no longer defined by gcc.
> >> >
> >> >So, can I delete this one? :-)
> >> 
> >> I don't know.  Someone used to maintain a non-cygwin Windows version of
> >> gdb.  I don't know if it even builds, like I said.  I'm not even sure
> >> how to configure it.
> >> 
> >> Perhaps the people at mingw-users@lists.sourceforge.net know the answer
> >> to this?  I've Cc'ed them.
> >
> >The last non-cygwin windows version of gdb that I know of is 4.18 which
> Mumit
> >made available here: 
> > ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/ports
> >
> >The diff file for that port is dated May 1999.
> >
> >I have just started work on gdb 5.0 for mingw. I have not gotten far, mainly
> >because of lack of time.  Has anyone else made progress.
> 
> If you are at least considering this, then it sounds like the _WIN32
> conditionals
> in gdb sources should not be removed.
> 
> I assume that they will be required if you build a no-cygwin version of gdb,
> correct?
> 

Correct.  
Danny



_____________________________________________________________________________
http://store.yahoo.com.au - Yahoo! Store
- It's time you had your business online!

Re: [Mingw-users] Re: _WIN32?

[Kai Ruottu]

Christopher Faylor wrote:

> On Tue, May 01, 2001 at 09:19:39AM +1000, Danny Smith wrote:
> >
> >--- Christopher Faylor <cgf@redhat.com> wrote: > On Mon, Apr 30, 2001 at
> >01:05:17PM -0400, Andrew Cagney wrote:
> >> >Christopher Faylor wrote:
> >> >
> >> >>         _WIN32          Pure WIN32 support 'gcc -mno-cygwin' --
> >> >>                         don't know if it even builds.  _WIN32 is
> >> >>                         now no longer defined by gcc.
> >> >
> >> >So, can I delete this one? :-)
> >>
> >> I don't know.  Someone used to maintain a non-cygwin Windows version of
> >> gdb.  I don't know if it even builds, like I said.  I'm not even sure
> >> how to configure it.

 Perhaps this 'MSC_VER'-one, as the more detailed #ifdef's define it,
may be
removed. For me the _WIN32 has always been unclear.  It is more clear to
use
the '__CYGWIN32__' and '__MINGW32__' than the 'combined' _WIN32 meaning
them
both (at least earlier).

 If a port, another than for GCC, would be needed, let it at least be
for the
free or very cheap (coming with books and magazines) Borland
compilers(5.5 and
CodeBuilders), not for the very expensive MS-ones....

> >The last non-cygwin windows version of gdb that I know of is 4.18 which Mumit
> >made available here:
> > ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/ports
> >
> >The diff file for that port is dated May 1999.
> >
> >I have just started work on gdb 5.0 for mingw. I have not gotten far, mainly
> >because of lack of time.  Has anyone else made progress.

 Yes, with both 4.18.x and 5.0  using the Insight-derivation. The
snapshots
weren't yet looked by me but I wouldn't expect big surprises. In order
to get
something to download, I put the latest incarnations of these (the
binaries,
DLLs and scripts, some of these a year or more old though) for download
via
my new homepage :

     http://koti.mbnet.fi/"karuottu

 Perhaps some day I will try to collect the diffs against something (may
be
hard when adapting stuff when needed from the snapshots has been my
habit...)

> If you are at least considering this, then it sounds like the _WIN32 conditionals
> in gdb sources should not be removed.
>
> I assume that they will be required if you build a no-cygwin version of gdb,
> correct?

 As said, they just make the things more unclear. Questions like "Does
this work
under Cygwin, Mingw, MSVC++, BorlandC++, WatcomC,... ?" do arise,
because the
_WIN32 seems to mean them all. If only the Cygwin and Mingw ports are
only used
to compile GDB/Insight, why not use only the '__CYGWIN32__' and
'__MINGW32__' ?

 Removing the special Cygwin '_imp____cygwin_environ' etc. stuff, still
in the
snapshots (e.g. 'tcl/generic/tclEnv.c') when I last saw them, should be
sane...
These things should be defined in the Cygwin standard headers, not in
the GDB/tcl/tk/tix/itcl etc. sources. I'm quite sure I stripped all
these kind of
stuff for Mingw away, it already being defined in the standard
headers...

Cheers, Kai

Re: [Mingw-users] Re: _WIN32?

[Christopher Faylor]

On Tue, May 01, 2001 at 05:01:00PM +0300, Kai Ruottu wrote:
>Christopher Faylor wrote:
>>On Tue, May 01, 2001 at 09:19:39AM +1000, Danny Smith wrote:
>>>
>>>--- Christopher Faylor <cgf@redhat.com> wrote: > On Mon, Apr 30, 2001
>>>at 01:05:17PM -0400, Andrew Cagney wrote:
>>>>>Christopher Faylor wrote:
>>>>>
>>>>>>_WIN32          Pure WIN32 support 'gcc -mno-cygwin' --
>>>>>>don't know if it even builds.  _WIN32 is now no longer defined by gcc.
>>>>>
>>>>>So, can I delete this one?  :-)
>>>>
>>>>I don't know.  Someone used to maintain a non-cygwin Windows version of
>>>>gdb.  I don't know if it even builds, like I said.  I'm not even sure
>>>>how to configure it.
>
>Perhaps this 'MSC_VER'-one, as the more detailed #ifdef's define it,
>may be removed.  For me the _WIN32 has always been unclear.  It is more
>clear to use the '__CYGWIN32__' and '__MINGW32__' than the 'combined'
>_WIN32 meaning them both (at least earlier).
>
>If a port, another than for GCC, would be needed, let it at least be
>for the free or very cheap (coming with books and magazines) Borland
>compilers(5.5 and CodeBuilders), not for the very expensive MS-ones....

>>If you are at least considering this, then it sounds like the _WIN32
>>conditionals in gdb sources should not be removed.
>>
>>I assume that they will be required if you build a no-cygwin version of
>>gdb, correct?
>
>As said, they just make the things more unclear.  Questions like "Does
>this work under Cygwin, Mingw, MSVC++, BorlandC++, WatcomC,...  ?" do
>arise, because the _WIN32 seems to mean them all.  If only the Cygwin
>and Mingw ports are only used to compile GDB/Insight, why not use only
>the '__CYGWIN32__' and '__MINGW32__' ?
>
>Removing the special Cygwin '_imp____cygwin_environ' etc.  stuff, still
>in the snapshots (e.g.  'tcl/generic/tclEnv.c') when I last saw them,
>should be sane...  These things should be defined in the Cygwin
>standard headers, not in the GDB/tcl/tk/tix/itcl etc.  sources.  I'm
>quite sure I stripped all these kind of stuff for Mingw away, it
>already being defined in the standard headers...

Unfortunately, unless you are going to be doing this, none of it is
going to get done.  We aren't looking for volunteers with suggestions,
we're looking for volunteers willing to do the work.

I'm the Cygwin/Windows maintainer but I am really not interested in
getting a non-Cygwin version of gdb working.

If you have patches available against the current CVS sources, please
submit them to gdb-patches@sources.redhat.com and
insight@sources.redhat.com and I will evaluate them.

cgf

RE: MACROS in gdb ???

[Aditya Chugh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2607 bytes --]

Title: RE: MACROS in gdb ???





Hello Jtc,
Many thanks for your help.
The target I'm using is a Linux machine 
running kernel version 2.2.16-22(Red Hat Linux release 7.0)
and the version of gdb is 5.0.


Also the gdb output looked like this....?
(gdb) p u2IncarnId
$2 = 0
(gdb) n
(gdb) p u2IncarnId
$3 = 1
(gdb) p &u2IncarnId
Address requested for identifier "u2IncarnId" which is in a register.
(gdb)


I found that one of the Makefiles I was using has
CCFLAGS  = -O2 -Wall.After removing the -O2 the problem seems to have been resolved.


But does this mean that if we complile using GNU CC with both `-g'  and `-O' options
GDB will give us wrong results ?? Moreover the same code when run in Visual Studio 6.0
prints correct values for u2IncarnId.Does this mean that the debugger in Visual Studio 6.0
is better than GDB for optimized code ? It comes as quite a sock to me ?
Any more thoughts ???
with sincere thanks,
Aditya




-----Original Message-----
From: jtc@redback.com [ mailto:jtc@redback.com ]
Sent: Tuesday, March 20, 2001 4:12 AM
To: Aditya Chugh
Cc: bug-gdb@prep.ai.mit.edu; gdb@sourceware.cygnus.com
Subject: Re: MACROS in gdb ???




>>>>> "Aditya" == Aditya Chugh <Aditya@in.huawei.com> writes:
Aditya> I am not sure this is the right forum for a question on gdb.


I have culled the 'cc' list to the most relevant mailing lists.


Aditya> I am a Newbie as far as gdb is concerned.  But I have been
Aditya> struggling with this for quite some time and would sincerely
Aditya> appreciate any help.


Aditya> But after processing this macro the value of u2IncarnId
Aditya> changes unexplicably ????


You don't mention what target you're using or what optimization level
was used when you compiled the files.  But the symptoms you describe
often occur when debugging optimized code.  


For example if a register is being used to hold a value and then that
value is no longer needed in the rest of the function, a compiler may
choose to use that register for an unrelated value.  This can make
debugging a bit of a challenge, but looking at a disassembly of the
function or recompiling the system with no optimization can be used to
help diagnose the problem.


It helps to have a somewhat "flexible" attitude when it comes to
debugging optimized code.  A rigid interpretation of results will
lead to frustration.


Aditya> If I am missing something obvious please forgive me. I have
Aditya> spent the whole day trying to figure out where I am going
Aditya> wrong.


I hope this helps.  


        --jtc


-- 
J.T. Conklin
RedBack Networks

Re: MACROS in gdb ???

[J.T. Conklin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2384 bytes --]

While others have provided solid answers, I might as well add my two
bits to close this thread.

>>>>> "Aditya" == Aditya Chugh <Aditya@in.huawei.com> writes:
Aditya> I found that one of the Makefiles I was using has CCFLAGS  =
Aditya> -O2 -Wall.After removing the -O2 the problem seems to have
Aditya> been resolved.
Aditya>
Aditya> But does this mean that if we complile using GNU CC with both
Aditya> `-g'  and `-O' options GDB will give us wrong results ??

It can.  

There are several reasons for this.  In some cases the compiler does
not provide the necessary debug information to the debugger, in other
cases the debugger does not interpret the debug info properly, and in
other the debug info format is not rich enough to describe the optim-
ization done by the compiler.  When you are working on a problem, it
really doesn't matter why (although on some targets it's possible to
switch debug formats, for example from stabs to dwarf2), it's just 
something you have to adapt to.

Aditya> Moreover the same code when run in Visual Studio 6.0 prints
Aditya> correct values for u2IncarnId.Does this mean that the debugger
Aditya> in Visual Studio 6.0 is better than GDB for optimized code ?

I'm not familiar enough with Visual Studio 6.0 to say.  Note that in
some compilers, selecting debug options either disable outright or de-
tunes the optimizer so the debug info and the code generated match.
You could verify this by comparing the output of the VS6.0 compiler
when the debug options is turned on and when it is turned off.

Aditya> It comes as quite a sock to me ?  Any more thoughts ???  with
Aditya> sincere thanks, Aditya

Only what's already been said.  

  * It is possible to debug optimized code if you recognize that the 
    source code isn't going to match the generated code.  Variables 
    may contain the wrong value, or perhaps be even optimized out of
    existance.

  * If it's not possible to debug optimized code, recompile your
    application without optimization.  Some bugs might magically "go
    away" (actually, they're still lurking) since the code isn't the
    same.  I find that algorithm botches usually show up bright and
    clear, it's the memory corruption bugs that evade detection.

  * And if you know what module(s) is botched, just recompile those.

Hope this helps,

        --jtc
    
-- 
J.T. Conklin
RedBack Networks

RE: MACROS in gdb ???

[Eli Zaretskii]

On Tue, 20 Mar 2001, Aditya Chugh wrote:

> (gdb) p &u2IncarnId
> Address requested for identifier "u2IncarnId" which is in a register.

Alternatively, "info address u2IncarnId" will tell you explicitly
where the variable is stored.

> But does this mean that if we complile using GNU CC with both `-g'  and `-O'
> options GDB will give us wrong results ??

No, it just means that debugging optimized code should be taken with a
grain of salt.  In particular, you should be very suspicious about
values of variables that are in registers: verify them with
independent evidence, such as (in this case) the info about the
arguments with which the function was called (type "info args"), or
evaluation of equivalent expressions which use only memory-based
variables.

> Moreover the same code when run in Visual Studio 6.0 prints correct
> values for u2IncarnId.Does this mean that the debugger in Visual
> Studio 6.0 is better than GDB for optimized code ?

Part of the blame lies with the compiler (which doesn't leave enough
info for the debugger to deal with register variables), part of the
problem is in the debugger.  As ABIs evolve, GDB development needs to
catch up, and it takes time.  (Note that when you debug with Visual 
Studio, you don't replace the debugger alone, you also use a different 
compiler.  So the comparison with GDB alone is not really fair.)

Also note that GCC doesn't change its code generation when it sees -g,
so you are actually debugging the same code which will run in the
production version.  Other compilers lower the optimization level or
disable optimizations completely when building a debug version, so you
are debugging a totally different code.  This is an important feature
of GCC and GDB, but it does come at a price.

(This is why I think your ``solution'' of disabling optimizations is
Bad Idea: you are debugging a program which is very different from the
production code that will actually run on your target system.)

One possibility to try is to compile your program with -gstabs+
instead of -g (unless your GCC is already configured to do that by
default).  That provides more elaborate debug info for GDB to work
with, but I'm not sure it will help in this particular case.

Re: MACROS in gdb ???

[Kevin Buettner]

On Mar 20, 11:23am, Eli Zaretskii wrote:

> (This is why I think your ``solution'' of disabling optimizations is
> Bad Idea: you are debugging a program which is very different from the
> production code that will actually run on your target system.)

A compromise solution is to only recompile those files that you think
you'll be actively debugging with a lower optimization level.  You
are still debugging a program which'll be different than the production
code, but only parts of it are different.

Also, it should be noted that it's frequently easier to just turn off
optimizations at times when the debugger is *really* needed and then
turn them back on again once the problem is solved.  (I usually make
an attempt at figuring out the problem in the optimized version; but
sometimes either there just isn't enough debug information or the
behavior is too confusing.  At that point, I'll recompile the source
file in question with lower optimization.)

Kevin

Re: MACROS in gdb ???

[Eli Zaretskii]

On Tue, 20 Mar 2001, Kevin Buettner wrote:

> I usually make an attempt at figuring out the problem in the
> optimized version; but sometimes either there just isn't enough
> debug information or the behavior is too confusing.  At that point,
> I'll recompile the source file in question with lower optimization.

Yes, I agree: turning off optimizations should be the last resort, if
debugging optimized code is so confusing that you can't figure out
what's going on.

I find that it is usually unnecessary to turn off optimizations,
except in very rare cases.

Re: MACROS in gdb ???

[Daniel Berlin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

Aditya Chugh <Aditya@in.huawei.com> writes:

> Hello Jtc,
> Many thanks for your help.
> The target I'm using is a Linux machine
> running kernel version 2.2.16-22(Red Hat Linux release 7.0)
> and the version of gdb is 5.0.
> 
> Also the gdb output looked like this....?
> (gdb) p u2IncarnId
> $2 = 0
> (gdb) n
> (gdb) p u2IncarnId
> $3 = 1
> (gdb) p &u2IncarnId
> Address requested for identifier "u2IncarnId" which is in a register.
> (gdb)
> 
> I found that one of the Makefiles I was using has
> CCFLAGS  = -O2 -Wall.After removing the -O2 the problem seems to have been
> resolved.
> 
> But does this mean that if we complile using GNU CC with both `-g'  and `-O'
> options
> GDB will give us wrong results ?? Moreover the same code when run in Visual
> Studio 6.0
> prints correct values for u2IncarnId.Does this mean that the debugger in
> Visual Studio 6.0
> is better than GDB for optimized code ? 
Right now?
Quite possibly.


Optimized debugging support in GDB is only really possible through
fully supporting things we don't fully support yet.
--Dan