public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [RFC 1/2] Remove linux-waitpid.c debugging code
  2019-05-30 21:30 [RFC 0/2] Let's discuss moving gdbserver to top-level Tom Tromey
@ 2019-05-30 21:30 ` Tom Tromey
  2019-06-03 14:57   ` Simon Marchi
  2019-05-30 21:30 ` [RFC 2/2] Move gdb's xmalloc and friends to new file Tom Tromey
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 22+ messages in thread
From: Tom Tromey @ 2019-05-30 21:30 UTC (permalink / raw)
  To: gdb-patches; +Cc: Tom Tromey

The debugging code in linux-waitpid.c is one of the few remaining
spots that depends on the gdb/gdbserver difference.

My first thought was that this code is not extremely useful, so this
patch removes this code.  (However, if it is actually useful to
someone, we could make it work by introducing a new abstraction.)

gdb/ChangeLog
2019-05-30  Tom Tromey  <tom@tromey.com>

	* nat/linux-waitpid.c: Don't include server.h.
	(linux_debug): Remove.
	(my_waitpid): Update.
---
 gdb/ChangeLog           |  6 ++++++
 gdb/nat/linux-waitpid.c | 34 +---------------------------------
 2 files changed, 7 insertions(+), 33 deletions(-)

diff --git a/gdb/nat/linux-waitpid.c b/gdb/nat/linux-waitpid.c
index a7d11ab8d32..298032dff9a 100644
--- a/gdb/nat/linux-waitpid.c
+++ b/gdb/nat/linux-waitpid.c
@@ -19,35 +19,10 @@
 
 #include "common/common-defs.h"
 
-#ifdef GDBSERVER
-/* FIXME: server.h is required for the definition of debug_threads
-   which is used in the gdbserver-specific debug printing in
-   linux_debug.  This code should be made available to GDB also,
-   but the lack of a suitable flag to enable it prevents this.  */
-#include "server.h"
-#endif
-
 #include "linux-nat.h"
 #include "linux-waitpid.h"
 #include "common/gdb_wait.h"
 
-/* Print debugging output based on the format string FORMAT and
-   its parameters.  */
-
-static inline void ATTRIBUTE_PRINTF (1,2)
-linux_debug (const char *format, ...)
-{
-#ifdef GDBSERVER
-  if (debug_threads)
-    {
-      va_list args;
-      va_start (args, format);
-      debug_vprintf (format, args);
-      va_end (args);
-    }
-#endif
-}
-
 /* Convert wait status STATUS to a string.  Used for printing debug
    messages only.  */
 
@@ -79,20 +54,13 @@ status_to_str (int status)
 int
 my_waitpid (int pid, int *status, int flags)
 {
-  int ret, out_errno;
-
-  linux_debug ("my_waitpid (%d, 0x%x)\n", pid, flags);
+  int ret;
 
   do
     {
       ret = waitpid (pid, status, flags);
     }
   while (ret == -1 && errno == EINTR);
-  out_errno = errno;
-
-  linux_debug ("my_waitpid (%d, 0x%x): status(%x), %d\n",
-	       pid, flags, (ret > 0 && status != NULL) ? *status : -1, ret);
 
-  errno = out_errno;
   return ret;
 }
-- 
2.17.2

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [RFC 0/2] Let's discuss moving gdbserver to top-level
@ 2019-05-30 21:30 Tom Tromey
  2019-05-30 21:30 ` [RFC 1/2] Remove linux-waitpid.c debugging code Tom Tromey
                   ` (4 more replies)
  0 siblings, 5 replies; 22+ messages in thread
From: Tom Tromey @ 2019-05-30 21:30 UTC (permalink / raw)
  To: gdb-patches

I've wanted to move gdbserver to the top-level for a while now.  I
think it will provide a decent benefit, mainly by letting gdb and
gdbserver share their libiberty, gnulib, and "common" libraries --
shaving off some build time.  It also will have the nice side effect
of simplifying gdbserver's Makefile, fixing some existing bugs.

I have written the patches to do this, but before reworking them into
submittable form, I thought I'd send a couple of initial patches and
start a discussion.

This short series removes a couple of barriers to turning "common"
into a library.  These are pretty much the only changes that could be
sent in isolation.

The rest of the series is:

* Move gnulib to the top-level
* Rename "common" to "gdbsupport" in preparation for a move
* Move "gdbsupport" to top-level
* Move gdbserver to top-level
* Make gdbserver share the other top-level libraries

Most of the patches are pretty mechanical.  There are one or two
hacks, primarily because this series doesn't move the "nat" directory.

Let me know what you think.

Tom


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [RFC 2/2] Move gdb's xmalloc and friends to new file
  2019-05-30 21:30 [RFC 0/2] Let's discuss moving gdbserver to top-level Tom Tromey
  2019-05-30 21:30 ` [RFC 1/2] Remove linux-waitpid.c debugging code Tom Tromey
