From: John Baldwin <jhb@freebsd.org>
To: Pedro Alves <palves@redhat.com>
Cc: Chris Johns <chrisj@rtems.org>, gdb@sourceware.org
Subject: Re: gdb-7.12 powerpc-rtems4.12-gdb does not build on FreeBSD.
Date: Thu, 24 Nov 2016 17:47:00 -0000 [thread overview]
Message-ID: <7134105.CQ6yKBgfxn@ralph.baldwin.cx> (raw)
In-Reply-To: <3e3f8637-bd0c-4849-0430-1922a737f8f7@redhat.com>
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
next prev parent reply other threads:[~2016-11-24 17:47 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
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 [this message]
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=7134105.CQ6yKBgfxn@ralph.baldwin.cx \
--to=jhb@freebsd.org \
--cc=chrisj@rtems.org \
--cc=gdb@sourceware.org \
--cc=palves@redhat.com \
/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