* Building the 7.8.90 pretest on MinGW [not found] <announce.20150113122445.36DDE48E8A@joel.gnat.com> @ 2015-01-15 16:07 ` Eli Zaretskii 2015-01-15 19:49 ` Doug Evans 2015-01-16 8:49 ` Eli Zaretskii 0 siblings, 2 replies; 13+ messages in thread From: Eli Zaretskii @ 2015-01-15 16:07 UTC (permalink / raw) To: gdb-patches I've built the pretest using MinGW32. I found 2 issues: one with gnulib's time.h (reported to the gnulib list), the other with the recent changes in tui/. Specifically, starting "gdb -tui" fails with this error message: Cannot enable the TUI: error opening terminal [TERM=<unset>] This happens because the recent additions to tui.c make assumptions about the curses library that don't hold for the MinGW port of ncurses, e.g. that $TERM must be set. The patch below fixes this for me. OK to install it (master and branch)? 2015-01-15 Eli Zaretskii <eliz@gnu.org> * gdb/tui/tui.c (tui_enable) [__MINGW32__]: If the call to 'newterm' fails with the 1st arg NULL, try again with "unknown". Don't test the "cup" capability: it isn't supported by the Windows port of ncurses, but the Windows console driver is still capable of supporting TUI. --- gdb/tui/tui.c~0 2015-01-13 14:14:48 +0200 +++ gdb/tui/tui.c 2015-01-15 10:52:01 +0200 @@ -425,6 +425,12 @@ tui_enable (void) error (_("Cannot enable the TUI when output is not a terminal")); s = newterm (NULL, stdout, stdin); +#ifdef __MINGW32__ + /* The MinGW port of ncurses requires $TERM to be unset in order + to activate the Windows console driver. */ + if (s == NULL) + s = newterm ("unknown", stdout, stdin); +#endif if (s == NULL) { error (_("Cannot enable the TUI: error opening terminal [TERM=%s]"), @@ -432,7 +438,9 @@ tui_enable (void) } w = stdscr; - /* Check required terminal capabilities. */ + /* Check required terminal capabilities. The MinGW port of + ncurses does have them, but doesn't expose them through "cup". */ +#ifndef __MINGW32__ cap = tigetstr ("cup"); if (cap == NULL || cap == (char *) -1 || *cap == '\0') { @@ -442,6 +450,7 @@ tui_enable (void) "terminal doesn't support cursor addressing [TERM=%s]"), gdb_getenv_term ()); } +#endif cbreak (); noecho (); ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Building the 7.8.90 pretest on MinGW 2015-01-15 16:07 ` Building the 7.8.90 pretest on MinGW Eli Zaretskii @ 2015-01-15 19:49 ` Doug Evans 2015-01-19 17:48 ` Eli Zaretskii 2015-01-16 8:49 ` Eli Zaretskii 1 sibling, 1 reply; 13+ messages in thread From: Doug Evans @ 2015-01-15 19:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb-patches On Thu, Jan 15, 2015 at 8:07 AM, Eli Zaretskii <eliz@gnu.org> wrote: > I've built the pretest using MinGW32. I found 2 issues: one with > gnulib's time.h (reported to the gnulib list), the other with the > recent changes in tui/. Specifically, starting "gdb -tui" fails with > this error message: > > Cannot enable the TUI: error opening terminal [TERM=<unset>] > > This happens because the recent additions to tui.c make assumptions > about the curses library that don't hold for the MinGW port of > ncurses, e.g. that $TERM must be set. > > The patch below fixes this for me. OK to install it (master and > branch)? > > 2015-01-15 Eli Zaretskii <eliz@gnu.org> > > * gdb/tui/tui.c (tui_enable) [__MINGW32__]: If the call to 'newterm' > fails with the 1st arg NULL, try again with "unknown". Don't test > the "cup" capability: it isn't supported by the Windows port of > ncurses, but the Windows console driver is still capable of > supporting TUI. Ok by me. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Building the 7.8.90 pretest on MinGW 2015-01-15 19:49 ` Doug Evans @ 2015-01-19 17:48 ` Eli Zaretskii 2015-01-22 11:05 ` Pedro Alves 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2015-01-19 17:48 UTC (permalink / raw) To: Doug Evans; +Cc: gdb-patches > Date: Thu, 15 Jan 2015 11:49:06 -0800 > From: Doug Evans <dje@google.com> > Cc: gdb-patches <gdb-patches@sourceware.org> > > On Thu, Jan 15, 2015 at 8:07 AM, Eli Zaretskii <eliz@gnu.org> wrote: > > I've built the pretest using MinGW32. I found 2 issues: one with > > gnulib's time.h (reported to the gnulib list), the other with the > > recent changes in tui/. Specifically, starting "gdb -tui" fails with > > this error message: > > > > Cannot enable the TUI: error opening terminal [TERM=<unset>] > > > > This happens because the recent additions to tui.c make assumptions > > about the curses library that don't hold for the MinGW port of > > ncurses, e.g. that $TERM must be set. > > > > The patch below fixes this for me. OK to install it (master and > > branch)? > > > > 2015-01-15 Eli Zaretskii <eliz@gnu.org> > > > > * gdb/tui/tui.c (tui_enable) [__MINGW32__]: If the call to 'newterm' > > fails with the 1st arg NULL, try again with "unknown". Don't test > > the "cup" capability: it isn't supported by the Windows port of > > ncurses, but the Windows console driver is still capable of > > supporting TUI. > > Ok by me. Thanks. I'd like to hear from Pedro as well, as the changes which caused this were committed by him. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Building the 7.8.90 pretest on MinGW 2015-01-19 17:48 ` Eli Zaretskii @ 2015-01-22 11:05 ` Pedro Alves 2015-01-22 16:09 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Pedro Alves @ 2015-01-22 11:05 UTC (permalink / raw) To: Eli Zaretskii, Doug Evans; +Cc: gdb-patches Sorry for the delay. On 01/19/2015 05:48 PM, Eli Zaretskii wrote: > Thanks. I'd like to hear from Pedro as well, as the changes which > caused this were committed by him. This is OK with me. A couple questions though: The "cup" check is there to make sure that e.g., starting GDB in a shell within emacs doesn't result in a messed up session. Did you try that? I imagine that cases like when stdin is a pipe, like e.g., when starting mingw gdb in a cygwin shell or in a cygwin ssh session, may result in a messed up screen. I mildly wonder whether pdcurses works here as is without this patch, thus whether the #ifdef check should distinguish ncurses from pdcurses somehow. IIUC, some people build with pdcurses instead of GNU ncurses. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Building the 7.8.90 pretest on MinGW 2015-01-22 11:05 ` Pedro Alves @ 2015-01-22 16:09 ` Eli Zaretskii 2015-01-22 17:04 ` Pedro Alves 2015-01-22 18:30 ` Eli Zaretskii 0 siblings, 2 replies; 13+ messages in thread From: Eli Zaretskii @ 2015-01-22 16:09 UTC (permalink / raw) To: Pedro Alves; +Cc: dje, gdb-patches > Date: Thu, 22 Jan 2015 11:05:09 +0000 > From: Pedro Alves <palves@redhat.com> > CC: gdb-patches@sourceware.org > > Sorry for the delay. > > On 01/19/2015 05:48 PM, Eli Zaretskii wrote: > > > Thanks. I'd like to hear from Pedro as well, as the changes which > > caused this were committed by him. > > This is OK with me. Thanks, I will push shortly. > A couple questions though: > > The "cup" check is there to make sure that e.g., starting GDB > in a shell within emacs doesn't result in a messed up session. > Did you try that? You mean, start GDB under Emacs as gdb -tui -i=mi ... ? It's a strange thing to do, but I did try it now, and didn't see any problems. Which isn't surprising: Emacs injects "TERM=emacs" into the environment inherited by GDB, so the Windows ncurses driver doesn't activate itself. > I imagine that cases like when stdin is a pipe, like e.g., when > starting mingw gdb in a cygwin shell or in a cygwin ssh session, may > result in a messed up screen. Why would it? pipes fail the isatty test. > I mildly wonder whether pdcurses works here as is without > this patch, thus whether the #ifdef check should distinguish > ncurses from pdcurses somehow. I have no idea, ncurses seems to be much more actively developed than pdcurses, so I switched long ago. > IIUC, some people build with pdcurses instead of GNU ncurses. Indeed, so I hope they will speak up. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Building the 7.8.90 pretest on MinGW 2015-01-22 16:09 ` Eli Zaretskii @ 2015-01-22 17:04 ` Pedro Alves 2015-01-22 17:27 ` Eli Zaretskii 2015-01-22 18:30 ` Eli Zaretskii 1 sibling, 1 reply; 13+ messages in thread From: Pedro Alves @ 2015-01-22 17:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dje, gdb-patches On 01/22/2015 04:08 PM, Eli Zaretskii wrote: >> A couple questions though: >> >> The "cup" check is there to make sure that e.g., starting GDB >> in a shell within emacs doesn't result in a messed up session. >> Did you try that? > > You mean, start GDB under Emacs as > > gdb -tui -i=mi ... No, I mean, start a shell buffer in emacs, start gdb within that, and do "layout src". See https://sourceware.org/bugzilla/show_bug.cgi?id=17519. Could you try that? > > ? It's a strange thing to do, but I did try it now, and didn't see > any problems. Which isn't surprising: Emacs injects "TERM=emacs" into > the environment inherited by GDB, so the Windows ncurses driver > doesn't activate itself. > >> I imagine that cases like when stdin is a pipe, like e.g., when >> starting mingw gdb in a cygwin shell or in a cygwin ssh session, may >> result in a messed up screen. > > Why would it? pipes fail the isatty test. Right. I recalled that Windows isatty returns true on all sorts of character devices, like serial ports or the NUL device, not just consoles, but confused pipes. Pipes are not one of those. I see that gnulib has a isatty module that checks that exactly -- it uses GetConsoleMode to make sure input is a real console handle. We don't import that gnulib module presently, but if we need that console check it sounds like importing that module would be way to fix it. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Building the 7.8.90 pretest on MinGW 2015-01-22 17:04 ` Pedro Alves @ 2015-01-22 17:27 ` Eli Zaretskii 2015-01-22 17:46 ` Pedro Alves 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2015-01-22 17:27 UTC (permalink / raw) To: Pedro Alves; +Cc: dje, gdb-patches > Date: Thu, 22 Jan 2015 17:03:30 +0000 > From: Pedro Alves <palves@redhat.com> > CC: dje@google.com, gdb-patches@sourceware.org > > No, I mean, start a shell buffer in emacs, start gdb within that, > and do "layout src". > > See https://sourceware.org/bugzilla/show_bug.cgi?id=17519. > > Could you try that? It says "TUI mode not allowed". (Tested in GDB 7.8.1 built with TUI, I don't have a newer binary where I type this.) > > Why would it? pipes fail the isatty test. > > Right. I recalled that Windows isatty returns true on all > sorts of character devices, like serial ports or the NUL device, > not just consoles, but confused pipes. Pipes are not one of > those. I see that gnulib has a isatty module that checks that > exactly -- it uses GetConsoleMode to make sure input is a real > console handle. We don't import that gnulib module presently, but > if we need that console check it sounds like importing that > module would be way to fix it. Fix what? TUI doesn't need this fix. The only practical problem with MS runtime's isatty is that the null device doesn't fail it, but that's of a marginal importance for GDB, I think. That issue is important for filters and other batch-style programs where redirection to or from the null device is frequently used. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Building the 7.8.90 pretest on MinGW 2015-01-22 17:27 ` Eli Zaretskii @ 2015-01-22 17:46 ` Pedro Alves 0 siblings, 0 replies; 13+ messages in thread From: Pedro Alves @ 2015-01-22 17:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dje, gdb-patches On 01/22/2015 05:27 PM, Eli Zaretskii wrote: >> Date: Thu, 22 Jan 2015 17:03:30 +0000 >> From: Pedro Alves <palves@redhat.com> >> CC: dje@google.com, gdb-patches@sourceware.org >> >> No, I mean, start a shell buffer in emacs, start gdb within that, >> and do "layout src". >> >> See https://sourceware.org/bugzilla/show_bug.cgi?id=17519. >> >> Could you try that? > > It says "TUI mode not allowed". (Tested in GDB 7.8.1 built with TUI, > I don't have a newer binary where I type this.) Ok, that's before my patch, but it means that isatty returned false, so we're good after the patch too. > >>> Why would it? pipes fail the isatty test. >> >> Right. I recalled that Windows isatty returns true on all >> sorts of character devices, like serial ports or the NUL device, >> not just consoles, but confused pipes. Pipes are not one of >> those. I see that gnulib has a isatty module that checks that >> exactly -- it uses GetConsoleMode to make sure input is a real >> console handle. We don't import that gnulib module presently, but >> if we need that console check it sounds like importing that >> module would be way to fix it. > > Fix what? Let me rephrase it: We don't import that gnulib module presently, but if we need that console check it sounds like importing that module would be way to add it. Stress on the "IF". > TUI doesn't need this fix. The only practical problem with > MS runtime's isatty is that the null device doesn't fail it, but > that's of a marginal importance for GDB, I think. That issue is > important for filters and other batch-style programs where redirection > to or from the null device is frequently used. Since pipes already fail the isatty check, I agree it's of marginal importance. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Building the 7.8.90 pretest on MinGW 2015-01-22 16:09 ` Eli Zaretskii 2015-01-22 17:04 ` Pedro Alves @ 2015-01-22 18:30 ` Eli Zaretskii 1 sibling, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2015-01-22 18:30 UTC (permalink / raw) To: palves; +Cc: dje, gdb-patches > Date: Thu, 22 Jan 2015 18:08:50 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: dje@google.com, gdb-patches@sourceware.org > > > Date: Thu, 22 Jan 2015 11:05:09 +0000 > > From: Pedro Alves <palves@redhat.com> > > CC: gdb-patches@sourceware.org > > > > Sorry for the delay. > > > > On 01/19/2015 05:48 PM, Eli Zaretskii wrote: > > > > > Thanks. I'd like to hear from Pedro as well, as the changes which > > > caused this were committed by him. > > > > This is OK with me. > > Thanks, I will push shortly. Done. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Building the 7.8.90 pretest on MinGW 2015-01-15 16:07 ` Building the 7.8.90 pretest on MinGW Eli Zaretskii 2015-01-15 19:49 ` Doug Evans @ 2015-01-16 8:49 ` Eli Zaretskii 2015-01-20 18:27 ` Joel Brobecker 1 sibling, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2015-01-16 8:49 UTC (permalink / raw) To: gdb-patches > Date: Thu, 15 Jan 2015 18:07:11 +0200 > From: Eli Zaretskii <eliz@gnu.org> > > I've built the pretest using MinGW32. I found 2 issues: one with > gnulib's time.h (reported to the gnulib list) The gnulib problem was fixed upstream, see http://lists.gnu.org/archive/html/bug-gnulib/2015-01/msg00044.html Can we please import that fix into GDB, so that the next releases will not have the problem? (I don't know how to import from gnulib, let alone do it for just some of the modules.) TIA ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Building the 7.8.90 pretest on MinGW 2015-01-16 8:49 ` Eli Zaretskii @ 2015-01-20 18:27 ` Joel Brobecker 2015-01-20 18:36 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Joel Brobecker @ 2015-01-20 18:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb-patches > The gnulib problem was fixed upstream, see > > http://lists.gnu.org/archive/html/bug-gnulib/2015-01/msg00044.html > > Can we please import that fix into GDB, so that the next releases will > not have the problem? (I don't know how to import from gnulib, let > alone do it for just some of the modules.) No one's really answered, so I'll provide some feedback: We can add one or more modules, but I'm pretty sure the code for all modules need to be from the same version of gnulib. This means we need to import a more recent version of gnulib, but IIRC, the past few upgrades haven't always been completely smooth (although, perhaps it was more about the fact that we were adding new modules, rather than the fact that we were upgrading). In any case, doing the upgrade itself is fairly simple, but one needs to have enough time afterwards to follow up on any issues that come up from the update. I'd do it for you, but I don't have much of the time to followup on any breakage caused by it. If others are willing to help with that, I could give the gnulib update a go. -- Joel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Building the 7.8.90 pretest on MinGW 2015-01-20 18:27 ` Joel Brobecker @ 2015-01-20 18:36 ` Eli Zaretskii 2015-01-20 19:08 ` Joel Brobecker 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2015-01-20 18:36 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches > Date: Tue, 20 Jan 2015 19:27:41 +0100 > From: Joel Brobecker <brobecker@adacore.com> > Cc: gdb-patches@sourceware.org > > > The gnulib problem was fixed upstream, see > > > > http://lists.gnu.org/archive/html/bug-gnulib/2015-01/msg00044.html > > > > Can we please import that fix into GDB, so that the next releases will > > not have the problem? (I don't know how to import from gnulib, let > > alone do it for just some of the modules.) > > No one's really answered, so I'll provide some feedback: We can add > one or more modules, but I'm pretty sure the code for all modules need > to be from the same version of gnulib. What about just "cherry-picking" that single change? Or would that cause trouble further down the line, when we do update gnulib? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Building the 7.8.90 pretest on MinGW 2015-01-20 18:36 ` Eli Zaretskii @ 2015-01-20 19:08 ` Joel Brobecker 0 siblings, 0 replies; 13+ messages in thread From: Joel Brobecker @ 2015-01-20 19:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb-patches > > No one's really answered, so I'll provide some feedback: We can add > > one or more modules, but I'm pretty sure the code for all modules need > > to be from the same version of gnulib. > > What about just "cherry-picking" that single change? Or would that > cause trouble further down the line, when we do update gnulib? It doesn't work with the way we import gnulib - we import using a SHA1 as a reference so that others can repeat the exact same import when adding new modules. If you are curious, the script we use is at gdb/gnulib/update-gnulib.sh (see GNULIB_COMMIT_SHA1). -- Joel ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-01-22 18:30 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <announce.20150113122445.36DDE48E8A@joel.gnat.com> 2015-01-15 16:07 ` Building the 7.8.90 pretest on MinGW Eli Zaretskii 2015-01-15 19:49 ` Doug Evans 2015-01-19 17:48 ` Eli Zaretskii 2015-01-22 11:05 ` Pedro Alves 2015-01-22 16:09 ` Eli Zaretskii 2015-01-22 17:04 ` Pedro Alves 2015-01-22 17:27 ` Eli Zaretskii 2015-01-22 17:46 ` Pedro Alves 2015-01-22 18:30 ` Eli Zaretskii 2015-01-16 8:49 ` Eli Zaretskii 2015-01-20 18:27 ` Joel Brobecker 2015-01-20 18:36 ` Eli Zaretskii 2015-01-20 19:08 ` Joel Brobecker
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).