@ 2019-05-30 21:30 ` Tom Tromey
  2019-06-03 15:03   ` Simon Marchi
                     ` (2 more replies)
  2019-06-03 10:24 ` [RFC 0/2] Let's discuss moving gdbserver to top-level Alan Hayward
                   ` (2 subsequent siblings)
  4 siblings, 3 replies; 22+ messages in thread
From: Tom Tromey @ 2019-05-30 21:30 UTC (permalink / raw)
  To: gdb-patches; +Cc: Tom Tromey

When "common" becomes a library, linking will cause a symbol clash,
because "xmalloc" and some related symbols are defined in that
library, libiberty, and readline.

To work around this problem, this patch moves the clashing symbols to
a new file, which is then compiled separately for both gdb and
gdbserver.

gdb/ChangeLog
2019-05-30  Tom Tromey  <tom@tromey.com>

	* common/common-utils.c (xmalloc, xrealloc, xcalloc)
	(xmalloc_failed): Move to alloc.c.
	* alloc.c: New file.
	* Makefile.in (COMMON_SFILES): Add alloc.c.

gdb/gdbserver/ChangeLog
2019-05-30  Tom Tromey  <tom@tromey.com>

	* Makefile.in (SFILES): Add alloc.c.
	(OBS): Add alloc.o.
	(IPA_OBJS): Add alloc-ipa.o.
	(alloc-ipa.o): New target.
	(%.o: ../%.c): New pattern rule.
---
 gdb/ChangeLog             |  7 +++
 gdb/Makefile.in           |  1 +
 gdb/alloc.c               | 95 +++++++++++++++++++++++++++++++++++++++
 gdb/common/common-utils.c | 72 -----------------------------
 gdb/gdbserver/ChangeLog   |  8 ++++
 gdb/gdbserver/Makefile.in | 11 +++++
 6 files changed, 122 insertions(+), 72 deletions(-)
 create mode 100644 gdb/alloc.c

diff --git a/gdb/Makefile.in b/gdb/Makefile.in
index 0f495783600..15ec7a61b1c 100644
--- a/gdb/Makefile.in
+++ b/gdb/Makefile.in
@@ -924,6 +924,7 @@ COMMON_SFILES = \
 	ada-varobj.c \
 	addrmap.c \
 	agent.c \
+	alloc.c \
 	annotate.c \
 	arch-utils.c \
 	auto-load.c \
diff --git a/gdb/alloc.c b/gdb/alloc.c
new file mode 100644
index 00000000000..e6c9c215435
--- /dev/null
+++ b/gdb/alloc.c
@@ -0,0 +1,95 @@
+/* Shared allocation functions for GDB, the GNU debugger.
+
+   Copyright (C) 2019 Free Software Foundation, Inc.
+
+   This file is part of GDB.
+
+   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 "common/common-defs.h"
+#include "libiberty.h"
+#include <cstdlib>
+#include "common/errors.h"
+
+/* The xmalloc() (libiberty.h) family of memory management routines.
+
+   These are like the ISO-C malloc() family except that they implement
+   consistent semantics and guard against typical memory management
+   problems.  */
+
+/* NOTE: These are declared using PTR to ensure consistency with
+   "libiberty.h".  xfree() is GDB local.  */
+
+PTR                            /* ARI: PTR */
+xmalloc (size_t size)
+{
+  void *val;
+
+  /* See libiberty/xmalloc.c.  This function need's to match that's
+     semantics.  It never returns NULL.  */
+  if (size == 0)
+    size = 1;
+
+  val = malloc (size);         /* ARI: malloc */
+  if (val == NULL)
+    malloc_failure (size);
+
+  return val;
+}
+
+PTR                              /* ARI: PTR */
+xrealloc (PTR ptr, size_t size)          /* ARI: PTR */
+{
+  void *val;
+
+  /* See libiberty/xmalloc.c.  This function need's to match that's
+     semantics.  It never returns NULL.  */
+  if (size == 0)
+    size = 1;
+
+  if (ptr != NULL)
+    val = realloc (ptr, size);	/* ARI: realloc */
+  else
+    val = malloc (size);	        /* ARI: malloc */
+  if (val == NULL)
+    malloc_failure (size);
+
+  return val;
+}
+
+PTR                            /* ARI: PTR */
+xcalloc (size_t number, size_t size)
+{
+  void *mem;
+
+  /* See libiberty/xmalloc.c.  This function need's to match that's
+     semantics.  It never returns NULL.  */
+  if (number == 0 || size == 0)
+    {
+      number = 1;
+      size = 1;
+    }
+
+  mem = calloc (number, size);      /* ARI: xcalloc */
+  if (mem == NULL)
+    malloc_failure (number * size);
+
+  return mem;
+}
+
+void
+xmalloc_failed (size_t size)
+{
+  malloc_failure (size);
+}
diff --git a/gdb/common/common-utils.c b/gdb/common/common-utils.c
index 74ca93810c7..dd839a0d4d1 100644
--- a/gdb/common/common-utils.c
+++ b/gdb/common/common-utils.c
@@ -22,84 +22,12 @@
 #include "host-defs.h"
 #include <ctype.h>
 
-/* The xmalloc() (libiberty.h) family of memory management routines.
-
-   These are like the ISO-C malloc() family except that they implement
-   consistent semantics and guard against typical memory management
-   problems.  */
-
-/* NOTE: These are declared using PTR to ensure consistency with
-   "libiberty.h".  xfree() is GDB local.  */
-
-PTR                            /* ARI: PTR */
-xmalloc (size_t size)
-{
-  void *val;
-
-  /* See libiberty/xmalloc.c.  This function need's to match that's
-     semantics.  It never returns NULL.  */
-  if (size == 0)
-    size = 1;
-
-  val = malloc (size);         /* ARI: malloc */
-  if (val == NULL)
-    malloc_failure (size);
-
-  return val;
-}
-
-PTR                              /* ARI: PTR */
-xrealloc (PTR ptr, size_t size)          /* ARI: PTR */
-{
-  void *val;
-
-  /* See libiberty/xmalloc.c.  This function need's to match that's
-     semantics.  It never returns NULL.  */
-  if (size == 0)
-    size = 1;
-
-  if (ptr != NULL)
-    val = realloc (ptr, size);	/* ARI: realloc */
-  else
-    val = malloc (size);	        /* ARI: malloc */
-  if (val == NULL)
-    malloc_failure (size);
-
-  return val;
-}
-
-PTR                            /* ARI: PTR */           
-xcalloc (size_t number, size_t size)
-{
-  void *mem;
-
-  /* See libiberty/xmalloc.c.  This function need's to match that's
-     semantics.  It never returns NULL.  */
-  if (number == 0 || size == 0)
-    {
-      number = 1;
-      size = 1;
-    }
-
-  mem = calloc (number, size);      /* ARI: xcalloc */
-  if (mem == NULL)
-    malloc_failure (number * size);
-
-  return mem;
-}
-
 void *
 xzalloc (size_t size)
 {
   return xcalloc (1, size);
 }
 
-void
-xmalloc_failed (size_t size)
-{
-  malloc_failure (size);
-}
-
 /* Like asprintf/vasprintf but get an internal_error if the call
    fails. */
 
diff --git a/gdb/gdbserver/Makefile.in b/gdb/gdbserver/Makefile.in
index f5fc55034ee..a0793e657c5 100644
--- a/gdb/gdbserver/Makefile.in
+++ b/gdb/gdbserver/Makefile.in
@@ -197,6 +197,7 @@ SFILES = \
 	$(srcdir)/arch/arm-get-next-pcs.c \
 	$(srcdir)/arch/arm-linux.c \
 	$(srcdir)/arch/ppc-linux-common.c \
+	$(srcdir)/../alloc.c \
 	$(srcdir)/common/btrace-common.c \
 	$(srcdir)/common/buffer.c \
 	$(srcdir)/common/cleanups.c \
@@ -238,6 +239,7 @@ SOURCES = $(SFILES)
 TAGFILES = $(SOURCES) ${HFILES} ${ALLPARAM} ${POSSLIBS}
 
 OBS = \
+	alloc.o \
 	ax.o \
 	common/agent.o \
 	common/btrace-common.o \
@@ -413,6 +415,7 @@ gdbreplay$(EXEEXT): $(sort $(GDBREPLAY_OBS)) $(LIBGNU) $(LIBIBERTY)
 		$(LIBIBERTY)
 
 IPA_OBJS = \
+	alloc-ipa.o \
 	ax-ipa.o \
 	common/common-utils-ipa.o \
 	common/errors-ipa.o \
@@ -568,6 +571,10 @@ ax.o: ax.c
 	$(COMPILE) $(WARN_CFLAGS_NO_FORMAT) $<
 	$(POSTCOMPILE)
 
+alloc-ipa.o: ../alloc.c
+	$(IPAGENT_COMPILE) $(WARN_CFLAGS_NO_FORMAT) $<
+	$(POSTCOMPILE)
+
 # Rules for objects that go in the in-process agent.
 
 arch/%-ipa.o: ../arch/%.c
@@ -623,6 +630,10 @@ common/%.o: ../common/%.c
 	$(COMPILE) $<
 	$(POSTCOMPILE)
 
+%.o: ../%.c
+	$(COMPILE) $<
+	$(POSTCOMPILE)
+
 # Rules for register format descriptions.  Suffix destination files with
 # -generated to identify and clean them easily.
 
-- 
2.17.2

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 0/2] Let's discuss moving gdbserver to top-level
  2019-05-30 21:30 [RFC 0/2] Let's discuss moving gdbserver to top-level Tom Tromey
  2019-05-30 21:30 ` [RFC 1/2] Remove linux-waitpid.c debugging code Tom Tromey
  2019-05-30 21:30 ` [RFC 2/2] Move gdb's xmalloc and friends to new file Tom Tromey
@ 2019-06-03 10:24 ` Alan Hayward
  2019-06-03 13:13   ` Tom Tromey
  2019-06-03 14:27 ` Simon Marchi
  2019-06-05  9:16 ` Pedro Alves
  4 siblings, 1 reply; 22+ messages in thread
From: Alan Hayward @ 2019-06-03 10:24 UTC (permalink / raw)
  To: Tom Tromey; +Cc: gdb-patches\@sourceware.org, nd



> On 30 May 2019, at 22:30, Tom Tromey <tom@tromey.com> wrote:
> 
> I've wanted to move gdbserver to the top-level for a while now.  I
> think it will provide a decent benefit, mainly by letting gdb and
> gdbserver share their libiberty, gnulib, and "common" libraries --
> shaving off some build time.  It also will have the nice side effect
> of simplifying gdbserver's Makefile, fixing some existing bugs.
> 
> I have written the patches to do this, but before reworking them into
> submittable form, I thought I'd send a couple of initial patches and
> start a discussion.
> 
> This short series removes a couple of barriers to turning "common"
> into a library.  These are pretty much the only changes that could be
> sent in isolation.
> 
> The rest of the series is:
> 
> * Move gnulib to the top-level
> * Rename "common" to "gdbsupport" in preparation for a move
> * Move "gdbsupport" to top-level
> * Move gdbserver to top-level
> * Make gdbserver share the other top-level libraries
> 
> Most of the patches are pretty mechanical.  There are one or two
> hacks, primarily because this series doesn't move the "nat" directory.
> 
> Let me know what you think.


Do you have a work in progress branch you could push? I think it’d be
Useful to see what things look like after all the changes.

> 
> Tom
> 
> 


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 0/2] Let's discuss moving gdbserver to top-level
  2019-06-03 10:24 ` [RFC 0/2] Let's discuss moving gdbserver to top-level Alan Hayward
