From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99527 invoked by alias); 24 Nov 2016 02:48:40 -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 99389 invoked by uid 89); 24 Nov 2016 02:48:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=baldwin, Baldwin, Johns, johns 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 02:48:27 +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 C840110AA27; Wed, 23 Nov 2016 21:48:25 -0500 (EST) From: John Baldwin To: Chris Johns Cc: gdb@sourceware.org Subject: Re: gdb-7.12 powerpc-rtems4.12-gdb does not build on FreeBSD. Date: Thu, 24 Nov 2016 02:48:00 -0000 Message-ID: <2608815.dbYXHQl3xm@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) In-Reply-To: <58363493.6010108@rtems.org> References: <5834D6E0.9060601@rtems.org> <1893490.1c09n3VfH9@ralph.baldwin.cx> <58363493.6010108@rtems.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00044.txt.bz2 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. > > Looking at sim/ppc/Makefile.in, it only references CC, not CXX, so I would not > > be surprised if it compiles as C without mangled symbols giving the error you > > have. > > Interesting. I will take a closer look. Maybe something on Linux is > building the sim/ppc as C++ and this does not happen with clang. I'm not sure why this isn't also broken on Linux. > I think 7.12 can still be built as C, though you might need to use a > > configure flag to do so? > > Really? I see code in 'gdbtypes.h' of 'enum type_code { ... }' and that > looks C++ and not C to me. C supports enums. However, GDB 7.12 has several macros for things like TRY/CATCH that use try/catch for C++ and setjmp/longjmp in C, etc. The next release of GDB will require C++ (and C++11 in fact). -- John Baldwin