From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21833 invoked by alias); 24 Nov 2016 00:30:33 -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 21797 invoked by uid 89); 24 Nov 2016 00:30:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.8 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=baldwin, Baldwin, Johns, johns X-HELO: mail.contemporary.net.au Received: from msc1401703.lnk.telstra.net (HELO mail.contemporary.net.au) (139.130.245.200) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 24 Nov 2016 00:30:26 +0000 Received: from [10.10.5.3] (kiwi.contemporary.net.au [10.10.5.3]) (authenticated bits=0) by mail.contemporary.net.au (8.14.9/8.14.7) with ESMTP id uAO0UBA1011608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 24 Nov 2016 11:30:11 +1100 (EST) (envelope-from chrisj@rtems.org) Subject: Re: gdb-7.12 powerpc-rtems4.12-gdb does not build on FreeBSD. To: John Baldwin , gdb@sourceware.org References: <5834D6E0.9060601@rtems.org> <5836233A.7000407@rtems.org> <1893490.1c09n3VfH9@ralph.baldwin.cx> From: Chris Johns Message-ID: <58363493.6010108@rtems.org> Date: Thu, 24 Nov 2016 00:30:00 -0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1893490.1c09n3VfH9@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00043.txt.bz2 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. > 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 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. > If you see non-mangled symbols from sim_calls.o, I > would try building 7.12 as plain C to see if that fixes it for now. I will take a look and report back. If this works I will need to consider the path we take as doing this complicates the build matrix for RTEMS where we have a number of hosts and possibly differing versions of gdb across the supported architectures. Thanks Chris