@ 2019-06-03 13:13   ` Tom Tromey
  0 siblings, 0 replies; 22+ messages in thread
From: Tom Tromey @ 2019-06-03 13:13 UTC (permalink / raw)
  To: Alan Hayward; +Cc: Tom Tromey, gdb-patches, nd

>>>>> "Alan" == Alan Hayward <Alan.Hayward@arm.com> writes:

Alan> Do you have a work in progress branch you could push? I think it’d be
Alan> Useful to see what things look like after all the changes.

See move-gdbserver-to-top-level-2 in my github.
It is a mess, though -- I haven't spent the time to clean it up.
It does build ok for me, but no promises.

Tom

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 0/2] Let's discuss moving gdbserver to top-level
  2019-05-30 21:30 [RFC 0/2] Let's discuss moving gdbserver to top-level Tom Tromey
                   ` (2 preceding siblings ...)
  2019-06-03 10:24 ` [RFC 0/2] Let's discuss moving gdbserver to top-level Alan Hayward
@ 2019-06-03 14:27 ` Simon Marchi
  2019-06-03 16:30   ` Tom Tromey
  2019-06-05  9:16 ` Pedro Alves
  4 siblings, 1 reply; 22+ messages in thread
From: Simon Marchi @ 2019-06-03 14:27 UTC (permalink / raw)
  To: Tom Tromey, gdb-patches

On 2019-05-30 5:30 p.m., Tom Tromey wrote:
> I've wanted to move gdbserver to the top-level for a while now.  I
> think it will provide a decent benefit, mainly by letting gdb and
> gdbserver share their libiberty, gnulib, and "common" libraries --
> shaving off some build time.  It also will have the nice side effect
> of simplifying gdbserver's Makefile, fixing some existing bugs.
> 
> I have written the patches to do this, but before reworking them into
> submittable form, I thought I'd send a couple of initial patches and
> start a discussion.
> 
> This short series removes a couple of barriers to turning "common"
> into a library.  These are pretty much the only changes that could be
> sent in isolation.
> 
> The rest of the series is:
> 
> * Move gnulib to the top-level
> * Rename "common" to "gdbsupport" in preparation for a move
> * Move "gdbsupport" to top-level
> * Move gdbserver to top-level
> * Make gdbserver share the other top-level libraries
> 
> Most of the patches are pretty mechanical.  There are one or two
> hacks, primarily because this series doesn't move the "nat" directory.
> 
> Let me know what you think.
> 
> Tom

Just some questions about how things will work after such a move (at least, how it
is in your branch).

I suppose that there will be a top-level --enable-gdbserver/--disable-gdbserver.
switch like there is for other components?

If so, what happens if you do something like

  ./configure --host=x86 --target=arm --enable-gdb --enable-gdbserver

?  Currently, if the host and target architectures are different, gdbserver won't be built
(this check is done in gdb/configure.ac:2181).

Is gdbserver silently skipped, or does it error out saying that you can't enable gdbserver
if host != target?

Do you know about anything else in the binutils-gdb tree that is built to run on the target?

Simon

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 1/2] Remove linux-waitpid.c debugging code
  2019-05-30 21:30 ` [RFC 1/2] Remove linux-waitpid.c debugging code Tom Tromey
@ 2019-06-03 14:57   ` Simon Marchi
  2019-06-03 16:32     ` Tom Tromey
  0 siblings, 1 reply; 22+ messages in thread
From: Simon Marchi @ 2019-06-03 14:57 UTC (permalink / raw)
  To: Tom Tromey, gdb-patches; +Cc: Pedro Alves

On 2019-05-30 5:30 p.m., Tom Tromey wrote:
> The debugging code in linux-waitpid.c is one of the few remaining
> spots that depends on the gdb/gdbserver difference.
> 
> My first thought was that this code is not extremely useful, so this
> patch removes this code.  (However, if it is actually useful to
> someone, we could make it work by introducing a new abstraction.)
> 
> gdb/ChangeLog
> 2019-05-30  Tom Tromey  <tom@tromey.com>
> 
> 	* nat/linux-waitpid.c: Don't include server.h.
> 	(linux_debug): Remove.
> 	(my_waitpid): Update.
> ---
>  gdb/ChangeLog           |  6 ++++++
>  gdb/nat/linux-waitpid.c | 34 +---------------------------------
>  2 files changed, 7 insertions(+), 33 deletions(-)
> 
> diff --git a/gdb/nat/linux-waitpid.c b/gdb/nat/linux-waitpid.c
> index a7d11ab8d32..298032dff9a 100644
> --- a/gdb/nat/linux-waitpid.c
> +++ b/gdb/nat/linux-waitpid.c
> @@ -19,35 +19,10 @@
>  
>  #include "common/common-defs.h"
>  
> -#ifdef GDBSERVER
> -/* FIXME: server.h is required for the definition of debug_threads
> -   which is used in the gdbserver-specific debug printing in
> -   linux_debug.  This code should be made available to GDB also,
> -   but the lack of a suitable flag to enable it prevents this.  */
> -#include "server.h"
> -#endif
> -
>  #include "linux-nat.h"
>  #include "linux-waitpid.h"
>  #include "common/gdb_wait.h"
>  
> -/* Print debugging output based on the format string FORMAT and
> -   its parameters.  */
> -
> -static inline void ATTRIBUTE_PRINTF (1,2)
> -linux_debug (const char *format, ...)
> -{
> -#ifdef GDBSERVER
> -  if (debug_threads)
> -    {
> -      va_list args;
> -      va_start (args, format);
> -      debug_vprintf (format, args);
> -      va_end (args);
> -    }
> -#endif
> -}
> -
>  /* Convert wait status STATUS to a string.  Used for printing debug
>     messages only.  */
>  
> @@ -79,20 +54,13 @@ status_to_str (int status)
>  int
>  my_waitpid (int pid, int *status, int flags)
>  {
> -  int ret, out_errno;
> -
> -  linux_debug ("my_waitpid (%d, 0x%x)\n", pid, flags);
> +  int ret;
>  
>    do
>      {
>        ret = waitpid (pid, status, flags);
>      }
>    while (ret == -1 && errno == EINTR);
> -  out_errno = errno;
> -
> -  linux_debug ("my_waitpid (%d, 0x%x): status(%x), %d\n",
> -	       pid, flags, (ret > 0 && status != NULL) ? *status : -1, ret);
>  
> -  errno = out_errno;
>    return ret;
>  }
> 

Pedro probably has a stronger opinion about this (as he is probably the one who
has spent the most time staring at those logs), but I would think that this
logging is useful when debugging interactions with the kernel.

Simon

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 2/2] Move gdb's xmalloc and friends to new file
  2019-05-30 21:30 ` [RFC 2/2] Move gdb's xmalloc and friends to new file Tom Tromey
@ 2019-06-03 15:03   ` Simon Marchi
  2019-06-03 16:33     ` Tom Tromey
  2019-06-05  9:40   ` Pedro Alves
  2019-06-17 15:45   ` Alan Hayward
  2 siblings, 1 reply; 22+ messages in thread
From: Simon Marchi @ 2019-06-03 15:03 UTC (permalink / raw)
  To: Tom Tromey, gdb-patches

On 2019-05-30 5:30 p.m., Tom Tromey wrote:
> When "common" becomes a library, linking will cause a symbol clash,
> because "xmalloc" and some related symbols are defined in that
> library, libiberty, and readline.
> 
> To work around this problem, this patch moves the clashing symbols to
> a new file, which is then compiled separately for both gdb and
> gdbserver.

Hmm how does this work currently?  We have an xmalloc symbols both in
common/common-utils.o and ../libiberty/libiberty.a, why doesn't it clash?

Simon

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 0/2] Let's discuss moving gdbserver to top-level
  2019-06-03 14:27 ` Simon Marchi
@ 2019-06-03 16:30   ` Tom Tromey
  0 siblings, 0 replies; 22+ messages in thread
From: Tom Tromey @ 2019-06-03 16:30 UTC (permalink / raw)
  To: Simon Marchi; +Cc: Tom Tromey, gdb-patches

>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:

Simon> Just some questions about how things will work after such a move (at least, how it
Simon> is in your branch).

Simon> I suppose that there will be a top-level --enable-gdbserver/--disable-gdbserver.
Simon> switch like there is for other components?

Yes.  This is provided automatically by the top-level configure.

Simon> If so, what happens if you do something like
Simon>   ./configure --host=x86 --target=arm --enable-gdb --enable-gdbserver
Simon> ?  Currently, if the host and target architectures are different, gdbserver won't be built
Simon> (this check is done in gdb/configure.ac:2181).

I forgot to implement any logic to disable gdbserver in the cross
scenario.  I will be sure to do that before submitting the series.

Simon> Is gdbserver silently skipped, or does it error out saying that you can't enable gdbserver
Simon> if host != target?

I'm not sure what it should do in this situation.  Maybe erroring out is
best, since it is a user error to do this.

The basic idea here, though, is to turn gdbserver from something special
with its own instructions into something that can be treated like the
other top-level directories.

Simon> Do you know about anything else in the binutils-gdb tree that is
Simon> built to run on the target?

Nope.

Tom

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 1/2] Remove linux-waitpid.c debugging code
  2019-06-03 14:57   ` Simon Marchi
@ 2019-06-03 16:32     ` Tom Tromey
  2019-06-05  9:32       ` Pedro Alves
  0 siblings, 1 reply; 22+ messages in thread
From: Tom Tromey @ 2019-06-03 16:32 UTC (permalink / raw)
  To: Simon Marchi; +Cc: Tom Tromey, gdb-patches, Pedro Alves

>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:

>> My first thought was that this code is not extremely useful, so this
>> patch removes this code.  (However, if it is actually useful to
>> someone, we could make it work by introducing a new abstraction.)

Simon> Pedro probably has a stronger opinion about this (as he is probably the one who
Simon> has spent the most time staring at those logs), but I would think that this
Simon> logging is useful when debugging interactions with the kernel.

I should have mentioned that the reason I figured it wasn't that useful
is that it's not available in gdb proper, only gdbserver.

Tom

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 2/2] Move gdb's xmalloc and friends to new file
  2019-06-03 15:03   ` Simon Marchi
@ 2019-06-03 16:33     ` Tom Tromey
  0 siblings, 0 replies; 22+ messages in thread
From: Tom Tromey @ 2019-06-03 16:33 UTC (permalink / raw)
  To: Simon Marchi; +Cc: Tom Tromey, gdb-patches

>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:

Simon> On 2019-05-30 5:30 p.m., Tom Tromey wrote:
>> When "common" becomes a library, linking will cause a symbol clash,
>> because "xmalloc" and some related symbols are defined in that
>> library, libiberty, and readline.
>> 
>> To work around this problem, this patch moves the clashing symbols to
>> a new file, which is then compiled separately for both gdb and
>> gdbserver.

Simon> Hmm how does this work currently?  We have an xmalloc symbols both in
Simon> common/common-utils.o and ../libiberty/libiberty.a, why doesn't it clash?

If a symbol comes from a .o then it overrides the symbols coming from
libraries.  The error only occurs if the symbol is only provided by
multiple libraries.  The former is the case today, because we don't make
a library from common/.

Tom

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 0/2] Let's discuss moving gdbserver to top-level
  2019-05-30 21:30 [RFC 0/2] Let's discuss moving gdbserver to top-level Tom Tromey
                   ` (3 preceding siblings ...)
  2019-06-03 14:27 ` Simon Marchi
@ 2019-06-05  9:16 ` Pedro Alves
  4 siblings, 0 replies; 22+ messages in thread
From: Pedro Alves @ 2019-06-05  9:16 UTC (permalink / raw)
  To: Tom Tromey, gdb-patches

On 5/30/19 10:30 PM, Tom Tromey wrote:
> I've wanted to move gdbserver to the top-level for a while now.  I
> think it will provide a decent benefit, mainly by letting gdb and
> gdbserver share their libiberty, gnulib, and "common" libraries --
> shaving off some build time.  It also will have the nice side effect
> of simplifying gdbserver's Makefile, fixing some existing bugs.
> 
> 
> Let me know what you think.

I think this is a good idea; I'm for this general direction.

But you knew that already.  :-)

Thanks,
Pedro Alves

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 1/2] Remove linux-waitpid.c debugging code
  2019-06-03 16:32     ` Tom Tromey
@ 2019-06-05  9:32       ` Pedro Alves
  0 siblings, 0 replies; 22+ messages in thread
From: Pedro Alves @ 2019-06-05  9:32 UTC (permalink / raw)
  To: Tom Tromey, Simon Marchi; +Cc: gdb-patches

On 6/3/19 5:32 PM, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
> 
>>> My first thought was that this code is not extremely useful, so this
>>> patch removes this code.  (However, if it is actually useful to
>>> someone, we could make it work by introducing a new abstraction.)
> 
> Simon> Pedro probably has a stronger opinion about this (as he is probably the one who
> Simon> has spent the most time staring at those logs), but I would think that this
> Simon> logging is useful when debugging interactions with the kernel.
> 
> I should have mentioned that the reason I figured it wasn't that useful
> is that it's not available in gdb proper, only gdbserver.

A bit of history here:

IIRC, the original reason my_waitpid in gdbserver printed the result, is
that I found that useful when I made my_waitpid emulate __WALL:

https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/gdbserver/linux-low.c;h=ba1d7b46bb96e4cec83ea698e40511d284f16532;hb=bd99dc858385792aad304d42f4a47791fd8d3272#l2110

Over the years, the function moved to gdb/nat/, gdb started using it too,
and then the __WALL emulation disappeared, making my_waitpid a simple
EINTR wrapper again.

Since the emulation is gone, and, both gdb and gdbserver print the result
of waitpid in the most interesting waitpid call spot:

      if (debug_threads)
	debug_printf ("LWFE: waitpid(-1, ...) returned %d, %s\n",
		      ret, errno ? strerror (errno) : "ERRNO-OK");


      if (debug_linux_nat)
	fprintf_unfiltered (gdb_stdlog,
			    "LNW: waitpid(-1, ...) returned %d, %s\n",
			    lwpid, errno ? safe_strerror (errno) : "ERRNO-OK");

... I guess I won't terribly miss it.

Thanks,
Pedro Alves

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 2/2] Move gdb's xmalloc and friends to new file
  2019-05-30 21:30 ` [RFC 2/2] Move gdb's xmalloc and friends to new file Tom Tromey
  2019-06-03 15:03   ` Simon Marchi
@ 2019-06-05  9:40   ` Pedro Alves
  2019-06-05 22:33     ` Tom Tromey
  2019-06-17 15:45   ` Alan Hayward
  2 siblings, 1 reply; 22+ messages in thread
From: Pedro Alves @ 2019-06-05  9:40 UTC (permalink / raw)
  To: Tom Tromey, gdb-patches

On 5/30/19 10:30 PM, Tom Tromey wrote:
> When "common" becomes a library, linking will cause a symbol clash,
> because "xmalloc" and some related symbols are defined in that
> library, libiberty, and readline.
> 
> To work around this problem, this patch moves the clashing symbols to
> a new file, which is then compiled separately for both gdb and
> gdbserver.
> 
> gdb/ChangeLog
> 2019-05-30  Tom Tromey  <tom@tromey.com>
> 
> 	* common/common-utils.c (xmalloc, xrealloc, xcalloc)
> 	(xmalloc_failed): Move to alloc.c.
> 	* alloc.c: New file.
> 	* Makefile.in (COMMON_SFILES): Add alloc.c.
> 
> gdb/gdbserver/ChangeLog
> 2019-05-30  Tom Tromey  <tom@tromey.com>
> 
> 	* Makefile.in (SFILES): Add alloc.c.
> 	(OBS): Add alloc.o.
> 	(IPA_OBJS): Add alloc-ipa.o.
> 	(alloc-ipa.o): New target.
> 	(%.o: ../%.c): New pattern rule.

This will be the first case of gdbserver building a file
from gdb/ .  I suppose we could preserve the gdb/common/
directory for such files.  But I guess moving it out of the
way until gdb/common/ moves to top level helps.

> +++ b/gdb/alloc.c
> @@ -0,0 +1,95 @@
> +/* Shared allocation functions for GDB, the GNU debugger.
> +
> +   Copyright (C) 2019 Free Software Foundation, Inc.

The file is new, but the contents aren't, and it's the contents
that matter wrt to copyright years.

There should be some comment here about why this is in a separate file
instead of living in the common library, to help people that read
the code from the tree without having this commit in context.

> +
> +#include "common/common-defs.h"

There should also be a comment explaining why this includes common-defs.h
instead of defs.h.

> +#include "libiberty.h"
> +#include <cstdlib>

Including <cstdlib> looks strange, given common-defs.h includes stdlib.h.
Why did you need this?

> +#include "common/errors.h"
> +
> +/* The xmalloc() (libiberty.h) family of memory management routines.
> +

Thanks,
Pedro Alves

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 2/2] Move gdb's xmalloc and friends to new file
  2019-06-05  9:40   ` Pedro Alves
@ 2019-06-05 22:33     ` Tom Tromey
  0 siblings, 0 replies; 22+ messages in thread
From: Tom Tromey @ 2019-06-05 22:33 UTC (permalink / raw)
  To: Pedro Alves; +Cc: Tom Tromey, gdb-patches

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> This will be the first case of gdbserver building a file
Pedro> from gdb/ .  I suppose we could preserve the gdb/common/
Pedro> directory for such files.  But I guess moving it out of the
Pedro> way until gdb/common/ moves to top level helps.

Yeah.  We can shuffle it around again later if we want.

>> +   Copyright (C) 2019 Free Software Foundation, Inc.

Pedro> The file is new, but the contents aren't, and it's the contents
Pedro> that matter wrt to copyright years.

Fixed.

Pedro> There should be some comment here about why this is in a separate file
Pedro> instead of living in the common library, to help people that read
Pedro> the code from the tree without having this commit in context.

Also fixed.

>> +#include "common/common-defs.h"

Pedro> There should also be a comment explaining why this includes common-defs.h
Pedro> instead of defs.h.

Fixed.

>> +#include "libiberty.h"
>> +#include <cstdlib>

Pedro> Including <cstdlib> looks strange, given common-defs.h includes stdlib.h.
Pedro> Why did you need this?

Removed.

I've appended the new file.

I'll probably push these patches sometime soon.

Tom

/* Shared allocation functions for GDB, the GNU debugger.

   Copyright (C) 1986-2019 Free Software Foundation, Inc.

   This file is part of GDB.

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

/* This file is unusual.

   Because both libiberty and readline define xmalloc and friends, the
   functions in this file can't appear in a library -- that will cause
   link errors.

   And, because we want to turn the common code into a library, this
   file can't live there.

   So, it lives in gdb and is built separately by gdb and gdbserver.
   Please be aware of this when modifying it.

   This also explains why this file includes common-defs.h and not
   defs.h or server.h -- we'd prefer to avoid depending on the
   GDBSERVER define when possible, and for this file it seemed
   simple to do so.  */

#include "common/common-defs.h"
#include "libiberty.h"
#include "common/errors.h"

/* The xmalloc() (libiberty.h) family of memory management routines.

   These are like the ISO-C malloc() family except that they implement
   consistent semantics and guard against typical memory management
   problems.  */

/* NOTE: These are declared using PTR to ensure consistency with
   "libiberty.h".  xfree() is GDB local.  */

PTR                            /* ARI: PTR */
xmalloc (size_t size)
{
  void *val;

  /* See libiberty/xmalloc.c.  This function need's to match that's
     semantics.  It never returns NULL.  */
  if (size == 0)
    size = 1;

  val = malloc (size);         /* ARI: malloc */
  if (val == NULL)
    malloc_failure (size);

  return val;
}

PTR                              /* ARI: PTR */
xrealloc (PTR ptr, size_t size)          /* ARI: PTR */
{
  void *val;

  /* See libiberty/xmalloc.c.  This function need's to match that's
     semantics.  It never returns NULL.  */
  if (size == 0)
    size = 1;

  if (ptr != NULL)
    val = realloc (ptr, size);	/* ARI: realloc */
  else
    val = malloc (size);	        /* ARI: malloc */
  if (val == NULL)
    malloc_failure (size);

  return val;
}

PTR                            /* ARI: PTR */
xcalloc (size_t number, size_t size)
{
  void *mem;

  /* See libiberty/xmalloc.c.  This function need's to match that's
     semantics.  It never returns NULL.  */
  if (number == 0 || size == 0)
    {
      number = 1;
      size = 1;
    }

  mem = calloc (number, size);      /* ARI: xcalloc */
  if (mem == NULL)
    malloc_failure (number * size);

  return mem;
}

void
xmalloc_failed (size_t size)
{
  malloc_failure (size);
}

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 2/2] Move gdb's xmalloc and friends to new file
  2019-05-30 21:30 ` [RFC 2/2] Move gdb's xmalloc and friends to new file Tom Tromey
  2019-06-03 15:03   ` Simon Marchi
  2019-06-05  9:40   ` Pedro Alves
@ 2019-06-17 15:45   ` Alan Hayward
  2019-06-17 17:43     ` Tom Tromey
  2 siblings, 1 reply; 22+ messages in thread
From: Alan Hayward @ 2019-06-17 15:45 UTC (permalink / raw)
  To: Tom Tromey; +Cc: gdb-patches\@sourceware.org, nd

Tom,

Looks like this breaks the building of alloc-ipa.o when using Make 3.81
I’ve tried this on a few different machines.

g++ -x c++  -g -O2    -I. -I../../../src/binutils-gdb/gdb/gdbserver -I../../../src/binutils-gdb/gdb/gdbserver/../regformats -I../../../src/binutils-gdb/gdb/gdbserver/.. -I../../../src/binutils-gdb/gdb/gdbserver/../../include -I../../../src/binutils-gdb/gdb/gdbserver/../../gnulib/import -Ibuild-gnulib-gdbserver/import  -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wformat -Wformat-nonliteral -Werror -DGDBSERVER  -DCONFIG_UST_GDB_INTEGRATION -Drpl_strerror=strerror -fPIC -DIN_PROCESS_AGENT -fvisibility=hidden -c -o alloc-ipa.o -MT alloc-ipa.o -MMD -MP -MF ./.deps/alloc-ipa.Tpo `echo " -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wformat -Wformat-nonliteral " | sed "s/ -Wformat-nonliteral / -Wno-format-nonliteral /g"`
g++: warning: ‘-x c++’ after last input file has no effect
g++: fatal error: no input files
compilation terminated.
make-3.81[4]: *** [alloc-ipa.o] Error 1
make-3.81[4]: *** Waiting for unfinished jobs....


Something has stripped the "../../../src/binutils-gdb/gdb/gdbserver/../alloc.c” from the build line.

Bizarrely, if you then run make a second time, everything works:

g++ -x c++  -g -O2    -I. -I../../../src/binutils-gdb/gdb/gdbserver -I../../../src/binutils-gdb/gdb/gdbserver/../regformats -I../../../src/binutils-gdb/gdb/gdbserver/.. -I../../../src/binutils-gdb/gdb/gdbserver/../../include -I../../../src/binutils-gdb/gdb/gdbserver/../../gnulib/import -Ibuild-gnulib-gdbserver/import  -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wformat -Wformat-nonliteral -Werror -DGDBSERVER  -DCONFIG_UST_GDB_INTEGRATION -Drpl_strerror=strerror -fPIC -DIN_PROCESS_AGENT -fvisibility=hidden -c -o alloc-ipa.o -MT alloc-ipa.o -MMD -MP -MF ./.deps/alloc-ipa.Tpo `echo " -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wformat -Wformat-nonliteral " | sed "s/ -Wformat-nonliteral / -Wno-format-nonliteral /g"` ../../../src/binutils-gdb/gdb/gdbserver/../alloc.c


