From: John Baldwin <jhb@freebsd.org>
To: Chris Johns <chrisj@rtems.org>
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 [thread overview]
Message-ID: <2608815.dbYXHQl3xm@ralph.baldwin.cx> (raw)
In-Reply-To: <58363493.6010108@rtems.org>
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
next prev parent reply other threads:[~2016-11-24 2:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-22 23:38 Chris Johns
2016-11-23 23:16 ` Chris Johns
2016-11-24 0:16 ` John Baldwin
2016-11-24 0:30 ` Chris Johns
2016-11-24 2:48 ` John Baldwin [this message]
2016-11-24 12:12 ` Pedro Alves
2016-11-24 12:33 ` Pedro Alves
2016-11-24 14:02 ` Pedro Alves
2016-11-25 0:21 ` Chris Johns
2016-11-25 1:21 ` Pedro Alves
2016-11-25 4:06 ` Chris Johns
2016-11-24 14:19 ` John Baldwin
2016-11-24 14:59 ` Pedro Alves
2016-11-24 17:47 ` John Baldwin
2016-11-24 18:52 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2608815.dbYXHQl3xm@ralph.baldwin.cx \
--to=jhb@freebsd.org \
--cc=chrisj@rtems.org \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox