From: Bernd Edlinger <bernd.edlinger@hotmail.de>
To: Pedro Alves <palves@redhat.com>, Eli Zaretskii <eliz@gnu.org>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
"dje@google.com" <dje@google.com>,
"vapier@gentoo.org" <vapier@gentoo.org>
Subject: RE: [PATCH] Enable building GDB without installed libtermcap
Date: Thu, 02 Apr 2015 17:34:00 -0000 [thread overview]
Message-ID: <DUB118-W470773612F88B34C273837E4F20@phx.gbl> (raw)
In-Reply-To: <54EF70A1.9000004@redhat.com>
Hi,
ping...
patch looks good for me.
On Thu, 26 Feb 2015 19:14:41, Pedro Alves wrote:
>
> On 02/26/2015 06:55 PM, Eli Zaretskii wrote:
>>> From: Pedro Alves <palves@redhat.com>
>>> Given that this stub file never needed these variables while it was
>>> Windows-only, how about we simply not define the variables if
>>> compiling for mingw/cygwin, but define them as weak everywhere else?
>>
>> Works for me, thanks.
>
> Alright. I recalled that Cygwin doesn't really care about old gcc's,
> so I filed it under not-a-problem and limited the #ifdefery to mingw.
>
> I'd like to hear more opinions on this (whole thing) before
> pushing ahead.
>
> From b99d25c7fc2b10d93b51743f44c08558bf06dfd6 Mon Sep 17 00:00:00 2001
> From: Pedro Alves <palves@redhat.com>
> Date: Thu, 26 Feb 2015 17:01:06 +0000
> Subject: [PATCH] Fallback to stub-termcap.c on all hosts
>
> Currently building gdb is impossible without an installed termcap or
> curses library. But, GDB already has a very minimal termcap in the
> tree to handle this situation for Windows -- gdb/stub-termcap.c. This
> patch makes that the fallback for all hosts.
>
> Testing this on GNU/Linux (by simply hacking away the termcap/curses
> detection in gdb/configure.ac), I tripped on:
>
> ../readline/libreadline.a(terminal.o): In function `_rl_init_terminal_io':
> /home/pedro/gdb/mygit/src/readline/terminal.c:527: undefined reference to `PC'
> /home/pedro/gdb/mygit/src/readline/terminal.c:528: undefined reference to `BC'
> /home/pedro/gdb/mygit/src/readline/terminal.c:529: undefined reference to `UP'
> /home/pedro/gdb/mygit/src/readline/terminal.c:538: undefined reference to `PC'
> /home/pedro/gdb/mygit/src/readline/terminal.c:539: undefined reference to `BC'
> /home/pedro/gdb/mygit/src/readline/terminal.c:540: undefined reference to `UP'
>
> These are globals that are normally defined by termcap (or ncurses'
> termcap emulation).
>
> Now, we could just define replacements in stub-termcap.c, but
> readline/terminal.c (at least the copy in our tree) has this "beauty":
>
> #if !defined (__linux__) && !defined (NCURSES_VERSION)
> # if defined (__EMX__) || defined (NEED_EXTERN_PC)
> extern
> # endif /* __EMX__ || NEED_EXTERN_PC */
> char PC, *BC, *UP;
> #endif /* !__linux__ && !NCURSES_VERSION */
>
> which can result in readline defining the globals too. That will
> usually work out in C, given that "-fcommon" is usually the default
> for C compilers, but that won't work for C++, or C with -fno-common
> (link fails with "multiple definition" errors)...
>
> Mirroring those #ifdef conditions in the stub termcap screams
> "brittle" to me -- I can see them changing in latter readline
> versions.
>
> My idea to work around that is to simply use __attribute__((weak)).
> Of all supported hosts
> (https://sourceware.org/gdb/wiki/Systems#Supported_Hosts), except Windows.
>
> Windows/PE/COFF's do support weak, but not on gcc 3.4 based toolchains
> (4.8.x does work). Given the file never needed the variables while it
> was Windows-only, just continue not defining them there.
>
> gdb/ChangeLog:
> 2015-02-26 Bernd Edlinger <bernd.edlinger@hotmail.de>
> Pedro Alves <palves@redhat.com>
>
> * configure.ac: Remove the mingw32-specific stub-termcap.o
> fallback, and instead fallback to the stub termcap on all hosts.
> * configure: Regenerate.
> * stub-termcap.c (PC, BC, UP): Define as weak symbols.
> ---
> gdb/configure.ac | 7 +------
> gdb/stub-termcap.c | 21 ++++++++++++++++++++-
> 2 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/gdb/configure.ac b/gdb/configure.ac
> index 6ac8adb..79fc115 100644
> --- a/gdb/configure.ac
> +++ b/gdb/configure.ac
> @@ -610,18 +610,13 @@ case $host_os in
> go32* | *djgpp*)
> ac_cv_search_tgetent="none required"
> ;;
> - *mingw32*)
> - if test x"$curses_found" != xyes; then
> - ac_cv_search_tgetent="none required"
> - CONFIG_OBS="$CONFIG_OBS stub-termcap.o"
> - fi ;;
> esac
>
> # These are the libraries checked by Readline.
> AC_SEARCH_LIBS(tgetent, [termcap tinfo curses ncurses])
>
> if test "$ac_cv_search_tgetent" = no; then
> - AC_MSG_ERROR([no termcap library found])
> + CONFIG_OBS="$CONFIG_OBS stub-termcap.o"
> fi
>
> AC_ARG_WITH([system-readline],
> diff --git a/gdb/stub-termcap.c b/gdb/stub-termcap.c
> index cc8632c..df5f888 100644
> --- a/gdb/stub-termcap.c
> +++ b/gdb/stub-termcap.c
> @@ -32,9 +32,28 @@ extern char* tgetstr (char *name, char **area);
> extern int tputs (char *string, int nlines, int (*outfun) ());
> extern char *tgoto (const char *cap, int col, int row);
>
> +/* These globals below are global termcap variables that readline
> + references.
> +
> + Actually, depending on preprocessor conditions that we don't want
> + to mirror here (as they may change depending on readline versions),
> + readline may define these globals as well, relying on the linker
> + merging them if needed (-fcommon). That doesn't work with
> + -fno-common or C++, so instead we define the symbols as weak.
> + Don't do this on Windows though, as MinGW gcc 3.4.2 doesn't support
> + weak (later versions, e.g., 4.8, do support it). Given this stub
> + file originally was Windows only, and we only needed this when we
> + made it work on other hosts, it should be OK. */
> +#ifndef __MINGW32__
> +char PC __attribute__((weak));
> +char *BC __attribute__((weak));
> +char *UP __attribute__((weak));
> +#endif
> +
> /* Each of the files below is a minimal implementation of the standard
> termcap function with the same name, suitable for use in a Windows
> - console window. */
> + console window, or when a real termcap/curses library isn't
> + available. */
>
> int
> tgetent (char *buffer, char *termtype)
> --
> 1.9.3
>
>
From gdb-patches-return-121524-listarch-gdb-patches=sources.redhat.com@sourceware.org Fri Apr 03 00:39:17 2015
Return-Path: <gdb-patches-return-121524-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb-patches@sources.redhat.com
Received: (qmail 23070 invoked by alias); 3 Apr 2015 00:39:17 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Delivered-To: mailing list gdb-patches@sourceware.org
Received: (qmail 23045 invoked by uid 89); 3 Apr 2015 00:39:16 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO: smtp.gentoo.org
Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 03 Apr 2015 00:39:15 +0000
Received: from vapier (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 2D09B340823; Fri, 3 Apr 2015 00:39:13 +0000 (UTC)
Date: Fri, 03 Apr 2015 00:39:00 -0000
From: Mike Frysinger <vapier@gentoo.org>
To: Hans-Peter Nilsson <hp@bitrange.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] sim: d10v: link in missing testsuite
Message-ID: <20150403003913.GF22171@vapier>
Mail-Followup-To: Hans-Peter Nilsson <hp@bitrange.com>, gdb-patches@sourceware.org
References: <1427692153-12656-1-git-send-email-vapier@gentoo.org> <alpine.BSF.2.02.1504021237280.9039@arjuna.pair.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0rSojgWGcpz+ezC3"
Content-Disposition: inline
In-Reply-To: <alpine.BSF.2.02.1504021237280.9039@arjuna.pair.com>
X-IsSubscribed: yes
X-SW-Source: 2015-04/txt/msg00112.txt.bz2
--0rSojgWGcpz+ezC3
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-length: 1506
On 02 Apr 2015 12:53, Hans-Peter Nilsson wrote:
> On Mon, 30 Mar 2015, Mike Frysinger wrote:
> > Looks like historical restructuring in this dir lost the d10v-elf subdir
> > and no one noticed in the meantime.
>
> Wow... And no port maintainer to frown at.
bisecting down, it was a general refactor that broke it ... 10 years ago ;)
> > Re-add it to the testsuite.
> >
> > There are some failures, but better some tests get run than none at all.
>
> Meh... I agree it should be enabled, but as this particular
> harness doesn't summarize the results, the value of a passing
> subset is much lessened...
it helped me verify my nrun refactor didn't screw things up. i was missing some
parts which would lead to a segfault early on.
> (I have to disable d10v sim testing -i.e. just building it-
> in my sim autotester, which is all-must-pass-or-nothing anyway.)
see the patch i posted & pushed
> Is the attached sim d10v-elf testsuite run log consistent with
> your results? A "grep -c Error log" yields 25, FWIW.
all the *-elf subdirs of sim/testsuite/ are like this and suck horribly. i
think i'll pull all the sim/ subdirs out into the higher level and rewrite these
to use the same dejagnu framework.
obnoxiously, this crappy framework supports parallel test running while dejagnu
does not. i'm not sure if there's any way to make the dejagnu do parallel ...
it's really really painful for some targets like frv & bfin which have hundreds
of tests.
-mike
--0rSojgWGcpz+ezC3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-length: 819
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJVHeExAAoJEEFjO5/oN/WBCecP/37kO6tE/ffOSJ9Pf1vfrJlp
IBmUJdbDWty8C6mOv64PQVOS5FWw8fg5DVf6umHbvNu2dO9Xpn4KlE5UqyCwNbvN
X/qGGz7sWVJJ3e2MYW83qJQxfLDUK5lYFn21TEpU/meANNyfZU8XWlNQ/0vGStkc
tgfT4JzL33r7T2qCTzWzQWRM+EDjArZGRNAuXQZ4cepvkd1a7wOXg/60yQ6Sej6K
skxECQXh1UmMKzVzRlEl5aQxJFM3HI8SduyIakjrffhsR7Wl1vwSMrSKWLgnQ2oE
l/oYBLGXaZ9q/ULDeeBWvdAhvEAd9MgwkilWNBG/EjbSJa7zYpnt3+UADWWrfJml
onBtl4UI0BRYly8ulsaMZDJGRZZ/SbzG7maSU4FNbi1+a9fRmEYMRQAXVZDCYfVf
6PIUYOb/u8K81SIMzxuvaqJrNxwRgYxOb25PZE9CuCZKlvoheR2lgI0LUGimRZWu
eO3HZqYhfUpsm/h3fVejDFE+m70lAcLd1g3ufg4UyhamPyHRz2RpfxIlzU5j6r3r
8oWBEo/DsU+GlMMe78y2SJ+N3JNDloKMR/mKa6ZbFTKN/2m9KbIKxoFr1Wt+mLnA
fF5SnugjQMFEDpJUHpoNcZ7ou6FPx5MTrxPigr4r07VsZjsQO0HXRt1LzUHRvnuO
ZrdpUqnkVuZrhr3gLwE9
Íyt
-----END PGP SIGNATURE-----
--0rSojgWGcpz+ezC3--
next prev parent reply other threads:[~2015-04-02 17:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <DUB118-W1951908395674D538A9BBDE4280@phx.gbl>
2015-02-23 16:06 ` Pedro Alves
2015-02-23 16:18 ` Pedro Alves
2015-02-23 19:27 ` Mike Frysinger
2015-02-23 19:44 ` Eli Zaretskii
2015-02-23 20:33 ` Mike Frysinger
2015-02-23 21:00 ` Eli Zaretskii
2015-02-24 18:18 ` Bernd Edlinger
2015-02-24 19:34 ` Mike Frysinger
2015-02-24 20:29 ` Doug Evans
2015-02-26 17:29 ` Pedro Alves
2015-02-26 17:48 ` Pedro Alves
2015-02-26 18:00 ` Eli Zaretskii
2015-02-26 18:45 ` Pedro Alves
2015-02-26 18:55 ` Eli Zaretskii
2015-02-26 19:14 ` Pedro Alves
2015-04-02 17:34 ` Bernd Edlinger [this message]
2015-04-06 11:42 ` Pedro Alves
2015-02-26 19:15 ` Bernd Edlinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DUB118-W470773612F88B34C273837E4F20@phx.gbl \
--to=bernd.edlinger@hotmail.de \
--cc=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=vapier@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox