Re: [PATCH] Enable building GDB without installed libtermcap

Re: [PATCH] Enable building GDB without installed libtermcap

[Pedro Alves]

Moving to gdb-patches@sourceware.org.  Please keep replies there.

On 02/22/2015 03:11 AM, Bernd Edlinger wrote:
>           Hi,
> 
> currently building gdb is impossible without an installed termcap or a curses library.
> That can be rather aw-quad when building a gdb for a build != host configuration.

Hmm, but how is that different from any other dependency?

> The idea for this patch is to include a simple version of libtermcap as a fall-back
> for the case that the host compiler does not have any cursor library.  This enables
> at least a non tui-enabled gdb.  It works even if there is no termcap configuration
> file on the target.  If a termcap or curses library can be found when configuring gdb,
> we will use the installed library instead of the included libtermcap.
> 
> I used the latest available GNU libtermcap-1.3.1 from http://ftp.gnu.org/gnu/termcap/,
> refreshed the autoconf files and integrated that in the gdb build system.

I don't see any change to libtermcap that makes this a "simple version of libtermcap".
AFAICS, this is really libtermcap, minus the manual and the definitions.  Parts of
the libtermcap patch you show look like something that really should be sent
to libtermcap's list, even.

> I verified that this patch builds various cross-configurations, including target=cygwin.
> 
> To keep the patch files below the limit of 400K for this newsgroup, the attached patch
> assumes that termcap-1.3.1 is first copied to the folder binutils-gdb/libtermcap.
> The texinfo files termcap.info.* need to be manually deleted, as they can be regenerated.
> Then the patch file patch-libtermcap.diff needs to be applied on the libtermcap folder,
> and then autoconf 2.64 needs to be done on the libtermcap folder. Finally the
> patch file patch-gdb-termcap.diff needs to be applied on the binutils-gdb folder.
> 
> 
> OK for trunk?

Sorry, without a better rationale, I don't see how this makes sense.  We
like to have _fewer_ copies of upstream projects in the repo (such as
e.g., readline), not more.

Thanks,
Pedro Alves

Re: [PATCH] Enable building GDB without installed libtermcap

[Pedro Alves]

On 02/23/2015 04:05 PM, Pedro Alves wrote:

>> The idea for this patch is to include a simple version of libtermcap as a fall-back
>> for the case that the host compiler does not have any cursor library.  This enables
>> at least a non tui-enabled gdb.  It works even if there is no termcap configuration
>> file on the target.  If a termcap or curses library can be found when configuring gdb,
>> we will use the installed library instead of the included libtermcap.

...

> I don't see any change to libtermcap that makes this a "simple version of libtermcap".
> AFAICS, this is really libtermcap, minus the manual and the definitions.  Parts of
> the libtermcap patch you show look like something that really should be sent
> to libtermcap's list, even.

...

> Sorry, without a better rationale, I don't see how this makes sense.  We
> like to have _fewer_ copies of upstream projects in the repo (such as
> e.g., readline), not more.

I should have added that GDB _already_ has a very minimal termcap in
the tree -- see gdb/windows-termcap.c.  We could consider making that
the fallback on all hosts.

Thanks,
Pedro Alves

Re: [PATCH] Enable building GDB without installed libtermcap

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

On 23 Feb 2015 16:11, Pedro Alves wrote:
> On 02/23/2015 04:05 PM, Pedro Alves wrote:
> 
> >> The idea for this patch is to include a simple version of libtermcap as a fall-back
> >> for the case that the host compiler does not have any cursor library.  This enables
> >> at least a non tui-enabled gdb.  It works even if there is no termcap configuration
> >> file on the target.  If a termcap or curses library can be found when configuring gdb,
> >> we will use the installed library instead of the included libtermcap.
> 
> ...
> 
> > I don't see any change to libtermcap that makes this a "simple version of libtermcap".
> > AFAICS, this is really libtermcap, minus the manual and the definitions.  Parts of
> > the libtermcap patch you show look like something that really should be sent
> > to libtermcap's list, even.
> 
> ...
> 
> > Sorry, without a better rationale, I don't see how this makes sense.  We
> > like to have _fewer_ copies of upstream projects in the repo (such as
> > e.g., readline), not more.
> 
> I should have added that GDB _already_ has a very minimal termcap in
> the tree -- see gdb/windows-termcap.c.  We could consider making that
> the fallback on all hosts.

i knew i remembered this working before but i couldn't remember why.  agreed -- 
gdb should, if it fails to find a viable termcap, fall back to this stub.

on the topic though, i've just used PDCurses in the past for Windows:
  http://pdcurses.sourceforge.net/
it's trivial to cross-compile and works great in Windows.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Enable building GDB without installed libtermcap

[Eli Zaretskii]

> Date: Mon, 23 Feb 2015 14:27:48 -0500
> From: Mike Frysinger <vapier@gentoo.org>
> Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>,	GDB Patches <gdb-patches@sourceware.org>
> 
> on the topic though, i've just used PDCurses in the past for Windows:
>   http://pdcurses.sourceforge.net/
> it's trivial to cross-compile and works great in Windows.

Ncurses is also available on Windows.

Re: [PATCH] Enable building GDB without installed libtermcap

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

On 23 Feb 2015 21:44, Eli Zaretskii wrote:
> From: Mike Frysinger <vapier@gentoo.org>
> > on the topic though, i've just used PDCurses in the past for Windows:
> >   http://pdcurses.sourceforge.net/
> > it's trivial to cross-compile and works great in Windows.
> 
> Ncurses is also available on Windows.

in my experience, pdcurses is easier to build than ncurses, especially 
cross-compiling
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Enable building GDB without installed libtermcap

[Eli Zaretskii]

> Date: Mon, 23 Feb 2015 15:33:28 -0500
> From: Mike Frysinger <vapier@gentoo.org>
> Cc: palves@redhat.com, bernd.edlinger@hotmail.de,
> 	gdb-patches@sourceware.org
> 
> On 23 Feb 2015 21:44, Eli Zaretskii wrote:
> > From: Mike Frysinger <vapier@gentoo.org>
> > > on the topic though, i've just used PDCurses in the past for Windows:
> > >   http://pdcurses.sourceforge.net/
> > > it's trivial to cross-compile and works great in Windows.
> > 
> > Ncurses is also available on Windows.
> 
> in my experience, pdcurses is easier to build than ncurses, especially 
> cross-compiling

No need to build ncurses, just download and use:

  http://invisible-island.net/datafiles/release/mingw32.zip
  http://invisible-island.net/datafiles/release/mingw64.zip
  http://sourceforge.net/projects/ezwinports/files/ncurses-5.9-w32-bin.zip/download