Reverting your change fixes the issue.

I’ve no idea what’s causing it, and am assuming it’s a weird make bug.
I remember having a 3.81 issue around the same area:
a543c5ca7c1285548726e6d92ca6044dc1963340.


(Personally, I’ve no attachment to 3.81, and usually use 4.x.)



Alan.




> On 30 May 2019, at 22:30, Tom Tromey <tom@tromey.com> wrote:
> 
> When "common" becomes a library, linking will cause a symbol clash,
> because "xmalloc" and some related symbols are defined in that
> library, libiberty, and readline.
> 
> To work around this problem, this patch moves the clashing symbols to
> a new file, which is then compiled separately for both gdb and
> gdbserver.
> 
> gdb/ChangeLog
> 2019-05-30  Tom Tromey  <tom@tromey.com>
> 
> 	* common/common-utils.c (xmalloc, xrealloc, xcalloc)
> 	(xmalloc_failed): Move to alloc.c.
> 	* alloc.c: New file.
> 	* Makefile.in (COMMON_SFILES): Add alloc.c.
> 
> gdb/gdbserver/ChangeLog
> 2019-05-30  Tom Tromey  <tom@tromey.com>
> 
> 	* Makefile.in (SFILES): Add alloc.c.
> 	(OBS): Add alloc.o.
> 	(IPA_OBJS): Add alloc-ipa.o.
> 	(alloc-ipa.o): New target.
> 	(%.o: ../%.c): New pattern rule.
> ---
> gdb/ChangeLog             |  7 +++
> gdb/Makefile.in           |  1 +
> gdb/alloc.c               | 95 +++++++++++++++++++++++++++++++++++++++
> gdb/common/common-utils.c | 72 -----------------------------
> gdb/gdbserver/ChangeLog   |  8 ++++
> gdb/gdbserver/Makefile.in | 11 +++++
> 6 files changed, 122 insertions(+), 72 deletions(-)
> create mode 100644 gdb/alloc.c
> 
> diff --git a/gdb/Makefile.in b/gdb/Makefile.in
> index 0f495783600..15ec7a61b1c 100644
> --- a/gdb/Makefile.in
> +++ b/gdb/Makefile.in
> @@ -924,6 +924,7 @@ COMMON_SFILES = \
> 	ada-varobj.c \
> 	addrmap.c \
> 	agent.c \
> +	alloc.c \
> 	annotate.c \
> 	arch-utils.c \
> 	auto-load.c \
> diff --git a/gdb/alloc.c b/gdb/alloc.c
> new file mode 100644
> index 00000000000..e6c9c215435
> --- /dev/null
> +++ b/gdb/alloc.c
> @@ -0,0 +1,95 @@
> +/* Shared allocation functions for GDB, the GNU debugger.
> +
> +   Copyright (C) 2019 Free Software Foundation, Inc.
> +
> +   This file is part of GDB.
> +
> +   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 "common/common-defs.h"
> +#include "libiberty.h"
> +#include <cstdlib>
> +#include "common/errors.h"
> +
> +/* The xmalloc() (libiberty.h) family of memory management routines.
> +
> +   These are like the ISO-C malloc() family except that they implement
> +   consistent semantics and guard against typical memory management
> +   problems.  */
> +
> +/* NOTE: These are declared using PTR to ensure consistency with
> +   "libiberty.h".  xfree() is GDB local.  */
> +
> +PTR                            /* ARI: PTR */
> +xmalloc (size_t size)
> +{
> +  void *val;
> +
> +  /* See libiberty/xmalloc.c.  This function need's to match that's
> +     semantics.  It never returns NULL.  */
> +  if (size == 0)
> +    size = 1;
> +
> +  val = malloc (size);         /* ARI: malloc */
> +  if (val == NULL)
> +    malloc_failure (size);
> +
> +  return val;
> +}
> +
> +PTR                              /* ARI: PTR */
> +xrealloc (PTR ptr, size_t size)          /* ARI: PTR */
> +{
> +  void *val;
> +
> +  /* See libiberty/xmalloc.c.  This function need's to match that's
> +     semantics.  It never returns NULL.  */
> +  if (size == 0)
> +    size = 1;
> +
> +  if (ptr != NULL)
> +    val = realloc (ptr, size);	/* ARI: realloc */
> +  else
> +    val = malloc (size);	        /* ARI: malloc */
> +  if (val == NULL)
> +    malloc_failure (size);
> +
> +  return val;
> +}
> +
> +PTR                            /* ARI: PTR */
> +xcalloc (size_t number, size_t size)
> +{
> +  void *mem;
> +
> +  /* See libiberty/xmalloc.c.  This function need's to match that's
> +     semantics.  It never returns NULL.  */
> +  if (number == 0 || size == 0)
> +    {
> +      number = 1;
> +      size = 1;
> +    }
> +
> +  mem = calloc (number, size);      /* ARI: xcalloc */
> +  if (mem == NULL)
> +    malloc_failure (number * size);
> +
> +  return mem;
> +}
> +
> +void
> +xmalloc_failed (size_t size)
> +{
> +  malloc_failure (size);
> +}
> diff --git a/gdb/common/common-utils.c b/gdb/common/common-utils.c
> index 74ca93810c7..dd839a0d4d1 100644
> --- a/gdb/common/common-utils.c
> +++ b/gdb/common/common-utils.c
> @@ -22,84 +22,12 @@
> #include "host-defs.h"
> #include <ctype.h>
> 
> -/* The xmalloc() (libiberty.h) family of memory management routines.
> -
> -   These are like the ISO-C malloc() family except that they implement
> -   consistent semantics and guard against typical memory management
> -   problems.  */
> -
> -/* NOTE: These are declared using PTR to ensure consistency with
> -   "libiberty.h".  xfree() is GDB local.  */
> -
> -PTR                            /* ARI: PTR */
> -xmalloc (size_t size)
> -{
> -  void *val;
> -
> -  /* See libiberty/xmalloc.c.  This function need's to match that's
> -     semantics.  It never returns NULL.  */
> -  if (size == 0)
> -    size = 1;
> -
> -  val = malloc (size);         /* ARI: malloc */
> -  if (val == NULL)
> -    malloc_failure (size);
> -
> -  return val;
> -}
> -
> -PTR                              /* ARI: PTR */
> -xrealloc (PTR ptr, size_t size)          /* ARI: PTR */
> -{
> -  void *val;
> -
> -  /* See libiberty/xmalloc.c.  This function need's to match that's
> -     semantics.  It never returns NULL.  */
> -  if (size == 0)
> -    size = 1;
> -
> -  if (ptr != NULL)
> -    val = realloc (ptr, size);	/* ARI: realloc */
> -  else
> -    val = malloc (size);	        /* ARI: malloc */
> -  if (val == NULL)
> -    malloc_failure (size);
> -
> -  return val;
> -}
> -
> -PTR                            /* ARI: PTR */           
> -xcalloc (size_t number, size_t size)
> -{
> -  void *mem;
> -
> -  /* See libiberty/xmalloc.c.  This function need's to match that's
> -     semantics.  It never returns NULL.  */
> -  if (number == 0 || size == 0)
> -    {
> -      number = 1;
> -      size = 1;
> -    }
> -
> -  mem = calloc (number, size);      /* ARI: xcalloc */
> -  if (mem == NULL)
> -    malloc_failure (number * size);
> -
> -  return mem;
> -}
> -
> void *
> xzalloc (size_t size)
> {
>   return xcalloc (1, size);
> }
> 
> -void
> -xmalloc_failed (size_t size)
> -{
> -  malloc_failure (size);
> -}
> -
> /* Like asprintf/vasprintf but get an internal_error if the call
>    fails. */
> 
> diff --git a/gdb/gdbserver/Makefile.in b/gdb/gdbserver/Makefile.in
> index f5fc55034ee..a0793e657c5 100644
> --- a/gdb/gdbserver/Makefile.in
> +++ b/gdb/gdbserver/Makefile.in
> @@ -197,6 +197,7 @@ SFILES = \
> 	$(srcdir)/arch/arm-get-next-pcs.c \
> 	$(srcdir)/arch/arm-linux.c \
> 	$(srcdir)/arch/ppc-linux-common.c \
> +	$(srcdir)/../alloc.c \
> 	$(srcdir)/common/btrace-common.c \
> 	$(srcdir)/common/buffer.c \
> 	$(srcdir)/common/cleanups.c \
> @@ -238,6 +239,7 @@ SOURCES = $(SFILES)
> TAGFILES = $(SOURCES) ${HFILES} ${ALLPARAM} ${POSSLIBS}
> 
> OBS = \
> +	alloc.o \
> 	ax.o \
> 	common/agent.o \
> 	common/btrace-common.o \
> @@ -413,6 +415,7 @@ gdbreplay$(EXEEXT): $(sort $(GDBREPLAY_OBS)) $(LIBGNU) $(LIBIBERTY)
> 		$(LIBIBERTY)
> 
> IPA_OBJS = \
> +	alloc-ipa.o \
> 	ax-ipa.o \
> 	common/common-utils-ipa.o \
> 	common/errors-ipa.o \
> @@ -568,6 +571,10 @@ ax.o: ax.c
> 	$(COMPILE) $(WARN_CFLAGS_NO_FORMAT) $<
> 	$(POSTCOMPILE)
> 
> +alloc-ipa.o: ../alloc.c
> +	$(IPAGENT_COMPILE) $(WARN_CFLAGS_NO_FORMAT) $<
> +	$(POSTCOMPILE)
> +
> # Rules for objects that go in the in-process agent.
> 
> arch/%-ipa.o: ../arch/%.c
> @@ -623,6 +630,10 @@ common/%.o: ../common/%.c
> 	$(COMPILE) $<
> 	$(POSTCOMPILE)
> 
> +%.o: ../%.c
> +	$(COMPILE) $<
> +	$(POSTCOMPILE)
> +
> # Rules for register format descriptions.  Suffix destination files with
> # -generated to identify and clean them easily.
> 
> -- 
> 2.17.2
> 


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 2/2] Move gdb's xmalloc and friends to new file
  2019-06-17 15:45   ` Alan Hayward
@ 2019-06-17 17:43     ` Tom Tromey
  2019-06-17 18:37       ` Pedro Alves
  0 siblings, 1 reply; 22+ messages in thread
From: Tom Tromey @ 2019-06-17 17:43 UTC (permalink / raw)
  To: Alan Hayward; +Cc: Tom Tromey, gdb-patches, nd

>>>>> "Alan" == Alan Hayward <Alan.Hayward@arm.com> writes:

Alan> Looks like this breaks the building of alloc-ipa.o when using Make 3.81
Alan> I’ve tried this on a few different machines.

Thanks.

My first thought is that maybe we should simply declare 3.81
unsupported.  It was apparently released in 2006:

    https://savannah.gnu.org/forum/forum.php?forum_id=4380

... so it is quite ancient.

Is there some compelling reason to keep supporting it?


If there is, I guess I can experiment to try to find a workaround.

thanks,
Tom

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 2/2] Move gdb's xmalloc and friends to new file
  2019-06-17 17:43     ` Tom Tromey
