From patchwork Wed Jun 1 09:18:53 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Clifton X-Patchwork-Id: 12674 Received: (qmail 67740 invoked by alias); 1 Jun 2016 09:18:59 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 67723 invoked by uid 89); 1 Jun 2016 09:18:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=libibertya, UD:libiberty.a, libiberty.a, Hx-languages-length:1731 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; Wed, 01 Jun 2016 09:18:57 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F13A97F344 for ; Wed, 1 Jun 2016 09:18:55 +0000 (UTC) Received: from littlehelper.redhat.com (vpn1-7-174.ams2.redhat.com [10.36.7.174]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u519Isdk001832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 1 Jun 2016 05:18:55 -0400 From: Nick Clifton To: gdb-patches@sourceware.org Subject: RFA: Add xmalloc_failed() to common-utils.c Date: Wed, 01 Jun 2016 10:18:53 +0100 Message-ID: <87inxtgtc2.fsf@redhat.com> MIME-Version: 1.0 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 * common/common-utils.c (xmalloc_failed): New function. Provided so that the version in libiberty is not linked in. 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. */