(I've just built GDB 7.9 with TUI using the last of these 3 URLs.)

RE: [PATCH] Enable building GDB without installed libtermcap

[Bernd Edlinger]

Hi,

On Mon, 23 Feb 2015 16:11:38, Pedro Alves wrote:
>
> On 02/23/2015 04:05 PM, Pedro Alves wrote:
>
>>> The idea for this patch is to include a simple version of libtermcap as a fall-back
>>> for the case that the host compiler does not have any cursor library. This enables
>>> at least a non tui-enabled gdb. It works even if there is no termcap configuration
>>> file on the target. If a termcap or curses library can be found when configuring gdb,
>>> we will use the installed library instead of the included libtermcap.
>
> ...
>
>> I don't see any change to libtermcap that makes this a "simple version of libtermcap".
>> AFAICS, this is really libtermcap, minus the manual and the definitions. Parts of
>> the libtermcap patch you show look like something that really should be sent
>> to libtermcap's list, even.
>
> ...
>
>> Sorry, without a better rationale, I don't see how this makes sense. We
>> like to have _fewer_ copies of upstream projects in the repo (such as
>> e.g., readline), not more.
>
> I should have added that GDB _already_ has a very minimal termcap in
> the tree -- see gdb/windows-termcap.c. We could consider making that
> the fallback on all hosts.
>

Ok, thanks for this hint!

That is probably exactly what I need.

This makes the patch much smaller.

Maybe the name windows-termcap.c is a bit misleading,
because my target is mostly some embedded linux.


How about this:


diff --git a/gdb/configure b/gdb/configure
index 9632f9a..d44ac41 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -7253,7 +7253,7 @@ fi
 
 
 if test "$ac_cv_search_tgetent" = no; then
-  as_fn_error "no termcap library found" "$LINENO" 5
+  CONFIG_OBS="$CONFIG_OBS windows-termcap.o"
 fi
 
 
diff --git a/gdb/configure.ac b/gdb/configure.ac
index dfc6947..87ca668 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -621,7 +621,7 @@ esac
 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 windows-termcap.o"
 fi
 
 AC_ARG_WITH([system-readline],
diff --git a/gdb/windows-termcap.c b/gdb/windows-termcap.c
index caafc47..b6e0d08 100644
--- a/gdb/windows-termcap.c
+++ b/gdb/windows-termcap.c
@@ -32,6 +32,8 @@ 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);
 
+char PC, *BC, *UP;
+
 /* 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.  */


Thanks
Bernd.
 		 	   		  
From gdb-patches-return-120183-listarch-gdb-patches=sources.redhat.com@sourceware.org Tue Feb 24 19:07:29 2015
Return-Path: <gdb-patches-return-120183-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb-patches@sources.redhat.com
Received: (qmail 70467 invoked by alias); 24 Feb 2015 19:07:29 -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 70429 invoked by uid 89); 24 Feb 2015 19:07:28 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2
X-HELO: mx1.redhat.com
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 24 Feb 2015 19:07:26 +0000
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26])	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1OJ7Ps0027114	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits%6 verifyúIL)	for <gdb-patches@sourceware.org>; Tue, 24 Feb 2015 14:07:25 -0500
Received: from host1.jankratochvil.net ([10.40.204.17])	by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1OJ7LWa000985	(version=TLSv1/SSLv3 cipher®S256-SHA bits%6 verify=NO);	Tue, 24 Feb 2015 14:07:24 -0500
Date: Tue, 24 Feb 2015 19:07:00 -0000
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: gdb-patches@sourceware.org
Cc: Phil Muldoon <pmuldoon@redhat.com>
Subject: [patch] compile: Fix GNU-IFUNC funcs called from injected code
Message-ID: <20150224190720.GA32497@host1.jankratochvil.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI"
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
X-IsSubscribed: yes
X-SW-Source: 2015-02/txt/msg00696.txt.bz2


--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-length: 543

Hi,

one could not call IFUNCs (=indirect functions) from the compiled injected
code.  Either it errored with:
	gdb command line:1:1: error: function return type cannot be function

or it just called the IFUNC dispatcher in normal way, returning real function
implementation address instead of the function return value (and thus no
function was called).

It is a pre-requisite for Phil's later 'compile print' code which calls
memcpy() from the injected code.


No regressions on {x86_64,x86_64-m32,i686}-fedora23pre-linux-gnu.


Thanks,
Jan

--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline; filename="compile-gnu-ifunc.patch"
Content-length: 5791

gdb/ChangeLog
2015-02-24  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* compile/compile-c-symbols.c (convert_one_symbol, convert_symbol_bmsym)
	(gcc_symbol_address): Call gnu_ifunc_resolve_addr.

gdb/testsuite/ChangeLog
2015-02-24  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb.compile/compile-ifunc.c: New file.
	* gdb.compile/compile-ifunc.exp: New file.

diff --git a/gdb/compile/compile-c-symbols.c b/gdb/compile/compile-c-symbols.c
index 6562f05..ba6a229 100644
--- a/gdb/compile/compile-c-symbols.c
+++ b/gdb/compile/compile-c-symbols.c
@@ -187,6 +187,8 @@ convert_one_symbol (struct compile_c_instance *context,
 	case LOC_BLOCK:
 	  kind = GCC_C_SYMBOL_FUNCTION;
 	  addr = BLOCK_START (SYMBOL_BLOCK_VALUE (sym));
+	  if (is_global && TYPE_GNU_IFUNC (SYMBOL_TYPE (sym)))
+	    addr = gnu_ifunc_resolve_addr (target_gdbarch (), addr);
 	  break;

 	case LOC_CONST:
@@ -365,6 +367,8 @@ convert_symbol_bmsym (struct compile_c_instance *context,
   gcc_decl decl;
   CORE_ADDR addr;

+  addr = MSYMBOL_VALUE_ADDRESS (objfile, msym);
+
   /* Conversion copied from write_exp_msymbol.  */
   switch (MSYMBOL_TYPE (msym))
     {
@@ -376,8 +380,11 @@ convert_symbol_bmsym (struct compile_c_instance *context,
       break;

     case mst_text_gnu_ifunc:
-      type = objfile_type (objfile)->nodebug_text_gnu_ifunc_symbol;
+      // nodebug_text_gnu_ifunc_symbol would cause:
+      // function return type cannot be function
+      type = objfile_type (objfile)->nodebug_text_symbol;
       kind = GCC_C_SYMBOL_FUNCTION;
+      addr = gnu_ifunc_resolve_addr (target_gdbarch (), addr);
       break;

     case mst_data:
@@ -400,7 +407,6 @@ convert_symbol_bmsym (struct compile_c_instance *context,
     }

   sym_type = convert_type (context, type);
-  addr = MSYMBOL_VALUE_ADDRESS (objfile, msym);
   decl = C_CTX (context)->c_ops->build_decl (C_CTX (context),
 					     MSYMBOL_NATURAL_NAME (msym),
 					     kind, sym_type, NULL, addr,
@@ -497,6 +503,8 @@ gcc_symbol_address (void *datum, struct gcc_c_context *gcc_context,
 				"gcc_symbol_address \"%s\": full symbol\n",
 				identifier);
 	  result = BLOCK_START (SYMBOL_BLOCK_VALUE (sym));
+	  if (TYPE_GNU_IFUNC (SYMBOL_TYPE (sym)))
+	    result = gnu_ifunc_resolve_addr (target_gdbarch (), result);
 	  found = 1;
 	}
       else
@@ -512,6 +520,8 @@ gcc_symbol_address (void *datum, struct gcc_c_context *gcc_context,
 				    "symbol\n",
 				    identifier);
 	      result = BMSYMBOL_VALUE_ADDRESS (msym);
+	      if (MSYMBOL_TYPE (msym.minsym) == mst_text_gnu_ifunc)
+		result = gnu_ifunc_resolve_addr (target_gdbarch (), result);
 	      found = 1;
 	    }
 	}
diff --git a/gdb/testsuite/gdb.compile/compile-ifunc.c b/gdb/testsuite/gdb.compile/compile-ifunc.c
new file mode 100644
index 0000000..e5cee77
--- /dev/null
+++ b/gdb/testsuite/gdb.compile/compile-ifunc.c
@@ -0,0 +1,46 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+   Copyright 2015 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+#include <stdlib.h>
+
+typedef int (*final_t) (int arg);
+
+int
+final (int arg)
+{
+  return arg + 1;
+}
+
+asm (".type gnu_ifunc, %gnu_indirect_function");
+
+final_t
+gnu_ifunc (void)
+{
+  return final;
+}
+
+extern int gnu_ifunc_alias (int arg) __attribute__ ((alias ("gnu_ifunc")));
+
+static int resultvar;
+
+int
+main (void)
+{
+  if (gnu_ifunc_alias (10) != 11)
+    abort ();
+  return resultvar;
+}
diff --git a/gdb/testsuite/gdb.compile/compile-ifunc.exp b/gdb/testsuite/gdb.compile/compile-ifunc.exp
new file mode 100644
index 0000000..9e83c46
--- /dev/null
+++ b/gdb/testsuite/gdb.compile/compile-ifunc.exp
@@ -0,0 +1,54 @@
+# Copyright 2015 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+standard_testfile
+
+if { [prepare_for_testing ${testfile}.exp "$testfile-nodebug" $srcfile {}] } {
+    return -1
+}
+
+if ![runto_main] {
+    return -1
+}
+
+if {[skip_compile_feature_tests]} {
+    untested "compile command not supported (could not find libcc1 shared library?)"
+    return -1
+}
+
+with_test_prefix "nodebug" {
+
+    gdb_test_no_output "compile code resultvar = gnu_ifunc (10);"
+
+    gdb_test "p resultvar" " = 11"
+
+}
+
+if { [prepare_for_testing ${testfile}.exp "$testfile-debug" $srcfile] } {
+    return -1
+}
+
+if ![runto_main] {
+    return -1
+}
+
+with_test_prefix "debug" {
+
+    # gnu_ifunc (10): error: too many arguments to function 'gnu_ifunc'
+    gdb_test_no_output "compile code resultvar = gnu_ifunc_alias (10);"
+
+    gdb_test "p resultvar" " = 11" "debug: p resultvar"
+
+}

--+HP7ph2BbKc20aGI--

Re: [PATCH] Enable building GDB without installed libtermcap

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 234 bytes --]

On 24 Feb 2015 19:13, Bernd Edlinger wrote:
> Maybe the name windows-termcap.c is a bit misleading,
> because my target is mostly some embedded linux.

yes, i think you should rename it to "stub-termcap.c" or something similar.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Enable building GDB without installed libtermcap

[Doug Evans]

On Tue, Feb 24, 2015 at 11:34 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On 24 Feb 2015 19:13, Bernd Edlinger wrote:
>> Maybe the name windows-termcap.c is a bit misleading,
>> because my target is mostly some embedded linux.
>
> yes, i think you should rename it to "stub-termcap.c" or something similar.
> -mike

Agreed.

Re: [PATCH] Enable building GDB without installed libtermcap

[Pedro Alves]

On 02/24/2015 08:29 PM, Doug Evans wrote:
> On Tue, Feb 24, 2015 at 11:34 AM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On 24 Feb 2015 19:13, Bernd Edlinger wrote:
>>> Maybe the name windows-termcap.c is a bit misleading,
>>> because my target is mostly some embedded linux.
>>
>> yes, i think you should rename it to "stub-termcap.c" or something similar.
>> -mike
> 
> Agreed.

Alright, that much is noncontroversial, I think.

Done:
 https://sourceware.org/ml/gdb-patches/2015-02/msg00772.html

-- 
Pedro Alves

Re: [PATCH] Enable building GDB without installed libtermcap

[Pedro Alves]

On 02/24/2015 06:13 PM, Bernd Edlinger wrote:

> Ok, thanks for this hint!
> 
> That is probably exactly what I need.
> 
> This makes the patch much smaller.
> 
> Maybe the name windows-termcap.c is a bit misleading,
> because my target is mostly some embedded linux.
> 

(meanwhile the file has been renamed to stub-termcap.c)

> How about this:
> --- a/gdb/configure.ac
> +++ b/gdb/configure.ac
> @@ -621,7 +621,7 @@ esac
>  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 windows-termcap.o"
>  fi

Yes, but I think we should remove the mingw specific fallback
a bit above too.

>  
>  AC_ARG_WITH([system-readline],
> diff --git a/gdb/windows-termcap.c b/gdb/windows-termcap.c
> index caafc47..b6e0d08 100644
> --- a/gdb/windows-termcap.c
> +++ b/gdb/windows-termcap.c
> @@ -32,6 +32,8 @@ 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);
>  
> +char PC, *BC, *UP;
> +

I was doing what I suggest above, and tripped on the need for this
too, without realizing you had this here already.  GDB is converting
to C++ (and people build with -fno-common too, e.g., 
https://sourceware.org/ml/gdb-patches/2015-02/msg00364.html), and
there's a problem with just defining these symbols unconditionally
here.  See patch below for details, and let me know what you (all) think.

----
[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),
Windows/PE/COFF would be the one that I'd be worried about WRT use of
weak, but the limited weak support in PE/COFF seems to work here.  A
cross build using x86_64-w64-mingw32 on Fedora 20 builds fine with
this.

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 | 13 ++++++++++++-
 2 files changed, 13 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..8704695 100644
--- a/gdb/stub-termcap.c
+++ b/gdb/stub-termcap.c
@@ -32,9 +32,20 @@ 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 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.  */
+char PC __attribute__((weak));
+char *BC __attribute__((weak));
+char *UP __attribute__((weak));
+
 /* 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

Re: [PATCH] Enable building GDB without installed libtermcap

[Eli Zaretskii]

> Date: Thu, 26 Feb 2015 17:48:06 +0000
> From: Pedro Alves <palves@redhat.com>
> CC: GDB Patches <gdb-patches@sourceware.org>, Doug Evans <dje@google.com>,        Mike Frysinger <vapier@gentoo.org>
> 
> My idea to work around that is to simply use __attribute__((weak)).
> Of all supported hosts
> (https://sourceware.org/gdb/wiki/Systems#Supported_Hosts),
> Windows/PE/COFF would be the one that I'd be worried about WRT use of
> weak, but the limited weak support in PE/COFF seems to work here.  A
> cross build using x86_64-w64-mingw32 on Fedora 20 builds fine with
> this.

With what version of GCC?  Quick testing indicates that 4.8.1 supports
that, but 3.4.2 doesn't.

Which version of GCC is the minimal one we want to support?

Or how about making this conditional on C++?

Re: [PATCH] Enable building GDB without installed libtermcap

[Pedro Alves]

On 02/26/2015 06:00 PM, Eli Zaretskii wrote:
>> Date: Thu, 26 Feb 2015 17:48:06 +0000
>> From: Pedro Alves <palves@redhat.com>
>> CC: GDB Patches <gdb-patches@sourceware.org>, Doug Evans <dje@google.com>,        Mike Frysinger <vapier@gentoo.org>
>>
>> My idea to work around that is to simply use __attribute__((weak)).
>> Of all supported hosts
>> (https://sourceware.org/gdb/wiki/Systems#Supported_Hosts),
>> Windows/PE/COFF would be the one that I'd be worried about WRT use of
>> weak, but the limited weak support in PE/COFF seems to work here.  A
>> cross build using x86_64-w64-mingw32 on Fedora 20 builds fine with
>> this.
> 
> With what version of GCC?  Quick testing indicates that 4.8.1 supports
> that, but 3.4.2 doesn't.

Ah.  This was:
  gcc version 4.8.3 20140522 (Fedora MinGW 4.8.3-1.fc20) (GCC)

> 
> Which version of GCC is the minimal one we want to support?

Hard to say at this point.  I'd hope we'd move to requiring
something more recent than 3.4.x.  From past discussions, I was
assuming we'd start by requiring 4.2 at least when finally require
C++.

> Or how about making this conditional on C++?

Some want to build with -fno-common, even in C mode.  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?  The worse that can happen is some host that
didn't use to build for lack of termcap will now fail to build
due to lack of weak.  In practical terms, you just end up with
no gdb, just like before, so no worse.

Thanks,
Pedro Alves

Re: [PATCH] Enable building GDB without installed libtermcap

[Eli Zaretskii]

> Date: Thu, 26 Feb 2015 18:44:53 +0000
> From: Pedro Alves <palves@redhat.com>
> CC: bernd.edlinger@hotmail.de, gdb-patches@sourceware.org, dje@google.com,
>         vapier@gentoo.org
> 
> > Which version of GCC is the minimal one we want to support?
> 
> Hard to say at this point.  I'd hope we'd move to requiring
> something more recent than 3.4.x.  From past discussions, I was
> assuming we'd start by requiring 4.2 at least when finally require
> C++.

I don't have that.  Someone should check if it supports this
attribute.

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

Re: [PATCH] Enable building GDB without installed libtermcap

[Pedro Alves]

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

RE: [PATCH] Enable building GDB without installed libtermcap

[Bernd Edlinger]

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

Re: [PATCH] Enable building GDB without installed libtermcap

[Pedro Alves]

On 04/02/2015 06:34 PM, Bernd Edlinger wrote:
> 
> On Thu, 26 Feb 2015 19:14:41, Pedro Alves wrote:

>> I'd like to hear more opinions on this (whole thing) before
>> pushing ahead.

> ping...
>
> patch looks good for me.
>

I pushed it in now.

Thanks,
Pedro Alves

RE: [PATCH] Enable building GDB without installed libtermcap

[Bernd Edlinger]

Hi,



On Thu, 26 Feb 2015 17:48:06, Pedro Alves wrote:
>
> Yes, but I think we should remove the mingw specific fallback
> a bit above too.
>

yes, and probably these lines too:

  cygwin*)
    if test -d $srcdir/libtermcap; then
      LIBS="../libtermcap/libtermcap.a $LIBS"
      ac_cv_search_tgetent="../libtermcap/libtermcap.a"
    fi ;;


reason: this block is never executed, because
$srcdir/libtermcap points to binutils-gdb/gdb/libtermcap
but it inclues ../libtermcap/libtermcap.a, which assumes
binutils-gdb/libtermcap. However if libtermcap was
there, it is built after gdb, so this would fail anyway.



Thanks
Bernd.
 		 	   		  
From gdb-patches-return-120273-listarch-gdb-patches=sources.redhat.com@sourceware.org Thu Feb 26 19:50:52 2015
Return-Path: <gdb-patches-return-120273-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb-patches@sources.redhat.com
Received: (qmail 105446 invoked by alias); 26 Feb 2015 19:50:52 -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 105437 invoked by uid 89); 26 Feb 2015 19:50:51 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2
X-HELO: mail-vc0-f174.google.com
Received: from mail-vc0-f174.google.com (HELO mail-vc0-f174.google.com) (209.85.220.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 26 Feb 2015 19:50:50 +0000
Received: by mail-vc0-f174.google.com with SMTP id id10so4812959vcb.5        for <gdb-patches@sourceware.org>; Thu, 26 Feb 2015 11:50:48 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.52.126.233 with SMTP id nb9mr9918562vdb.71.1424980248139; Thu, 26 Feb 2015 11:50:48 -0800 (PST)
Received: by 10.52.146.73 with HTTP; Thu, 26 Feb 2015 11:50:48 -0800 (PST)
In-Reply-To: <20150225151646.GA30181@adacore.com>
References: <CAAyhtXSnc_frS-2PKQDt_wDL+=FN9GPkJeWRo_Yn=ez1CYL4uw@mail.gmail.com>	<20130926165939.GA5440@adacore.com>	<CAAyhtXTmrJ04BVhziaFnogGyWLz7+G+Qwbc9UnHJkrEbDgTjFw@mail.gmail.com>	<20131004073447.GB3326@adacore.com>	<20150225151646.GA30181@adacore.com>
Date: Thu, 26 Feb 2015 19:50:00 -0000
Message-ID: <CAAyhtXRC8DFk0SdfLoQvhWk_+h5AFZW2QmXQ6RcdCVC9Asx9Vw@mail.gmail.com>
Subject: Re: Setting parity for remote serial
From: Yurij Grechishhev <yurij.grechishhev@gmail.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Content-Type: text/plain; charset=UTF-8
X-SW-Source: 2015-02/txt/msg00786.txt.bz2
Content-length: 1262

Hi Joel,
Glad to hear that this patch is still needed.
I believe, all questions with FSF copyright assignments had been resolved?
Please, let me know what I should do to complete this contribution.

Thank you

WBR,
Yury

2015-02-25 19:16 GMT+04:00 Joel Brobecker <brobecker@adacore.com>:
> Hello,
>
> On Fri, Oct 04, 2013 at 09:34:47AM +0200, Joel Brobecker wrote:
>> Thanks for your reply, Yurij.
>>
>> > > Any update on this patch?
>> > No updates
>>
>> Is there anything I can do to help this patch come through? I was
>> under the impression that it had stalled waiting for your assignment
>> to come through.
>>
>> > > I don't see you on file at the FSF regarding copyright assignment. What's
>> > the status on this?
>> > I think, assignment/disclaimer process with the FSF is currently complete.
>>
>> I had actually searched the records prior to sending the question.
>> Was the assignment done under a different name or maybe under a
>> university or employer's name?
>
> This is a feature that we would like to have. Unfortunately, since
> we lost contact with Yurij, unless we hear from him again, we will
> ask someone at AdaCore who hasn't seen the patch to implement
> a similar feature. Once we have that, we'll contribute it here.
>
> --
> Joel