diff mbox

RFA: Add xmalloc_failed() to common-utils.c

Message ID 87inxtgtc2.fsf@redhat.com
State New, archived
Headers

Commit Message

Nick Clifton June 1, 2016, 9:18 a.m. UTC 
  Hi Guys,

  I am finding that GDB currently fails to build because of a problem
  with libiberty and multiple definitions of xmalloc.  For example:

    % cd arm-eabi
    % make all-gdb
    [...]
    ../libiberty/libiberty.a(xmalloc.o): In function `xmalloc':
    libiberty/xmalloc.c:147: multiple definition of `xmalloc'
    common-utils.o:/work/sources/gcc/current/gdb/common/common-utils.c:41: first defined here
    [...]

  Which is strange because the xmalloc functions provided by
  common-utils.c ought to be sufficient.  I have traced this down to the
  fact that libiberty's cplus-dem.o file includes an unresolved reference
  to the xmalloc_failed() function.  (I am not sure exactly how this
  reference comes about however).  This function is only provided by the
  xmalloc.c file in libiberty, which is why it is being included in the
  link, and hence causing a conflict.

  The fix for the problem is, I think, quite straightforward - provide a
  copy of the xmalloc_failed function in common-utils.c.  I have tested
  this patch with a variety of different targets (x86, x86_64, arm,
  msp430) and not found any problems or regressions. So...

  OK to apply ?

Cheers
  Nick

gdb/ChangeLog
2016-06-01  Nick Clifton  <nickc@redhat.com>

	* common/common-utils.c (xmalloc_failed): New function.  Provided
	so that the version in libiberty is not linked in.

Comments

Pedro Alves June 1, 2016, 10:22 a.m. UTC | #1 
On 06/01/2016 10:18 AM, Nick Clifton wrote:
> Hi Guys,
> 
>   I am finding that GDB currently fails to build because of a problem
>   with libiberty and multiple definitions of xmalloc.  For example:
> 
>     % cd arm-eabi
>     % make all-gdb
>     [...]
>     ../libiberty/libiberty.a(xmalloc.o): In function `xmalloc':
>     libiberty/xmalloc.c:147: multiple definition of `xmalloc'
>     common-utils.o:/work/sources/gcc/current/gdb/common/common-utils.c:41: first defined here
>     [...]
> 
>   Which is strange because the xmalloc functions provided by
>   common-utils.c ought to be sufficient.  I have traced this down to the
>   fact that libiberty's cplus-dem.o file includes an unresolved reference
>   to the xmalloc_failed() function.  (I am not sure exactly how this
>   reference comes about however).

Sounds like you're using a combined gcc+binutils-gdb build?

Our libiberty copy is behind gcc's -- gcc's has a patch that
added a reference to xmalloc_failed to cplus-dem.c:

  https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00072.html

So turns out you're preemptively fixing a problem for whoever
merges libiberty next.

>   The fix for the problem is, I think, quite straightforward - provide a
>   copy of the xmalloc_failed function in common-utils.c.  I have tested
>   this patch with a variety of different targets (x86, x86_64, arm,
>   msp430) and not found any problems or regressions. So...
> 
>   OK to apply ?

OK.

Thanks,
Pedro Alves
Nick Clifton June 1, 2016, 10:45 a.m. UTC | #2 
Hi Pedro,

> Sounds like you're using a combined gcc+binutils-gdb build?

Yes. :-)

>>   OK to apply ?
> 
> OK.

Thanks - done.

Cheers
  Nick
diff mbox

Patch

diff --git a/gdb/common/common-utils.c b/gdb/common/common-utils.c
index 33668f3..5a346ec 100644
--- a/gdb/common/common-utils.c
+++ b/gdb/common/common-utils.c
@@ -100,6 +100,12 @@  xfree (void *ptr)
     free (ptr);                /* ARI: free */
 }
 
+void
+xmalloc_failed (size_t size)
+{
+  malloc_failure (size);
+}
+
 /* Like asprintf/vasprintf but get an internal_error if the call
    fails. */