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

On Thursday, November 24, 2016 02:59:47 PM Pedro Alves wrote:
> On 11/24/2016 02:18 PM, John Baldwin wrote:
> > On Thursday, November 24, 2016 12:12:45 PM Pedro Alves wrote:
> 
> >> 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():
> 
> Ah, yes, that's indeed simpler than what I was going for (see below, incomplete).
> Yours should be able to go to both 7.12 and master.  Please send it to gdb-patches.

Will do.  It may be cleaner long term to use sim-specific error routines as your
patch does.

> This exposes something else that needs to be done, as long
> as the sim is C -- gdb/remote-sim.c:gdb_os_error (which is
> what host_callback->error is set to, throws a C++ exception,
> and that will want to cross the sim.  But that will only work
> if the sim is build with -fexceptions (which is the default
> on x86_64).  So we either need to always build the sim explicitly
> with -fexceptions, or we need to longjmp out of the sim instead
> of throwing a C++ exception.  E.g., wrap calls into the sim
> with TRY_SJLJ/CATCH_SJLJ and make gdb_os_error use
> throw_exception_sjlj, like we handle longjmp-ing across
> readline.

Do you think the sims will eventually want to use C++?  If so, switching them
to build as C++ seems like less work overall as it would solve this while being
a step towards that direction.  If sims need to stay plain C, then I think I
prefer the setjmp/longjmp approach.

-- 
John Baldwin