This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf
- From: Carlos O'Donell <carlos at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, "Tsimbalist, Igor V" <igor dot v dot tsimbalist at intel dot com>
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 8 Mar 2018 16:47:08 -0800
- Subject: Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf
- Authentication-results: sourceware.org; auth=none
- References: <20180201205757.51911-1-hjl.tools@gmail.com> <877er1b4zp.fsf@mid.deneb.enyo.de> <CAMe9rOrZaz2RbcHBZ8MSjx0VaLpNxd=8RhmJoXmH0fps6qTYHA@mail.gmail.com> <87371pb3ga.fsf@mid.deneb.enyo.de> <CAMe9rOqPkq7gQ1e6EE-87kVuBnMZrqmOeNExQ1ZmGsqufZu3MQ@mail.gmail.com> <87tvu59o21.fsf@mid.deneb.enyo.de> <CAMe9rOqRz=YR78QqD_EqAagZ3yr1v8jqJvn2WuF=8KCJp9csfw@mail.gmail.com> <87po4t9mxt.fsf@mid.deneb.enyo.de> <CAMe9rOpcDM0hp_h1EomZrjaR2raSiS5kB-B0o6fFRBZ9ysA=Ew@mail.gmail.com> <3764b0a1-9f26-6f5f-1bc5-d374f2672f3a@redhat.com> <CAMe9rOrA+yv2E8u0NjAMMhPkpL5+rk6TuhCj7dhBiupryUGQ7w@mail.gmail.com> <86d5d5ba-2b53-1904-dada-3efe2b3ad501@redhat.com> <CAMe9rOqGDo4SpTQ=BBRK+RJcVVN3M9WQxwWFJjK+k=+nvTPAOg@mail.gmail.com> <CAMe9rOpVQ9oEK0WYdPvR_1nuvkpwXy3Rsy5UYsXvOnScRu2toA@mail.gmail.com> <CAMe9rOp_b2vtkJqc=0vf1rzk2==e3YA4W4Dvkp=FqopmswfoLg@mail.gmail.com> <D511F25789BA7F4EBA64C8A63891A0029EF8ABE2@irsmsx105.ger.corp.intel.com> <CAMe9rOpbXhsfwmhUT8wx4bZzav_bVETioK=03zE4i4ERcZvX5w@mail.gmail.com>
On 03/08/2018 04:48 AM, H.J. Lu wrote:
> True. This is the patch I have tested:
>
> https://github.com/hjl-tools/gcc/commit/e98087865405f051e93d5f35588789ef9686db4a
I assume NOTRACK prefix is what Intel calls 'NO_TRACK_EN' in the CET
documentation since binutils uses the 0x3E prefix for it and that matches
the Intel CET docs. Please correct me if I'm wrong.
In which case I agree, using NOTRACK is going to prevent a useful use
of CET against writes to the cancellation jump buffer.
This patch looks good to me, but is not a *correctness* issue, it is
simply that we want to extend coverage to the private cancellation
setjmp/longjmp buffers.
Is there any way we can do this with source markup instead of via
a fragile list in the compiler?
Presumably users may want to markup their own code like this also
if they have custom implementations of functions that behave like
setjmp/longjmp?
--
Cheers,
Carlos.