* Re: [Mingw-users] Re: _WIN32? [not found] <200105010009.RAA12115@tully.CS.Berkeley.EDU> @ 2001-05-03 1:24 ` Paul Hilfinger 2001-05-03 13:41 ` Andrew Cagney 0 siblings, 1 reply; 121+ messages in thread From: Paul Hilfinger @ 2001-05-03 1:24 UTC (permalink / raw) To: Christopher Faylor, Danny Smith; +Cc: gdb, mingw-users, dewar 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-03 1:24 ` [Mingw-users] Re: _WIN32? Paul Hilfinger @ 2001-05-03 13:41 ` Andrew Cagney 2001-05-03 14:15 ` Danny Smith ` (2 more replies) 0 siblings, 3 replies; 121+ messages in thread From: Andrew Cagney @ 2001-05-03 13:41 UTC (permalink / raw) To: Paul Hilfinger; +Cc: Christopher Faylor, Danny Smith, gdb, mingw-users, dewar > 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-03 13:41 ` Andrew Cagney @ 2001-05-03 14:15 ` Danny Smith 2001-05-03 15:24 ` Andrew Cagney 2001-05-03 23:58 ` [Mingw-users] Re: _WIN32? Paul Hilfinger 2001-05-04 0:20 ` Eli Zaretskii 2 siblings, 1 reply; 121+ messages in thread From: Danny Smith @ 2001-05-03 14:15 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb, mingw-users --- 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! ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-03 14:15 ` Danny Smith @ 2001-05-03 15:24 ` Andrew Cagney 2001-05-03 15:54 ` Christopher Faylor ` (3 more replies) 0 siblings, 4 replies; 121+ messages in thread From: Andrew Cagney @ 2001-05-03 15:24 UTC (permalink / raw) To: Danny Smith; +Cc: gdb, mingw-users 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-03 15:24 ` Andrew Cagney @ 2001-05-03 15:54 ` Christopher Faylor 2001-05-03 16:11 ` Andrew Cagney 2001-05-04 2:19 ` Eli Zaretskii ` (2 subsequent siblings) 3 siblings, 1 reply; 121+ messages in thread From: Christopher Faylor @ 2001-05-03 15:54 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-03 15:54 ` Christopher Faylor @ 2001-05-03 16:11 ` Andrew Cagney 2001-05-04 2:17 ` Eli Zaretskii 0 siblings, 1 reply; 121+ messages in thread From: Andrew Cagney @ 2001-05-03 16:11 UTC (permalink / raw) To: Christopher Faylor; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-03 16:11 ` Andrew Cagney @ 2001-05-04 2:17 ` Eli Zaretskii 0 siblings, 0 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-04 2:17 UTC (permalink / raw) To: gdb > 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-03 15:24 ` Andrew Cagney 2001-05-03 15:54 ` Christopher Faylor @ 2001-05-04 2:19 ` Eli Zaretskii 2001-05-04 8:45 ` Christopher Faylor 2001-05-07 9:08 ` Eli Zaretskii 2001-05-07 9:09 ` [RFA] Remove OS-specific defines (was: _WIN32?) Eli Zaretskii 3 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-04 2:19 UTC (permalink / raw) To: gdb > 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-04 2:19 ` Eli Zaretskii @ 2001-05-04 8:45 ` Christopher Faylor 2001-05-04 10:18 ` Eli Zaretskii 0 siblings, 1 reply; 121+ messages in thread From: Christopher Faylor @ 2001-05-04 8:45 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-04 8:45 ` Christopher Faylor @ 2001-05-04 10:18 ` Eli Zaretskii 2001-05-04 12:04 ` Christopher Faylor 0 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-04 10:18 UTC (permalink / raw) To: cgf; +Cc: gdb > 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-04 10:18 ` Eli Zaretskii @ 2001-05-04 12:04 ` Christopher Faylor 0 siblings, 0 replies; 121+ messages in thread From: Christopher Faylor @ 2001-05-04 12:04 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-03 15:24 ` Andrew Cagney 2001-05-03 15:54 ` Christopher Faylor 2001-05-04 2:19 ` Eli Zaretskii @ 2001-05-07 9:08 ` Eli Zaretskii 2001-05-08 4:38 ` DOS/Windows-specific code (was: _WIN32?) Eli Zaretskii ` (15 more replies) 2001-05-07 9:09 ` [RFA] Remove OS-specific defines (was: _WIN32?) Eli Zaretskii 3 siblings, 16 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-07 9:08 UTC (permalink / raw) To: ac131313; +Cc: danny_r_smith_2001, gdb, mingw-users > 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code (was: _WIN32?) 2001-05-07 9:08 ` Eli Zaretskii @ 2001-05-08 4:38 ` Eli Zaretskii 2001-05-08 4:40 ` DOS/Windows-specific code: cli-cmds.c Eli Zaretskii ` (14 subsequent siblings) 15 siblings, 0 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:38 UTC (permalink / raw) To: gdb; +Cc: ac131313 > 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code: cli-cmds.c 2001-05-07 9:08 ` Eli Zaretskii 2001-05-08 4:38 ` DOS/Windows-specific code (was: _WIN32?) Eli Zaretskii @ 2001-05-08 4:40 ` Eli Zaretskii 2001-05-08 5:07 ` Registers are not available in Cygwin leonp ` (2 more replies) 2001-05-08 4:42 ` DOS/Windows-specific code: exec.c and symfile.c Eli Zaretskii ` (13 subsequent siblings) 15 siblings, 3 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:40 UTC (permalink / raw) To: gdb; +Cc: ac131313 * 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)? ^ permalink raw reply [flat|nested] 121+ messages in thread
* Registers are not available in Cygwin 2001-05-08 4:40 ` DOS/Windows-specific code: cli-cmds.c Eli Zaretskii @ 2001-05-08 5:07 ` leonp 2001-05-08 7:16 ` DOS/Windows-specific code: cli-cmds.c Christopher Faylor 2001-05-08 17:56 ` Andrew Cagney 2 siblings, 0 replies; 121+ messages in thread From: leonp @ 2001-05-08 5:07 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: cli-cmds.c 2001-05-08 4:40 ` DOS/Windows-specific code: cli-cmds.c Eli Zaretskii 2001-05-08 5:07 ` Registers are not available in Cygwin leonp @ 2001-05-08 7:16 ` Christopher Faylor 2001-05-08 17:51 ` Andrew Cagney 2001-05-08 17:56 ` Andrew Cagney 2 siblings, 1 reply; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 7:16 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: cli-cmds.c 2001-05-08 7:16 ` DOS/Windows-specific code: cli-cmds.c Christopher Faylor @ 2001-05-08 17:51 ` Andrew Cagney 2001-05-08 17:53 ` Christopher Faylor 2001-05-09 3:02 ` Eli Zaretskii 0 siblings, 2 replies; 121+ messages in thread From: Andrew Cagney @ 2001-05-08 17:51 UTC (permalink / raw) To: Christopher Faylor; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: cli-cmds.c 2001-05-08 17:51 ` Andrew Cagney @ 2001-05-08 17:53 ` Christopher Faylor 2001-05-09 3:02 ` Eli Zaretskii 1 sibling, 0 replies; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 17:53 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: cli-cmds.c 2001-05-08 17:51 ` Andrew Cagney 2001-05-08 17:53 ` Christopher Faylor @ 2001-05-09 3:02 ` Eli Zaretskii 2001-05-10 8:33 ` Andrew Cagney 1 sibling, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-09 3:02 UTC (permalink / raw) To: Andrew Cagney; +Cc: Christopher Faylor, gdb 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: cli-cmds.c 2001-05-09 3:02 ` Eli Zaretskii @ 2001-05-10 8:33 ` Andrew Cagney 0 siblings, 0 replies; 121+ messages in thread From: Andrew Cagney @ 2001-05-10 8:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Christopher Faylor, gdb > 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: cli-cmds.c 2001-05-08 4:40 ` DOS/Windows-specific code: cli-cmds.c Eli Zaretskii 2001-05-08 5:07 ` Registers are not available in Cygwin leonp 2001-05-08 7:16 ` DOS/Windows-specific code: cli-cmds.c Christopher Faylor @ 2001-05-08 17:56 ` Andrew Cagney 2001-05-09 3:03 ` Eli Zaretskii 2 siblings, 1 reply; 121+ messages in thread From: Andrew Cagney @ 2001-05-08 17:56 UTC (permalink / raw) To: Eli Zaretskii, gdb > * 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: cli-cmds.c 2001-05-08 17:56 ` Andrew Cagney @ 2001-05-09 3:03 ` Eli Zaretskii 2001-05-09 9:10 ` Andrew Cagney 0 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-09 3:03 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: cli-cmds.c 2001-05-09 3:03 ` Eli Zaretskii @ 2001-05-09 9:10 ` Andrew Cagney 0 siblings, 0 replies; 121+ messages in thread From: Andrew Cagney @ 2001-05-09 9:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code: exec.c and symfile.c 2001-05-07 9:08 ` Eli Zaretskii 2001-05-08 4:38 ` DOS/Windows-specific code (was: _WIN32?) Eli Zaretskii 2001-05-08 4:40 ` DOS/Windows-specific code: cli-cmds.c Eli Zaretskii @ 2001-05-08 4:42 ` Eli Zaretskii 2001-05-08 7:43 ` Elena Zannoni 2001-05-08 17:58 ` Andrew Cagney 2001-05-08 4:43 ` DOS/Windows-specific code: inflow.c Eli Zaretskii ` (12 subsequent siblings) 15 siblings, 2 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:42 UTC (permalink / raw) To: gdb; +Cc: ac131313 * 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: exec.c and symfile.c 2001-05-08 4:42 ` DOS/Windows-specific code: exec.c and symfile.c Eli Zaretskii @ 2001-05-08 7:43 ` Elena Zannoni 2001-05-08 17:58 ` Andrew Cagney 1 sibling, 0 replies; 121+ messages in thread From: Elena Zannoni @ 2001-05-08 7:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb, ac131313 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. > ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: exec.c and symfile.c 2001-05-08 4:42 ` DOS/Windows-specific code: exec.c and symfile.c Eli Zaretskii 2001-05-08 7:43 ` Elena Zannoni @ 2001-05-08 17:58 ` Andrew Cagney 2001-05-09 3:03 ` Eli Zaretskii 1 sibling, 1 reply; 121+ messages in thread From: Andrew Cagney @ 2001-05-08 17:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: exec.c and symfile.c 2001-05-08 17:58 ` Andrew Cagney @ 2001-05-09 3:03 ` Eli Zaretskii 2001-05-09 7:07 ` Christopher Faylor 0 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-09 3:03 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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.) ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: exec.c and symfile.c 2001-05-09 3:03 ` Eli Zaretskii @ 2001-05-09 7:07 ` Christopher Faylor 0 siblings, 0 replies; 121+ messages in thread From: Christopher Faylor @ 2001-05-09 7:07 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code: inflow.c 2001-05-07 9:08 ` Eli Zaretskii ` (2 preceding siblings ...) 2001-05-08 4:42 ` DOS/Windows-specific code: exec.c and symfile.c Eli Zaretskii @ 2001-05-08 4:43 ` Eli Zaretskii 2001-05-08 7:54 ` Christopher Faylor 2001-05-08 4:46 ` DOS/Windows-specific code: main.c Eli Zaretskii ` (11 subsequent siblings) 15 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:43 UTC (permalink / raw) To: gdb; +Cc: ac131313 * 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: inflow.c 2001-05-08 4:43 ` DOS/Windows-specific code: inflow.c Eli Zaretskii @ 2001-05-08 7:54 ` Christopher Faylor 2001-05-08 11:15 ` Eli Zaretskii 0 siblings, 1 reply; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 7:54 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: inflow.c 2001-05-08 7:54 ` Christopher Faylor @ 2001-05-08 11:15 ` Eli Zaretskii 2001-05-09 13:10 ` Christopher Faylor 0 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 11:15 UTC (permalink / raw) To: cgf; +Cc: gdb > 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: inflow.c 2001-05-08 11:15 ` Eli Zaretskii @ 2001-05-09 13:10 ` Christopher Faylor 0 siblings, 0 replies; 121+ messages in thread From: Christopher Faylor @ 2001-05-09 13:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code: main.c 2001-05-07 9:08 ` Eli Zaretskii ` (3 preceding siblings ...) 2001-05-08 4:43 ` DOS/Windows-specific code: inflow.c Eli Zaretskii @ 2001-05-08 4:46 ` Eli Zaretskii 2001-05-08 7:58 ` Christopher Faylor 2001-05-08 4:46 ` DOS/Windows-specific code: maint.c Eli Zaretskii ` (10 subsequent siblings) 15 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:46 UTC (permalink / raw) To: gdb; +Cc: ac131313 * 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: main.c 2001-05-08 4:46 ` DOS/Windows-specific code: main.c Eli Zaretskii @ 2001-05-08 7:58 ` Christopher Faylor 2001-05-08 8:17 ` Keith Seitz 0 siblings, 1 reply; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 7:58 UTC (permalink / raw) To: gdb; +Cc: keiths 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: main.c 2001-05-08 7:58 ` Christopher Faylor @ 2001-05-08 8:17 ` Keith Seitz 2001-05-08 8:19 ` Christopher Faylor 0 siblings, 1 reply; 121+ messages in thread From: Keith Seitz @ 2001-05-08 8:17 UTC (permalink / raw) To: Christopher Faylor; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: main.c 2001-05-08 8:17 ` Keith Seitz @ 2001-05-08 8:19 ` Christopher Faylor 0 siblings, 0 replies; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 8:19 UTC (permalink / raw) To: Keith Seitz; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code: maint.c 2001-05-07 9:08 ` Eli Zaretskii ` (4 preceding siblings ...) 2001-05-08 4:46 ` DOS/Windows-specific code: main.c Eli Zaretskii @ 2001-05-08 4:46 ` Eli Zaretskii 2001-05-08 23:40 ` Kevin Buettner 2001-05-10 8:33 ` Andrew Cagney 2001-05-08 4:47 ` DOS/Windows-specific code: source.c Eli Zaretskii ` (9 subsequent siblings) 15 siblings, 2 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:46 UTC (permalink / raw) To: gdb; +Cc: ac131313 * 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: maint.c 2001-05-08 4:46 ` DOS/Windows-specific code: maint.c Eli Zaretskii @ 2001-05-08 23:40 ` Kevin Buettner 2001-05-09 3:22 ` Eli Zaretskii 2001-05-10 8:33 ` Andrew Cagney 1 sibling, 1 reply; 121+ messages in thread From: Kevin Buettner @ 2001-05-08 23:40 UTC (permalink / raw) To: Eli Zaretskii, gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: maint.c 2001-05-08 23:40 ` Kevin Buettner @ 2001-05-09 3:22 ` Eli Zaretskii 0 siblings, 0 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-09 3:22 UTC (permalink / raw) To: Kevin Buettner; +Cc: gdb 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: maint.c 2001-05-08 4:46 ` DOS/Windows-specific code: maint.c Eli Zaretskii 2001-05-08 23:40 ` Kevin Buettner @ 2001-05-10 8:33 ` Andrew Cagney 2001-05-10 8:53 ` Eli Zaretskii 1 sibling, 1 reply; 121+ messages in thread From: Andrew Cagney @ 2001-05-10 8:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb > #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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: maint.c 2001-05-10 8:33 ` Andrew Cagney @ 2001-05-10 8:53 ` Eli Zaretskii 0 siblings, 0 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-10 8:53 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code: source.c 2001-05-07 9:08 ` Eli Zaretskii ` (5 preceding siblings ...) 2001-05-08 4:46 ` DOS/Windows-specific code: maint.c Eli Zaretskii @ 2001-05-08 4:47 ` Eli Zaretskii 2001-05-08 9:30 ` DJ Delorie 2001-05-08 11:14 ` Christopher Faylor 2001-05-08 4:48 ` DOS/Windows-specific code: terminal.h Eli Zaretskii ` (8 subsequent siblings) 15 siblings, 2 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:47 UTC (permalink / raw) To: gdb; +Cc: ac131313 * 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.) ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: source.c 2001-05-08 4:47 ` DOS/Windows-specific code: source.c Eli Zaretskii @ 2001-05-08 9:30 ` DJ Delorie 2001-05-08 11:18 ` Christopher Faylor 2001-05-08 11:14 ` Christopher Faylor 1 sibling, 1 reply; 121+ messages in thread From: DJ Delorie @ 2001-05-08 9:30 UTC (permalink / raw) To: gdb 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: source.c 2001-05-08 9:30 ` DJ Delorie @ 2001-05-08 11:18 ` Christopher Faylor 2001-05-08 12:23 ` Eli Zaretskii 0 siblings, 1 reply; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 11:18 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: source.c 2001-05-08 11:18 ` Christopher Faylor @ 2001-05-08 12:23 ` Eli Zaretskii 2001-05-08 14:00 ` DJ Delorie 0 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 12:23 UTC (permalink / raw) To: cgf; +Cc: gdb > 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: source.c 2001-05-08 12:23 ` Eli Zaretskii @ 2001-05-08 14:00 ` DJ Delorie 2001-05-09 3:05 ` Eli Zaretskii 0 siblings, 1 reply; 121+ messages in thread From: DJ Delorie @ 2001-05-08 14:00 UTC (permalink / raw) To: gdb "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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: source.c 2001-05-08 14:00 ` DJ Delorie @ 2001-05-09 3:05 ` Eli Zaretskii 2001-05-09 7:08 ` Christopher Faylor 0 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-09 3:05 UTC (permalink / raw) To: DJ Delorie; +Cc: gdb 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: source.c 2001-05-09 3:05 ` Eli Zaretskii @ 2001-05-09 7:08 ` Christopher Faylor 0 siblings, 0 replies; 121+ messages in thread From: Christopher Faylor @ 2001-05-09 7:08 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: source.c 2001-05-08 4:47 ` DOS/Windows-specific code: source.c Eli Zaretskii 2001-05-08 9:30 ` DJ Delorie @ 2001-05-08 11:14 ` Christopher Faylor 2001-05-08 12:25 ` Eli Zaretskii 1 sibling, 1 reply; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 11:14 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: source.c 2001-05-08 11:14 ` Christopher Faylor @ 2001-05-08 12:25 ` Eli Zaretskii 2001-05-08 12:33 ` Christopher Faylor 0 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 12:25 UTC (permalink / raw) To: cgf; +Cc: gdb > 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: source.c 2001-05-08 12:25 ` Eli Zaretskii @ 2001-05-08 12:33 ` Christopher Faylor 2001-05-09 3:05 ` Eli Zaretskii 0 siblings, 1 reply; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 12:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: source.c 2001-05-08 12:33 ` Christopher Faylor @ 2001-05-09 3:05 ` Eli Zaretskii 0 siblings, 0 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-09 3:05 UTC (permalink / raw) To: Christopher Faylor; +Cc: gdb 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code: terminal.h 2001-05-07 9:08 ` Eli Zaretskii ` (6 preceding siblings ...) 2001-05-08 4:47 ` DOS/Windows-specific code: source.c Eli Zaretskii @ 2001-05-08 4:48 ` Eli Zaretskii 2001-05-08 11:18 ` Christopher Faylor 2001-05-08 4:48 ` DOS/Windows-specific code: sparcl-tdep.c Eli Zaretskii ` (7 subsequent siblings) 15 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:48 UTC (permalink / raw) To: gdb; +Cc: ac131313 * 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: terminal.h 2001-05-08 4:48 ` DOS/Windows-specific code: terminal.h Eli Zaretskii @ 2001-05-08 11:18 ` Christopher Faylor 0 siblings, 0 replies; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 11:18 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code: sparcl-tdep.c 2001-05-07 9:08 ` Eli Zaretskii ` (7 preceding siblings ...) 2001-05-08 4:48 ` DOS/Windows-specific code: terminal.h Eli Zaretskii @ 2001-05-08 4:48 ` Eli Zaretskii 2001-05-08 23:47 ` Kevin Buettner 2001-05-08 4:50 ` DOS/Windows-specific code: top.c Eli Zaretskii ` (6 subsequent siblings) 15 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:48 UTC (permalink / raw) To: gdb; +Cc: ac131313 * 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: sparcl-tdep.c 2001-05-08 4:48 ` DOS/Windows-specific code: sparcl-tdep.c Eli Zaretskii @ 2001-05-08 23:47 ` Kevin Buettner 2001-05-09 3:14 ` Eli Zaretskii 2001-05-10 8:33 ` Andrew Cagney 0 siblings, 2 replies; 121+ messages in thread From: Kevin Buettner @ 2001-05-08 23:47 UTC (permalink / raw) To: Eli Zaretskii, gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: sparcl-tdep.c 2001-05-08 23:47 ` Kevin Buettner @ 2001-05-09 3:14 ` Eli Zaretskii 2001-05-10 8:33 ` Andrew Cagney 1 sibling, 0 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-09 3:14 UTC (permalink / raw) To: Kevin Buettner; +Cc: gdb 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: sparcl-tdep.c 2001-05-08 23:47 ` Kevin Buettner 2001-05-09 3:14 ` Eli Zaretskii @ 2001-05-10 8:33 ` Andrew Cagney 1 sibling, 0 replies; 121+ messages in thread From: Andrew Cagney @ 2001-05-10 8:33 UTC (permalink / raw) To: Kevin Buettner; +Cc: Eli Zaretskii, gdb > 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code: top.c 2001-05-07 9:08 ` Eli Zaretskii ` (8 preceding siblings ...) 2001-05-08 4:48 ` DOS/Windows-specific code: sparcl-tdep.c Eli Zaretskii @ 2001-05-08 4:50 ` Eli Zaretskii 2001-05-08 7:46 ` Elena Zannoni 2001-05-08 4:51 ` DOS/Windows-specific code: utils.c Eli Zaretskii ` (5 subsequent siblings) 15 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:50 UTC (permalink / raw) To: gdb; +Cc: ac131313 * 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? ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: top.c 2001-05-08 4:50 ` DOS/Windows-specific code: top.c Eli Zaretskii @ 2001-05-08 7:46 ` Elena Zannoni 0 siblings, 0 replies; 121+ messages in thread From: Elena Zannoni @ 2001-05-08 7:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb, ac131313 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code: utils.c 2001-05-07 9:08 ` Eli Zaretskii ` (9 preceding siblings ...) 2001-05-08 4:50 ` DOS/Windows-specific code: top.c Eli Zaretskii @ 2001-05-08 4:51 ` Eli Zaretskii 2001-05-08 11:26 ` Christopher Faylor 2001-05-08 4:52 ` DOS/Windows-specific code: ser-tcp.c Eli Zaretskii ` (4 subsequent siblings) 15 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:51 UTC (permalink / raw) To: gdb; +Cc: ac131313 * 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: utils.c 2001-05-08 4:51 ` DOS/Windows-specific code: utils.c Eli Zaretskii @ 2001-05-08 11:26 ` Christopher Faylor 0 siblings, 0 replies; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 11:26 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code: ser-tcp.c 2001-05-07 9:08 ` Eli Zaretskii ` (10 preceding siblings ...) 2001-05-08 4:51 ` DOS/Windows-specific code: utils.c Eli Zaretskii @ 2001-05-08 4:52 ` Eli Zaretskii 2001-05-08 5:56 ` Russ Allbery ` (3 more replies) 2001-05-08 4:52 ` DOS/Windows-specific code: sh-tdep.c and sh3-rom.c Eli Zaretskii ` (3 subsequent siblings) 15 siblings, 4 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:52 UTC (permalink / raw) To: gdb; +Cc: ac131313 * 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: ser-tcp.c 2001-05-08 4:52 ` DOS/Windows-specific code: ser-tcp.c Eli Zaretskii @ 2001-05-08 5:56 ` Russ Allbery 2001-05-08 6:01 ` Christopher Faylor ` (2 subsequent siblings) 3 siblings, 0 replies; 121+ messages in thread From: Russ Allbery @ 2001-05-08 5:56 UTC (permalink / raw) To: gdb 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/ > ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: ser-tcp.c 2001-05-08 4:52 ` DOS/Windows-specific code: ser-tcp.c Eli Zaretskii 2001-05-08 5:56 ` Russ Allbery @ 2001-05-08 6:01 ` Christopher Faylor 2001-05-08 8:09 ` Eli Zaretskii 2001-05-08 23:53 ` Kevin Buettner 2001-05-10 8:32 ` DOS/Windows-specific code: ser-tcp.c Andrew Cagney 3 siblings, 1 reply; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 6:01 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: ser-tcp.c 2001-05-08 6:01 ` Christopher Faylor @ 2001-05-08 8:09 ` Eli Zaretskii 2001-05-08 8:20 ` Christopher Faylor 0 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 8:09 UTC (permalink / raw) To: cgf; +Cc: gdb > > 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: ser-tcp.c 2001-05-08 8:09 ` Eli Zaretskii @ 2001-05-08 8:20 ` Christopher Faylor 2001-05-08 10:30 ` Eli Zaretskii 0 siblings, 1 reply; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 8:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: ser-tcp.c 2001-05-08 8:20 ` Christopher Faylor @ 2001-05-08 10:30 ` Eli Zaretskii 2001-05-08 11:03 ` Christopher Faylor 0 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 10:30 UTC (permalink / raw) To: cgf; +Cc: gdb > 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: ser-tcp.c 2001-05-08 10:30 ` Eli Zaretskii @ 2001-05-08 11:03 ` Christopher Faylor 0 siblings, 0 replies; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 11:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: ser-tcp.c 2001-05-08 4:52 ` DOS/Windows-specific code: ser-tcp.c Eli Zaretskii 2001-05-08 5:56 ` Russ Allbery 2001-05-08 6:01 ` Christopher Faylor @ 2001-05-08 23:53 ` Kevin Buettner 2001-05-09 6:59 ` DOS/Windows-specific code: ser-tcp.c [need ruling from Andrew] Christopher Faylor 2001-05-10 8:32 ` DOS/Windows-specific code: ser-tcp.c Andrew Cagney 3 siblings, 1 reply; 121+ messages in thread From: Kevin Buettner @ 2001-05-08 23:53 UTC (permalink / raw) To: Eli Zaretskii, gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: ser-tcp.c [need ruling from Andrew] 2001-05-08 23:53 ` Kevin Buettner @ 2001-05-09 6:59 ` Christopher Faylor 2001-05-09 9:29 ` Andrew Cagney 0 siblings, 1 reply; 121+ messages in thread From: Christopher Faylor @ 2001-05-09 6:59 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: ser-tcp.c [need ruling from Andrew] 2001-05-09 6:59 ` DOS/Windows-specific code: ser-tcp.c [need ruling from Andrew] Christopher Faylor @ 2001-05-09 9:29 ` Andrew Cagney 0 siblings, 0 replies; 121+ messages in thread From: Andrew Cagney @ 2001-05-09 9:29 UTC (permalink / raw) To: Christopher Faylor; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: ser-tcp.c 2001-05-08 4:52 ` DOS/Windows-specific code: ser-tcp.c Eli Zaretskii ` (2 preceding siblings ...) 2001-05-08 23:53 ` Kevin Buettner @ 2001-05-10 8:32 ` Andrew Cagney 3 siblings, 0 replies; 121+ messages in thread From: Andrew Cagney @ 2001-05-10 8:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb > * 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code: sh-tdep.c and sh3-rom.c 2001-05-07 9:08 ` Eli Zaretskii ` (11 preceding siblings ...) 2001-05-08 4:52 ` DOS/Windows-specific code: ser-tcp.c Eli Zaretskii @ 2001-05-08 4:52 ` Eli Zaretskii 2001-05-08 7:49 ` Elena Zannoni 2001-05-08 23:55 ` Kevin Buettner 2001-05-08 4:53 ` DOS/Windows-specific code: values.c Eli Zaretskii ` (2 subsequent siblings) 15 siblings, 2 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:52 UTC (permalink / raw) To: gdb; +Cc: ac131313 * 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c 2001-05-08 4:52 ` DOS/Windows-specific code: sh-tdep.c and sh3-rom.c Eli Zaretskii @ 2001-05-08 7:49 ` Elena Zannoni 2001-05-08 11:17 ` Eli Zaretskii 2001-05-08 12:35 ` Christopher Faylor 2001-05-08 23:55 ` Kevin Buettner 1 sibling, 2 replies; 121+ messages in thread From: Elena Zannoni @ 2001-05-08 7:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb, ac131313 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c 2001-05-08 7:49 ` Elena Zannoni @ 2001-05-08 11:17 ` Eli Zaretskii 2001-05-08 11:40 ` Elena Zannoni 2001-05-08 12:35 ` Christopher Faylor 1 sibling, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 11:17 UTC (permalink / raw) To: ezannoni; +Cc: gdb, ac131313 > 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c 2001-05-08 11:17 ` Eli Zaretskii @ 2001-05-08 11:40 ` Elena Zannoni 2001-05-08 12:36 ` Christopher Faylor 0 siblings, 1 reply; 121+ messages in thread From: Elena Zannoni @ 2001-05-08 11:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ezannoni, gdb, ac131313 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c 2001-05-08 11:40 ` Elena Zannoni @ 2001-05-08 12:36 ` Christopher Faylor 0 siblings, 0 replies; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 12:36 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c 2001-05-08 7:49 ` Elena Zannoni 2001-05-08 11:17 ` Eli Zaretskii @ 2001-05-08 12:35 ` Christopher Faylor 2001-05-08 18:17 ` Andrew Cagney 1 sibling, 1 reply; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 12:35 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c 2001-05-08 12:35 ` Christopher Faylor @ 2001-05-08 18:17 ` Andrew Cagney 2001-05-08 19:35 ` Christopher Faylor 0 siblings, 1 reply; 121+ messages in thread From: Andrew Cagney @ 2001-05-08 18:17 UTC (permalink / raw) To: Christopher Faylor; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c 2001-05-08 18:17 ` Andrew Cagney @ 2001-05-08 19:35 ` Christopher Faylor 0 siblings, 0 replies; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 19:35 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c 2001-05-08 4:52 ` DOS/Windows-specific code: sh-tdep.c and sh3-rom.c Eli Zaretskii 2001-05-08 7:49 ` Elena Zannoni @ 2001-05-08 23:55 ` Kevin Buettner 2001-05-09 3:20 ` Eli Zaretskii 1 sibling, 1 reply; 121+ messages in thread From: Kevin Buettner @ 2001-05-08 23:55 UTC (permalink / raw) To: Eli Zaretskii, gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c 2001-05-08 23:55 ` Kevin Buettner @ 2001-05-09 3:20 ` Eli Zaretskii 2001-05-09 7:49 ` Elena Zannoni 0 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-09 3:20 UTC (permalink / raw) To: Kevin Buettner; +Cc: gdb 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)." ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: sh-tdep.c and sh3-rom.c 2001-05-09 3:20 ` Eli Zaretskii @ 2001-05-09 7:49 ` Elena Zannoni 0 siblings, 0 replies; 121+ messages in thread From: Elena Zannoni @ 2001-05-09 7:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Kevin Buettner, gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code: values.c 2001-05-07 9:08 ` Eli Zaretskii ` (12 preceding siblings ...) 2001-05-08 4:52 ` DOS/Windows-specific code: sh-tdep.c and sh3-rom.c Eli Zaretskii @ 2001-05-08 4:53 ` Eli Zaretskii 2001-05-08 23:58 ` Kevin Buettner 2001-05-08 4:54 ` DOS/Windows-specific code in sim/ Eli Zaretskii 2001-05-08 4:55 ` DOS/Windows-specific code: all the rest Eli Zaretskii 15 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:53 UTC (permalink / raw) To: gdb; +Cc: ac131313 * 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! ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: values.c 2001-05-08 4:53 ` DOS/Windows-specific code: values.c Eli Zaretskii @ 2001-05-08 23:58 ` Kevin Buettner 2001-05-09 7:01 ` Christopher Faylor 2001-05-10 8:33 ` Andrew Cagney 0 siblings, 2 replies; 121+ messages in thread From: Kevin Buettner @ 2001-05-08 23:58 UTC (permalink / raw) To: Eli Zaretskii, gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: values.c 2001-05-08 23:58 ` Kevin Buettner @ 2001-05-09 7:01 ` Christopher Faylor 2001-05-10 8:33 ` Andrew Cagney 1 sibling, 0 replies; 121+ messages in thread From: Christopher Faylor @ 2001-05-09 7:01 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: values.c 2001-05-08 23:58 ` Kevin Buettner 2001-05-09 7:01 ` Christopher Faylor @ 2001-05-10 8:33 ` Andrew Cagney 1 sibling, 0 replies; 121+ messages in thread From: Andrew Cagney @ 2001-05-10 8:33 UTC (permalink / raw) To: Kevin Buettner; +Cc: Eli Zaretskii, gdb > 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code in sim/ 2001-05-07 9:08 ` Eli Zaretskii ` (13 preceding siblings ...) 2001-05-08 4:53 ` DOS/Windows-specific code: values.c Eli Zaretskii @ 2001-05-08 4:54 ` Eli Zaretskii 2001-05-08 9:30 ` DJ Delorie 2001-05-08 4:55 ` DOS/Windows-specific code: all the rest Eli Zaretskii 15 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:54 UTC (permalink / raw) To: gdb; +Cc: ac131313 * 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? ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code in sim/ 2001-05-08 4:54 ` DOS/Windows-specific code in sim/ Eli Zaretskii @ 2001-05-08 9:30 ` DJ Delorie 2001-05-08 11:04 ` Eli Zaretskii 2001-05-10 8:33 ` Andrew Cagney 0 siblings, 2 replies; 121+ messages in thread From: DJ Delorie @ 2001-05-08 9:30 UTC (permalink / raw) To: gdb 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... ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code in sim/ 2001-05-08 9:30 ` DJ Delorie @ 2001-05-08 11:04 ` Eli Zaretskii 2001-05-10 8:33 ` Andrew Cagney 1 sibling, 0 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 11:04 UTC (permalink / raw) To: dj; +Cc: gdb > 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? ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code in sim/ 2001-05-08 9:30 ` DJ Delorie 2001-05-08 11:04 ` Eli Zaretskii @ 2001-05-10 8:33 ` Andrew Cagney 1 sibling, 0 replies; 121+ messages in thread From: Andrew Cagney @ 2001-05-10 8:33 UTC (permalink / raw) To: DJ Delorie; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* DOS/Windows-specific code: all the rest 2001-05-07 9:08 ` Eli Zaretskii ` (14 preceding siblings ...) 2001-05-08 4:54 ` DOS/Windows-specific code in sim/ Eli Zaretskii @ 2001-05-08 4:55 ` Eli Zaretskii 2001-05-08 5:12 ` leonp 2001-05-08 9:45 ` DJ Delorie 15 siblings, 2 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 4:55 UTC (permalink / raw) To: gdb; +Cc: ac131313 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: all the rest 2001-05-08 4:55 ` DOS/Windows-specific code: all the rest Eli Zaretskii @ 2001-05-08 5:12 ` leonp 2001-05-08 7:59 ` Christopher Faylor 2001-05-08 9:45 ` DJ Delorie 1 sibling, 1 reply; 121+ messages in thread From: leonp @ 2001-05-08 5:12 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: all the rest 2001-05-08 5:12 ` leonp @ 2001-05-08 7:59 ` Christopher Faylor 0 siblings, 0 replies; 121+ messages in thread From: Christopher Faylor @ 2001-05-08 7:59 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: all the rest 2001-05-08 4:55 ` DOS/Windows-specific code: all the rest Eli Zaretskii 2001-05-08 5:12 ` leonp @ 2001-05-08 9:45 ` DJ Delorie 2001-05-08 10:53 ` Eli Zaretskii 1 sibling, 1 reply; 121+ messages in thread From: DJ Delorie @ 2001-05-08 9:45 UTC (permalink / raw) To: gdb 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: all the rest 2001-05-08 9:45 ` DJ Delorie @ 2001-05-08 10:53 ` Eli Zaretskii 2001-05-08 12:08 ` DJ Delorie 0 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-08 10:53 UTC (permalink / raw) To: dj; +Cc: gdb > 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? ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: DOS/Windows-specific code: all the rest 2001-05-08 10:53 ` Eli Zaretskii @ 2001-05-08 12:08 ` DJ Delorie 0 siblings, 0 replies; 121+ messages in thread From: DJ Delorie @ 2001-05-08 12:08 UTC (permalink / raw) To: eliz; +Cc: gdb > 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* [RFA] Remove OS-specific defines (was: _WIN32?) 2001-05-03 15:24 ` Andrew Cagney ` (2 preceding siblings ...) 2001-05-07 9:08 ` Eli Zaretskii @ 2001-05-07 9:09 ` Eli Zaretskii 2001-05-07 10:39 ` Kevin Buettner 3 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-07 9:09 UTC (permalink / raw) To: ac131313; +Cc: danny_r_smith_2001, gdb, mingw-users 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); } ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [RFA] Remove OS-specific defines (was: _WIN32?) 2001-05-07 9:09 ` [RFA] Remove OS-specific defines (was: _WIN32?) Eli Zaretskii @ 2001-05-07 10:39 ` Kevin Buettner 2001-05-07 11:23 ` Eli Zaretskii 0 siblings, 1 reply; 121+ messages in thread From: Kevin Buettner @ 2001-05-07 10:39 UTC (permalink / raw) To: Eli Zaretskii, ac131313; +Cc: danny_r_smith_2001, gdb, mingw-users 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [RFA] Remove OS-specific defines (was: _WIN32?) 2001-05-07 10:39 ` Kevin Buettner @ 2001-05-07 11:23 ` Eli Zaretskii 2001-05-07 11:37 ` Andrew Cagney 0 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-07 11:23 UTC (permalink / raw) To: kevinb; +Cc: ac131313, danny_r_smith_2001, gdb > 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? ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [RFA] Remove OS-specific defines (was: _WIN32?) 2001-05-07 11:23 ` Eli Zaretskii @ 2001-05-07 11:37 ` Andrew Cagney 0 siblings, 0 replies; 121+ messages in thread From: Andrew Cagney @ 2001-05-07 11:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: kevinb, danny_r_smith_2001, gdb >> 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-03 13:41 ` Andrew Cagney 2001-05-03 14:15 ` Danny Smith @ 2001-05-03 23:58 ` Paul Hilfinger 2001-05-04 9:04 ` Andrew Cagney 2001-05-04 0:20 ` Eli Zaretskii 2 siblings, 1 reply; 121+ messages in thread From: Paul Hilfinger @ 2001-05-03 23:58 UTC (permalink / raw) To: ac131313; +Cc: cgf, danny_r_smith_2001, gdb, mingw-users, dewar > 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-03 23:58 ` [Mingw-users] Re: _WIN32? Paul Hilfinger @ 2001-05-04 9:04 ` Andrew Cagney 0 siblings, 0 replies; 121+ messages in thread From: Andrew Cagney @ 2001-05-04 9:04 UTC (permalink / raw) To: Paul Hilfinger; +Cc: cgf, danny_r_smith_2001, gdb, mingw-users, dewar > 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-03 13:41 ` Andrew Cagney 2001-05-03 14:15 ` Danny Smith 2001-05-03 23:58 ` [Mingw-users] Re: _WIN32? Paul Hilfinger @ 2001-05-04 0:20 ` Eli Zaretskii 2 siblings, 0 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-04 0:20 UTC (permalink / raw) To: ac131313; +Cc: hilfingr, cgf, danny_r_smith_2001, gdb, mingw-users, dewar > 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? @ 2001-05-05 15:57 Danny Smith 2001-05-05 18:54 ` Christopher Faylor 2001-05-05 23:02 ` Eli Zaretskii 0 siblings, 2 replies; 121+ messages in thread From: Danny Smith @ 2001-05-05 15:57 UTC (permalink / raw) To: gdb >> >> 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! ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-05 15:57 Danny Smith @ 2001-05-05 18:54 ` Christopher Faylor 2001-05-05 23:03 ` Eli Zaretskii 2001-05-05 23:02 ` Eli Zaretskii 1 sibling, 1 reply; 121+ messages in thread From: Christopher Faylor @ 2001-05-05 18:54 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-05 18:54 ` Christopher Faylor @ 2001-05-05 23:03 ` Eli Zaretskii 0 siblings, 0 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-05-05 23:03 UTC (permalink / raw) To: Christopher Faylor; +Cc: gdb 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-05 15:57 Danny Smith 2001-05-05 18:54 ` Christopher Faylor @ 2001-05-05 23:02 ` Eli Zaretskii 2001-05-06 1:52 ` Danny Smith 1 sibling, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-05-05 23:02 UTC (permalink / raw) To: Danny Smith; +Cc: gdb 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-05 23:02 ` Eli Zaretskii @ 2001-05-06 1:52 ` Danny Smith 0 siblings, 0 replies; 121+ messages in thread From: Danny Smith @ 2001-05-06 1:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb --- 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! ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: _WIN32?
@ 2001-04-30 10:15 Christopher Faylor
2001-04-30 16:19 ` [Mingw-users] _WIN32? Danny Smith
0 siblings, 1 reply; 121+ messages in thread
From: Christopher Faylor @ 2001-04-30 10:15 UTC (permalink / raw)
To: Andrew Cagney; +Cc: GDB Discussion, mingw-users
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
^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-04-30 10:15 _WIN32? Christopher Faylor @ 2001-04-30 16:19 ` Danny Smith 2001-04-30 17:03 ` Christopher Faylor 0 siblings, 1 reply; 121+ messages in thread From: Danny Smith @ 2001-04-30 16:19 UTC (permalink / raw) To: Christopher Faylor; +Cc: GDB Discussion, mingw-users --- 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! ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-04-30 16:19 ` [Mingw-users] _WIN32? Danny Smith @ 2001-04-30 17:03 ` Christopher Faylor 2001-04-30 17:29 ` Danny Smith 2001-05-01 7:03 ` Kai Ruottu 0 siblings, 2 replies; 121+ messages in thread From: Christopher Faylor @ 2001-04-30 17:03 UTC (permalink / raw) To: Danny Smith; +Cc: GDB Discussion, mingw-users 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-04-30 17:03 ` Christopher Faylor @ 2001-04-30 17:29 ` Danny Smith 2001-05-01 7:03 ` Kai Ruottu 1 sibling, 0 replies; 121+ messages in thread From: Danny Smith @ 2001-04-30 17:29 UTC (permalink / raw) To: GDB Discussion; +Cc: mingw-users --- 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! ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-04-30 17:03 ` Christopher Faylor 2001-04-30 17:29 ` Danny Smith @ 2001-05-01 7:03 ` Kai Ruottu 2001-05-01 7:44 ` Christopher Faylor 1 sibling, 1 reply; 121+ messages in thread From: Kai Ruottu @ 2001-05-01 7:03 UTC (permalink / raw) To: Christopher Faylor; +Cc: Danny Smith, DB Discussion, mingw-users 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [Mingw-users] Re: _WIN32? 2001-05-01 7:03 ` Kai Ruottu @ 2001-05-01 7:44 ` Christopher Faylor 0 siblings, 0 replies; 121+ messages in thread From: Christopher Faylor @ 2001-05-01 7:44 UTC (permalink / raw) To: Kai Ruottu; +Cc: Danny Smith, DB Discussion, mingw-users 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* RE: MACROS in gdb ???
@ 2001-03-21 15:59 Aditya Chugh
2001-03-21 15:59 ` Daniel Berlin
` (2 more replies)
0 siblings, 3 replies; 121+ messages in thread
From: Aditya Chugh @ 2001-03-21 15:59 UTC (permalink / raw)
To: jtc; +Cc: bug-gdb, gdb
[-- 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
^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: MACROS in gdb ??? 2001-03-21 15:59 MACROS in gdb ??? Aditya Chugh @ 2001-03-21 15:59 ` Daniel Berlin 2001-03-21 15:59 ` Eli Zaretskii 2001-03-21 15:59 ` J.T. Conklin 2 siblings, 0 replies; 121+ messages in thread From: Daniel Berlin @ 2001-03-21 15:59 UTC (permalink / raw) To: Aditya Chugh; +Cc: jtc, bug-gdb, gdb [-- 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* RE: MACROS in gdb ??? 2001-03-21 15:59 MACROS in gdb ??? Aditya Chugh 2001-03-21 15:59 ` Daniel Berlin @ 2001-03-21 15:59 ` Eli Zaretskii [not found] ` <eliz@is.elta.co.il> 2001-03-21 15:59 ` J.T. Conklin 2 siblings, 1 reply; 121+ messages in thread From: Eli Zaretskii @ 2001-03-21 15:59 UTC (permalink / raw) To: Aditya Chugh; +Cc: jtc, gdb 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
[parent not found: <eliz@is.elta.co.il>]
* Re: MACROS in gdb ??? [not found] ` <eliz@is.elta.co.il> @ 2001-03-21 15:59 ` Kevin Buettner 2001-03-21 15:59 ` Eli Zaretskii 0 siblings, 1 reply; 121+ messages in thread From: Kevin Buettner @ 2001-03-21 15:59 UTC (permalink / raw) To: Aditya Chugh; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: MACROS in gdb ??? 2001-03-21 15:59 ` Kevin Buettner @ 2001-03-21 15:59 ` Eli Zaretskii 0 siblings, 0 replies; 121+ messages in thread From: Eli Zaretskii @ 2001-03-21 15:59 UTC (permalink / raw) To: Kevin Buettner; +Cc: Aditya Chugh, gdb 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: MACROS in gdb ??? 2001-03-21 15:59 MACROS in gdb ??? Aditya Chugh 2001-03-21 15:59 ` Daniel Berlin 2001-03-21 15:59 ` Eli Zaretskii @ 2001-03-21 15:59 ` J.T. Conklin 2 siblings, 0 replies; 121+ messages in thread From: J.T. Conklin @ 2001-03-21 15:59 UTC (permalink / raw) To: Aditya Chugh; +Cc: bug-gdb, gdb [-- 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 ^ permalink raw reply [flat|nested] 121+ messages in thread
end of thread, other threads:[~2001-05-10 8:53 UTC | newest] Thread overview: 121+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <200105010009.RAA12115@tully.CS.Berkeley.EDU> 2001-05-03 1:24 ` [Mingw-users] Re: _WIN32? Paul Hilfinger 2001-05-03 13:41 ` Andrew Cagney 2001-05-03 14:15 ` Danny Smith 2001-05-03 15:24 ` Andrew Cagney 2001-05-03 15:54 ` Christopher Faylor 2001-05-03 16:11 ` Andrew Cagney 2001-05-04 2:17 ` Eli Zaretskii 2001-05-04 2:19 ` Eli Zaretskii 2001-05-04 8:45 ` Christopher Faylor 2001-05-04 10:18 ` Eli Zaretskii 2001-05-04 12:04 ` Christopher Faylor 2001-05-07 9:08 ` Eli Zaretskii 2001-05-08 4:38 ` DOS/Windows-specific code (was: _WIN32?) Eli Zaretskii 2001-05-08 4:40 ` DOS/Windows-specific code: cli-cmds.c Eli Zaretskii 2001-05-08 5:07 ` Registers are not available in Cygwin leonp 2001-05-08 7:16 ` DOS/Windows-specific code: cli-cmds.c Christopher Faylor 2001-05-08 17:51 ` Andrew Cagney 2001-05-08 17:53 ` Christopher Faylor 2001-05-09 3:02 ` Eli Zaretskii 2001-05-10 8:33 ` Andrew Cagney 2001-05-08 17:56 ` Andrew Cagney 2001-05-09 3:03 ` Eli Zaretskii 2001-05-09 9:10 ` Andrew Cagney 2001-05-08 4:42 ` DOS/Windows-specific code: exec.c and symfile.c Eli Zaretskii 2001-05-08 7:43 ` Elena Zannoni 2001-05-08 17:58 ` Andrew Cagney 2001-05-09 3:03 ` Eli Zaretskii 2001-05-09 7:07 ` Christopher Faylor 2001-05-08 4:43 ` DOS/Windows-specific code: inflow.c Eli Zaretskii 2001-05-08 7:54 ` Christopher Faylor 2001-05-08 11:15 ` Eli Zaretskii 2001-05-09 13:10 ` Christopher Faylor 2001-05-08 4:46 ` DOS/Windows-specific code: main.c Eli Zaretskii 2001-05-08 7:58 ` Christopher Faylor 2001-05-08 8:17 ` Keith Seitz 2001-05-08 8:19 ` Christopher Faylor 2001-05-08 4:46 ` DOS/Windows-specific code: maint.c Eli Zaretskii 2001-05-08 23:40 ` Kevin Buettner 2001-05-09 3:22 ` Eli Zaretskii 2001-05-10 8:33 ` Andrew Cagney 2001-05-10 8:53 ` Eli Zaretskii 2001-05-08 4:47 ` DOS/Windows-specific code: source.c Eli Zaretskii 2001-05-08 9:30 ` DJ Delorie 2001-05-08 11:18 ` Christopher Faylor 2001-05-08 12:23 ` Eli Zaretskii 2001-05-08 14:00 ` DJ Delorie 2001-05-09 3:05 ` Eli Zaretskii 2001-05-09 7:08 ` Christopher Faylor 2001-05-08 11:14 ` Christopher Faylor 2001-05-08 12:25 ` Eli Zaretskii 2001-05-08 12:33 ` Christopher Faylor 2001-05-09 3:05 ` Eli Zaretskii 2001-05-08 4:48 ` DOS/Windows-specific code: terminal.h Eli Zaretskii 2001-05-08 11:18 ` Christopher Faylor 2001-05-08 4:48 ` DOS/Windows-specific code: sparcl-tdep.c Eli Zaretskii 2001-05-08 23:47 ` Kevin Buettner 2001-05-09 3:14 ` Eli Zaretskii 2001-05-10 8:33 ` Andrew Cagney 2001-05-08 4:50 ` DOS/Windows-specific code: top.c Eli Zaretskii 2001-05-08 7:46 ` Elena Zannoni 2001-05-08 4:51 ` DOS/Windows-specific code: utils.c Eli Zaretskii 2001-05-08 11:26 ` Christopher Faylor 2001-05-08 4:52 ` DOS/Windows-specific code: ser-tcp.c Eli Zaretskii 2001-05-08 5:56 ` Russ Allbery 2001-05-08 6:01 ` Christopher Faylor 2001-05-08 8:09 ` Eli Zaretskii 2001-05-08 8:20 ` Christopher Faylor 2001-05-08 10:30 ` Eli Zaretskii 2001-05-08 11:03 ` Christopher Faylor 2001-05-08 23:53 ` Kevin Buettner 2001-05-09 6:59 ` DOS/Windows-specific code: ser-tcp.c [need ruling from Andrew] Christopher Faylor 2001-05-09 9:29 ` Andrew Cagney 2001-05-10 8:32 ` DOS/Windows-specific code: ser-tcp.c Andrew Cagney 2001-05-08 4:52 ` DOS/Windows-specific code: sh-tdep.c and sh3-rom.c Eli Zaretskii 2001-05-08 7:49 ` Elena Zannoni 2001-05-08 11:17 ` Eli Zaretskii 2001-05-08 11:40 ` Elena Zannoni 2001-05-08 12:36 ` Christopher Faylor 2001-05-08 12:35 ` Christopher Faylor 2001-05-08 18:17 ` Andrew Cagney 2001-05-08 19:35 ` Christopher Faylor 2001-05-08 23:55 ` Kevin Buettner 2001-05-09 3:20 ` Eli Zaretskii 2001-05-09 7:49 ` Elena Zannoni 2001-05-08 4:53 ` DOS/Windows-specific code: values.c Eli Zaretskii 2001-05-08 23:58 ` Kevin Buettner 2001-05-09 7:01 ` Christopher Faylor 2001-05-10 8:33 ` Andrew Cagney 2001-05-08 4:54 ` DOS/Windows-specific code in sim/ Eli Zaretskii 2001-05-08 9:30 ` DJ Delorie 2001-05-08 11:04 ` Eli Zaretskii 2001-05-10 8:33 ` Andrew Cagney 2001-05-08 4:55 ` DOS/Windows-specific code: all the rest Eli Zaretskii 2001-05-08 5:12 ` leonp 2001-05-08 7:59 ` Christopher Faylor 2001-05-08 9:45 ` DJ Delorie 2001-05-08 10:53 ` Eli Zaretskii 2001-05-08 12:08 ` DJ Delorie 2001-05-07 9:09 ` [RFA] Remove OS-specific defines (was: _WIN32?) Eli Zaretskii 2001-05-07 10:39 ` Kevin Buettner 2001-05-07 11:23 ` Eli Zaretskii 2001-05-07 11:37 ` Andrew Cagney 2001-05-03 23:58 ` [Mingw-users] Re: _WIN32? Paul Hilfinger 2001-05-04 9:04 ` Andrew Cagney 2001-05-04 0:20 ` Eli Zaretskii 2001-05-05 15:57 Danny Smith 2001-05-05 18:54 ` Christopher Faylor 2001-05-05 23:03 ` Eli Zaretskii 2001-05-05 23:02 ` Eli Zaretskii 2001-05-06 1:52 ` Danny Smith -- strict thread matches above, loose matches on Subject: below -- 2001-04-30 10:15 _WIN32? Christopher Faylor 2001-04-30 16:19 ` [Mingw-users] _WIN32? Danny Smith 2001-04-30 17:03 ` Christopher Faylor 2001-04-30 17:29 ` Danny Smith 2001-05-01 7:03 ` Kai Ruottu 2001-05-01 7:44 ` Christopher Faylor 2001-03-21 15:59 MACROS in gdb ??? Aditya Chugh 2001-03-21 15:59 ` Daniel Berlin 2001-03-21 15:59 ` Eli Zaretskii [not found] ` <eliz@is.elta.co.il> 2001-03-21 15:59 ` Kevin Buettner 2001-03-21 15:59 ` Eli Zaretskii 2001-03-21 15:59 ` J.T. Conklin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).