_WIN32?

_WIN32?

[Andrew Cagney]

Hello,

utils.c contains:

#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.  */

Given the ``!defined (MPW)'' bit is about to go, I'm wondering if the
!defined(_WIN32) is needed?

Hmm, actually, I'm puzzled.  Can anyone fill in the gaps?
	
	__GO32__	djgpp I think
	__CYGWIN__	ok - cygwin
	__CYGWIN32__	ok - old __CYGWIN__
	_WIN32
	_WIN32_WCE
	__MSDOS__

enjoy,
	Andrew

Re: _WIN32?

[Mo DeJong]

On Tue, 17 Apr 2001, Andrew Cagney wrote:

> Hello,
> 
> utils.c contains:
> 
> #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.  */
> 
> Given the ``!defined (MPW)'' bit is about to go, I'm wondering if the
> !defined(_WIN32) is needed?
> 
> Hmm, actually, I'm puzzled.  Can anyone fill in the gaps?
> 	
> 	__GO32__	djgpp I think
> 	__CYGWIN__	ok - cygwin
> 	__CYGWIN32__	ok - old __CYGWIN__
> 	_WIN32
> 	_WIN32_WCE
> 	__MSDOS__
> 
> enjoy,
> 	Andrew

I think that -D_WIN32 is passed in the CFLAGS for the Windows
port of Tcl. If this is a file used in gdbtk, that might
explain where the _WIN32 define came from. The windows
build of Tcl also uses -DWIN32 if that helps.

Mo DeJong
Red Hat Inc

Re: _WIN32?

[Christopher Faylor]

On Tue, Apr 17, 2001 at 05:49:41PM -0400, Andrew Cagney wrote:
>utils.c contains:
>
>#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.  */
>
>Given the ``!defined (MPW)'' bit is about to go, I'm wondering if the
>!defined(_WIN32) is needed?
>
>Hmm, actually, I'm puzzled.  Can anyone fill in the gaps?
>	
	__GO32__	djgpp I think
	__CYGWIN__	ok - cygwin
	__CYGWIN32__	ok - old __CYGWIN__
	_WIN32		Pure WIN32 support 'gcc -mno-cygwin' --
			don't know if it even builds.  _WIN32 is
			now no longer defined by gcc.
	_WIN32_WCE	Windows CE
	__MSDOS__	Dunno

cgf

Re: _WIN32?

[DJ Delorie]

Andrew Cagney <ac131313@cygnus.com> writes:
> 	__GO32__	djgpp I think

DJGPP V1, also defined by DJGPP V2 for backwards compatibility.
__DJGPP__ is the current recommended symbol.

> 	_WIN32

These are the 'canonical' way of detecting a Windows native compiler
(MSVC, MinGW, cygwin with -mno-cygwin).

> 	__MSDOS__

DJGPP, Borland C, older MSC's, and other dos-hosted compilers.  This
is (was?) the canonical way of detecting any dos-hosted compiler
(compiler-independent filesystem issues, for example)

Re: _WIN32?

[Eli Zaretskii]

On 17 Apr 2001, DJ Delorie wrote:

> > 	__GO32__	djgpp I think
> 
> DJGPP V1, also defined by DJGPP V2 for backwards compatibility.
> __DJGPP__ is the current recommended symbol.

I don't like changing code just for the sake of changing, that's why I
consistently left the old __GO32__ symbol unless I had a good reason
for changing it into __DJGPP__ (e.g., if DJGPP v1.x behaved
differently from the current DJGPP versions).  You can never know:
someone, somewhere could still use ye olde v1.x of DJGPP.

> > 	__MSDOS__
> 
> DJGPP, Borland C, older MSC's, and other dos-hosted compilers.  This
> is (was?) the canonical way of detecting any dos-hosted compiler
> (compiler-independent filesystem issues, for example)

In some code I contributed, __MSDOS__ is used instead of __DJGPP__
where the underlying issue is not specific to DJGPP, but rather is
common to all MS-DOS-based compilers.  An example is some problem with
limitations of a 8+3 DOS filesystem, e.g. that file names like
`.gdbinit' are not allowed.

By contrast, I use __DJGPP__ for code that won't (or shouldn't) work
with anything but DJGPP.  An example is a snippet in
mant.c:maintenance_dump_me which uses SIGABRT instead of SIGQUIT, for
the reason explained in a comment there.

Re: _WIN32?

[Andrew Cagney]

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? :-)

	Andrew

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: _WIN32?

[Andrew Cagney]

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

Was there ever anything beyond the ledgendary wingdb (a long deleted
version of GDB that compiled and ran using the windows environment).

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

Hope so.  I wouldn't mind adding this cleanup to the 5.2 release
criteria.

	Andrew

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

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: [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?

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

[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 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: 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?

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

[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: 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?

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

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

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

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

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?

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

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

[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