@ 2019-06-17 18:37       ` Pedro Alves
  2019-06-18  9:31         ` Alan Hayward
  0 siblings, 1 reply; 22+ messages in thread
From: Pedro Alves @ 2019-06-17 18:37 UTC (permalink / raw)
  To: Tom Tromey, Alan Hayward; +Cc: gdb-patches, nd

On 6/17/19 6:43 PM, Tom Tromey wrote:
>>>>>> "Alan" == Alan Hayward <Alan.Hayward@arm.com> writes:
> 
> Alan> Looks like this breaks the building of alloc-ipa.o when using Make 3.81
> Alan> I’ve tried this on a few different machines.
> 
> Thanks.
> 
> My first thought is that maybe we should simply declare 3.81
> unsupported.  It was apparently released in 2006:
> 
>     https://savannah.gnu.org/forum/forum.php?forum_id=4380
> 
> ... so it is quite ancient.
> 
> Is there some compelling reason to keep supporting it?
> 

I think it depends more on what distributions ship than what
the release date was.  E.g., if you look around the last couple
stable releases of popular stable distros (e.g., ubuntu, debian, fedora),
which GNU Make version did they ship?  If the GNU Make version shipped
by default is not 4.x, is there an easy optional rpm/deb package
for GNU Make 4.x available?

This was the same kind of investigation that led to the GCC 4.8
minimum requirement.

Also, looking around the GCC compile farm machine (including the
/opt/ dirs) for what is available may be a good hint/proxy for
determining whether bumping the requirement could cause trouble
for people.

> If there is, I guess I can experiment to try to find a workaround.

Thanks,
Pedro Alves

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 2/2] Move gdb's xmalloc and friends to new file
  2019-06-17 18:37       ` Pedro Alves
@ 2019-06-18  9:31         ` Alan Hayward
  2019-07-03 16:18           ` Alan Hayward
  0 siblings, 1 reply; 22+ messages in thread
From: Alan Hayward @ 2019-06-18  9:31 UTC (permalink / raw)
  To: Pedro Alves; +Cc: Tom Tromey, gdb-patches, nd



> On 17 Jun 2019, at 19:37, Pedro Alves <palves@redhat.com> wrote:
> 
> On 6/17/19 6:43 PM, Tom Tromey wrote:
>>>>>>> "Alan" == Alan Hayward <Alan.Hayward@arm.com> writes:
>> 
>> Alan> Looks like this breaks the building of alloc-ipa.o when using Make 3.81
>> Alan> I’ve tried this on a few different machines.
>> 
>> Thanks.
>> 
>> My first thought is that maybe we should simply declare 3.81
>> unsupported.  It was apparently released in 2006:
>> 
>>    https://savannah.gnu.org/forum/forum.php?forum_id=4380
>> 
>> ... so it is quite ancient.
>> 
>> Is there some compelling reason to keep supporting it?
>> 
> 
> I think it depends more on what distributions ship than what
> the release date was.  E.g., if you look around the last couple
> stable releases of popular stable distros (e.g., ubuntu, debian, fedora),
> which GNU Make version did they ship?  If the GNU Make version shipped
> by default is not 4.x, is there an easy optional rpm/deb package
> for GNU Make 4.x available?
> 
> This was the same kind of investigation that led to the GCC 4.8
> minimum requirement.
> 
> Also, looking around the GCC compile farm machine (including the
> /opt/ dirs) for what is available may be a good hint/proxy for
> determining whether bumping the requirement could cause trouble
> for people.


Glibc requires 4.0:
https://www.sourceware.org/ml/libc-alpha/2018-08/msg00003.html
	Changes to build and runtime requirements:
  	GNU make 4.0 or later is now required to build glibc.


GCC still allows 3.8:
https://gcc.gnu.org/install/prerequisites.html
	GNU make version 3.80 (or later)



Alan.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 2/2] Move gdb's xmalloc and friends to new file
  2019-06-18  9:31         ` Alan Hayward
