From: John Baldwin <jhb@freebsd.org>
To: gdb@sourceware.org
Cc: Pedro Alves <palves@redhat.com>
Subject: Re: C++ conversion status update
Date: Tue, 19 Apr 2016 19:26:00 -0000 [thread overview]
Message-ID: <4587615.ZrrbCebxpz@ralph.baldwin.cx> (raw)
In-Reply-To: <57151080.3000900@redhat.com>
On Monday, April 18, 2016 05:51:12 PM Pedro Alves wrote:
> On 04/16/2016 01:21 AM, Pedro Alves wrote:
> > Yes, agreed. I've sent a patch that does that to the
> > list now:
> >
> > https://sourceware.org/ml/gdb-patches/2016-04/msg00374.html
> >
> > If you could give it a try it'd be much appreciated. I've pushed
> > it to the users/palves/ptrace-detection branch (at sourceware.org)
> > as well, for convenience.
>
> FYI, a fix is in master now.
Thanks, I was able to test it and it works great on FreeBSD/amd64.
I have a set of simple C++ build fixes for fbsd-nat.c I will post to patches@
in a bit.
The only remaining issue is that FreeBSD's stack_t defines ss_sp as char *
instead of void *. Apparently 4.4BSD had this and the other BSD's fixed this
long ago. When I first ran into this in January I fixed FreeBSD's trunk, so
11.0 will ship with a proper ss_sp of void *, but older releases will not.
The affected code is in setup_alternate_signal_stack() in gdb/main.c where
ss_sp is assigned to the void * returned from xmalloc().
I was torn between just supporting C++ builds on FreeBSD 11 and later, or
adding autoconf glue for just this part. However, given that it seems like
the recent discussion is to deprecate C mode in the near future, it seems
like I should do the latter. Do you have any better suggestions?
--
John Baldwin
next prev parent reply other threads:[~2016-04-19 19:26 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-24 13:07 Pedro Alves
2015-12-14 14:40 ` Yao Qi
2015-12-14 19:09 ` Pedro Alves
2015-12-15 11:39 ` Jose E. Marchesi
2015-12-15 20:03 ` Simon Marchi
2015-12-16 0:19 ` Pedro Alves
2015-12-16 0:21 ` Pedro Alves
2015-12-16 1:19 ` Simon Marchi
2015-12-16 20:11 ` Pedro Alves
2015-12-16 20:15 ` Pedro Alves
2015-12-16 20:30 ` Simon Marchi
2015-12-16 22:10 ` Pedro Alves
2015-12-16 22:59 ` Pedro Alves
2016-01-19 19:00 ` John Baldwin
2016-01-20 11:10 ` Pedro Alves
2016-01-20 23:33 ` John Baldwin
2016-01-21 11:38 ` Pedro Alves
2016-04-16 0:21 ` Pedro Alves
2016-04-18 16:51 ` Pedro Alves
2016-04-19 19:26 ` John Baldwin [this message]
2016-04-19 20:36 ` Pedro Alves
2016-04-19 21:40 ` John Baldwin
2016-04-19 22:20 ` Pedro Alves
2016-04-13 0:25 ` Pedro Alves
2016-04-13 11:07 ` Yao Qi
2016-04-13 14:13 ` Pedro Alves
2016-04-13 14:31 ` Sergio Durigan Junior
2016-04-13 12:41 ` Joel Brobecker
2016-04-13 14:04 ` Pedro Alves
2016-04-13 14:16 ` Joel Brobecker
2016-04-13 14:27 ` Luis Machado
2016-04-13 14:35 ` Marc Khouzam
2016-04-13 14:59 ` Joel Brobecker
2016-04-13 14:40 ` Pedro Alves
2016-04-18 17:29 ` 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=4587615.ZrrbCebxpz@ralph.baldwin.cx \
--to=jhb@freebsd.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