From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18680 invoked by alias); 24 Nov 2016 14:19:42 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 18671 invoked by uid 89); 24 Nov 2016 14:19:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=H*MI:sk:5834D6E, HX-Greylist:EST, HX-Greylist:0500 X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 24 Nov 2016 14:19:39 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id B460810A73E; Thu, 24 Nov 2016 09:19:37 -0500 (EST) From: John Baldwin To: Pedro Alves Cc: Chris Johns , gdb@sourceware.org Subject: Re: gdb-7.12 powerpc-rtems4.12-gdb does not build on FreeBSD. Date: Thu, 24 Nov 2016 14:19:00 -0000 Message-ID: <2179193.1CJTdt5csh@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) In-Reply-To: <1ea845b2-d6bc-e9f7-d649-bc4f37462d92@redhat.com> References: <5834D6E0.9060601@rtems.org> <2608815.dbYXHQl3xm@ralph.baldwin.cx> <1ea845b2-d6bc-e9f7-d649-bc4f37462d92@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00048.txt.bz2 On Thursday, November 24, 2016 12:12:45 PM Pedro Alves wrote: > On 11/24/2016 02:46 AM, John Baldwin wrote: > > On Thursday, November 24, 2016 11:30:11 AM Chris Johns wrote: > >> On 24/11/2016 11:15, John Baldwin wrote: > >>> On Thursday, November 24, 2016 10:16:10 AM Chris Johns wrote: > >>>> On 23/11/2016 10:38, Chris Johns wrote: > >>>>> Hi, > >>>>> > >>>>> I am getting: > >>>>> > >>>>> ../sim/ppc/libsim.a(sim_calls.o): In function `sim_io_printf_filtered': > >>>>> ../../../gdb-7.12/sim/ppc/sim_calls.c:(.text+0x17c): undefined reference > >>>>> to `error' > >>>>> ../sim/ppc/libsim.a(sim_calls.o): In function `sim_load': > >>>>> ../../../gdb-7.12/sim/ppc/sim_calls.c:(.text+0x291): undefined reference > >>>>> to `error' > >>>>> ../../../gdb-7.12/sim/ppc/sim_calls.c:(.text+0x31d): undefined reference > >>>>> to `error' > >>>>> ../../../gdb-7.12/sim/ppc/sim_calls.c:(.text+0x357): undefined reference > >>>>> to `error' > >>>>> ../sim/ppc/libsim.a(sim_calls.o): In function `sim_create_inferior': > >>>>> ../../../gdb-7.12/sim/ppc/sim_calls.c:(.text+0x53e): undefined reference > >>>>> to `error' > >>>>> > >>>>> and errors.o has the following symbols: > >>>>> > >>>>> nm > >>>>> build/powerpc-rtems4.12-gdb-7.12-x86_64-freebsd10.3-1/build/gdb/errors.o > >>>>> 0000000000000120 T _Z14internal_errorPKciS0_z > >>>>> U _Z15internal_verrorPKciS0_P13__va_list_tag > >>>>> 00000000000001a0 T _Z16internal_warningPKciS0_z > >>>>> U _Z17internal_vwarningPKciS0_P13__va_list_tag > >>>>> 0000000000000090 T _Z5errorPKcz > >>>>> U _Z6verrorPKcP13__va_list_tag > >>>>> 0000000000000000 T _Z7warningPKcz > >>>>> U _Z8vwarningPKcP13__va_list_tag > >>>>> > >>>>> Is there a C++/C thing happening here between the PCC simulator and GDB? > >>>>> > >>>> > >>>> A follow up. It looks like GDB is being built by cc which is clang on > >>>> FreeBSD. I am told by Joel this gdb target builds on Linux. > >>>> > >>>> I do not know what the extern binding is for gdb, C or C++? > >>> > >>> clang vs gcc shouldn't really break this. > >> > >> Yes I agree. > >> > >>> What undefined symbols do you see > >>> in the nm of sim_calls.o? > >> > >> The symbol is `error` and in my original post I showed the output of nm > >> for the errors.o object file and `error` symbol is mangled. One thing > >> that confuses me is only this symbol is being reported and there must be > >> other calls to gdb. > > > > FYI, I reproduced this with gdb's master branch using > > "configure --target powerpc-rtems4.12-elf" (albeit on FreeBSD 11, though > > I have gcc48 installed as /usr/local/bin/gcc and configure found that and > > used it instead of cc). The raw symbol in sim_calls.o is indeed plain C: > > > > % nm sim/ppc/sim_calls.o | grep error > > U bfd_get_error > > U error > > 0000000000000a20 T sim_io_error > > > > Compiling gdb as C isn't an option on 'master', so it will need a different > > fix. Probably the sims need to be built as C++ now. > > The PPC sim shouldn't be calling GDB's "error" directly. If it does, > then that's should be fixed. There's an "error" method in the > host_callback structure (filled in by GDB) that should be used instead. Ah, the sim defines its own 'error()' routine in misc.c. It also defines its own zalloc() and a few other routines, but misc.o isn't included in libsim.a, only for specific binaries (it seems to be a stub defined to hold routines normally defined in gdb for use in stand-alone programs). Curiously, sim_calls.c defines its own zalloc(). I tried adding an error() to sim_calls.c and that fixes the build. I modeled it on sim_io_error(): diff --git a/sim/ppc/sim_calls.c b/sim/ppc/sim_calls.c index 470c958..eb5d1a7 100644 --- a/sim/ppc/sim_calls.c +++ b/sim/ppc/sim_calls.c @@ -386,6 +386,16 @@ sim_io_error (SIM_DESC sd, const char *fmt, ...) /****/ +void NORETURN +error (const char *msg, ...) +{ + va_list ap; + va_start(ap, msg); + callbacks->evprintf_filtered (callbacks, msg, ap); + va_end(ap); + callbacks->error (callbacks, ""); +} + void * zalloc(long size) { -- John Baldwin