This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC][PR 67336][PING^6] Verify pointers during stack unwind
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Yuri Gribov <tetra2005 at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Ian Lance Taylor <ian at airs dot com>, Andrew Pinski <pinskia at gmail dot com>
- Date: Wed, 2 Aug 2017 20:47:06 +0200
- Subject: Re: [RFC][PR 67336][PING^6] Verify pointers during stack unwind
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jakub at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1005513A97
- References: <CAJOtW+4_FR+1zBiTvL_EBN7NGj-S9=7cR5Qsm560P7XsyLfFzA@mail.gmail.com> <96fda4ab-0c92-96ea-1993-5c235b1a8b03@redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Aug 02, 2017 at 12:38:13PM -0600, Jeff Law wrote:
> On 07/17/2017 01:23 AM, Yuri Gribov wrote:
> > I've rebased the previous patch to trunk per Andrew's suggestion.
> > Original patch description/motivation/questions are in
> > https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01869.html
> Is his stuff used for exception handling? If so, doesn't that make the
> performance a significant concern (ie that msync call?)
For the performance issue, I wonder if it wouldn't be better to just
compile the unwinder twice, basically include everything needed for the
verification backtrace in a single *.c file with special defines, and
not export anything from that *.o file except the single entrypoint.
That would also handle the ABI problems.
For the concurrent calls of other threads unmapping stacks of running
threads (that is where most of the verification goes against), I'm afraid
that is simply non-solveable, even if you don't cache anything, it will
still be racy.
Jakub