@ 2019-07-03 16:18           ` Alan Hayward
  2019-07-13 16:04             ` Tom Tromey
  2019-07-16 19:47             ` Pedro Alves
  0 siblings, 2 replies; 22+ messages in thread
From: Alan Hayward @ 2019-07-03 16:18 UTC (permalink / raw)
  To: Pedro Alves, Tom Tromey; +Cc: gdb-patches, nd



> On 18 Jun 2019, at 10:30, Alan Hayward <Alan.Hayward@arm.com> wrote:
> 
> 
> 
>> On 17 Jun 2019, at 19:37, Pedro Alves <palves@redhat.com> wrote:
>> 
>> On 6/17/19 6:43 PM, Tom Tromey wrote:
>>>>>>>> "Alan" == Alan Hayward <Alan.Hayward@arm.com> writes:
>>> 
>>> Alan> Looks like this breaks the building of alloc-ipa.o when using Make 3.81
>>> Alan> I’ve tried this on a few different machines.
>>> 
>>> Thanks.
>>> 
>>> My first thought is that maybe we should simply declare 3.81
>>> unsupported.  It was apparently released in 2006:
>>> 
>>>   https://savannah.gnu.org/forum/forum.php?forum_id=4380
>>> 
>>> ... so it is quite ancient.
>>> 
>>> Is there some compelling reason to keep supporting it?
>>> 
>> 
>> I think it depends more on what distributions ship than what
>> the release date was.  E.g., if you look around the last couple
>> stable releases of popular stable distros (e.g., ubuntu, debian, fedora),
>> which GNU Make version did they ship?  If the GNU Make version shipped
>> by default is not 4.x, is there an easy optional rpm/deb package
>> for GNU Make 4.x available?
>> 
>> This was the same kind of investigation that led to the GCC 4.8
>> minimum requirement.
>> 
>> Also, looking around the GCC compile farm machine (including the
>> /opt/ dirs) for what is available may be a good hint/proxy for
>> determining whether bumping the requirement could cause trouble
>> for people.
> 
> 
> Glibc requires 4.0:
> https://www.sourceware.org/ml/libc-alpha/2018-08/msg00003.html
> 	Changes to build and runtime requirements:
>  	GNU make 4.0 or later is now required to build glibc.
> 
> 
> GCC still allows 3.8:
> https://gcc.gnu.org/install/prerequisites.html
> 	GNU make version 3.80 (or later)
> 

I’ve done a little more digging into as many machines as I could find:

Ubuntu 16.04, 18.04 - make 4.1
Ubuntu 14.04 - make 4.0
Fedora 27 - make 4.2.1
Redhat 7.5, Centos 7.5, Centos 6 - make 3.82
Redhat 5.8, 6.9 - make 3.81
OpenSuse 42.2 - 4.2.1

Also: https://software.opensuse.org/package/make confirms a mix of 4.21 and
3.82 as the versions in various latest distros.

I’ve tried building using make 3.82, and it works for me.
Make 3.82 was released in 2010.

Any objection upping the minimum make version to 3.82 ?

If so I can raise a patch to add a statement to the NEWS file (similar to
the one that already exists).


Alan.





^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 2/2] Move gdb's xmalloc and friends to new file
  2019-07-03 16:18           ` Alan Hayward
@ 2019-07-13 16:04             ` Tom Tromey
  2019-07-16 19:47             ` Pedro Alves
  1 sibling, 0 replies; 22+ messages in thread
From: Tom Tromey @ 2019-07-13 16:04 UTC (permalink / raw)
  To: Alan Hayward; +Cc: Pedro Alves, Tom Tromey, gdb-patches, nd

>>>>> "Alan" == Alan Hayward <Alan.Hayward@arm.com> writes:

Alan> Any objection upping the minimum make version to 3.82 ?

Alan> If so I can raise a patch to add a statement to the NEWS file (similar to
Alan> the one that already exists).

That would be fine by me.

Tom

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [RFC 2/2] Move gdb's xmalloc and friends to new file
  2019-07-03 16:18           ` Alan Hayward
  2019-07-13 16:04             ` Tom Tromey
@ 2019-07-16 19:47             ` Pedro Alves
  1 sibling, 0 replies; 22+ messages in thread
From: Pedro Alves @ 2019-07-16 19:47 UTC (permalink / raw)
  To: Alan Hayward, Tom Tromey; +Cc: gdb-patches, nd

On 7/3/19 5:18 PM, Alan Hayward wrote:
> 
> 
>> On 18 Jun 2019, at 10:30, Alan Hayward <Alan.Hayward@arm.com> wrote:
>>
>>
>>
>>> On 17 Jun 2019, at 19:37, Pedro Alves <palves@redhat.com> wrote:
>>>
>>> On 6/17/19 6:43 PM, Tom Tromey wrote:
>>>>>>>>> "Alan" == Alan Hayward <Alan.Hayward@arm.com> writes:
>>>>
>>>> Alan> Looks like this breaks the building of alloc-ipa.o when using Make 3.81
>>>> Alan> I’ve tried this on a few different machines.
>>>>
>>>> Thanks.
>>>>
>>>> My first thought is that maybe we should simply declare 3.81
>>>> unsupported.  It was apparently released in 2006:
>>>>
>>>>   https://savannah.gnu.org/forum/forum.php?forum_id=4380
>>>>
>>>> ... so it is quite ancient.
>>>>
>>>> Is there some compelling reason to keep supporting it?
>>>>
>>>
>>> I think it depends more on what distributions ship than what
>>> the release date was.  E.g., if you look around the last couple
>>> stable releases of popular stable distros (e.g., ubuntu, debian, fedora),
>>> which GNU Make version did they ship?  If the GNU Make version shipped
>>> by default is not 4.x, is there an easy optional rpm/deb package
>>> for GNU Make 4.x available?
>>>
>>> This was the same kind of investigation that led to the GCC 4.8
>>> minimum requirement.
>>>
>>> Also, looking around the GCC compile farm machine (including the
>>> /opt/ dirs) for what is available may be a good hint/proxy for
>>> determining whether bumping the requirement could cause trouble
>>> for people.
>>
>>
>> Glibc requires 4.0:
>> https://www.sourceware.org/ml/libc-alpha/2018-08/msg00003.html
>> 	Changes to build and runtime requirements:
>>  	GNU make 4.0 or later is now required to build glibc.
>>
>>
>> GCC still allows 3.8:
>> https://gcc.gnu.org/install/prerequisites.html
>> 	GNU make version 3.80 (or later)
>>
> 
> I’ve done a little more digging into as many machines as I could find:
> 
> Ubuntu 16.04, 18.04 - make 4.1
> Ubuntu 14.04 - make 4.0
> Fedora 27 - make 4.2.1
> Redhat 7.5, Centos 7.5, Centos 6 - make 3.82
> Redhat 5.8, 6.9 - make 3.81
> OpenSuse 42.2 - 4.2.1
> 
> Also: https://software.opensuse.org/package/make confirms a mix of 4.21 and
> 3.82 as the versions in various latest distros.
> 
> I’ve tried building using make 3.82, and it works for me.
> Make 3.82 was released in 2010.
> 
> Any objection upping the minimum make version to 3.82 ?
> 

Fine with me as well.  Thanks for digging into all those machines.

Thanks,
Pedro Alves

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2019-07-16 19:47 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-30 21:30 [RFC 0/2] Let's discuss moving gdbserver to top-level Tom Tromey
2019-05-30 21:30 ` [RFC 1/2] Remove linux-waitpid.c debugging code Tom Tromey
2019-06-03 14:57   ` Simon Marchi
2019-06-03 16:32     ` Tom Tromey
2019-06-05  9:32       ` Pedro Alves
2019-05-30 21:30 ` [RFC 2/2] Move gdb's xmalloc and friends to new file Tom Tromey
2019-06-03 15:03   ` Simon Marchi
2019-06-03 16:33     ` Tom Tromey
2019-06-05  9:40   ` Pedro Alves
2019-06-05 22:33     ` Tom Tromey
2019-06-17 15:45   ` Alan Hayward
2019-06-17 17:43     ` Tom Tromey
2019-06-17 18:37       ` Pedro Alves
2019-06-18  9:31         ` Alan Hayward
2019-07-03 16:18           ` Alan Hayward
2019-07-13 16:04             ` Tom Tromey
2019-07-16 19:47             ` Pedro Alves
2019-06-03 10:24 ` [RFC 0/2] Let's discuss moving gdbserver to top-level Alan Hayward
2019-06-03 13:13   ` Tom Tromey
2019-06-03 14:27 ` Simon Marchi
2019-06-03 16:30   ` Tom Tromey
2019-06-05  9:16 ` Pedro Alves

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