Re: gdb-7.12 powerpc-rtems4.12-gdb does not build on FreeBSD.

John Baldwin
2016-11-24T14:19:42Z

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