Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Chris Johns <chrisj@rtems.org>
To: John Baldwin <jhb@freebsd.org>, gdb@sourceware.org
Subject: Re: gdb-7.12 powerpc-rtems4.12-gdb does not build on FreeBSD.
Date: Thu, 24 Nov 2016 00:30:00 -0000	[thread overview]
Message-ID: <58363493.6010108@rtems.org> (raw)
In-Reply-To: <1893490.1c09n3VfH9@ralph.baldwin.cx>

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


  reply	other threads:[~2016-11-24  0:30 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 [this message]
2016-11-24  2:48       ` John Baldwin
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=58363493.6010108@rtems.org \
    --to=chrisj@rtems.org \
    --cc=gdb@sourceware.org \
    --cc=jhb@freebsd.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