This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 7 Dec 2017 17:58:14 +0000
- Subject: Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
- Authentication-results: sourceware.org; auth=none
- References: <20171207174057.GA32196@gmail.com>
On Thu, 7 Dec 2017, H.J. Lu wrote:
> On x86, padding in struct __jmp_buf_tag is used for shadow stack pointer
> to support shadow stack in Intel Control-flow Enforcemen Technology.
> Since the cancel_jmp_buf array is passed to setjmp and longjmp by
> casting it to pointer to struct __jmp_buf_tag, it should be as large
> as struct __jmp_buf_tag. This patch adds pthread.h, pthreaddef.h and
> pthreadP.h for Linux/x86 to define a new cancel_jmp_buf to match
> struct __jmp_buf_tag.
Duplicating the installed pthread.h is a bad idea (in general, we should
avoid having architecture-specific variants of installed headers as much
as possible, and, especially, define APIs in architecture-independent
headers and limit architecture-specific variants to as few constants or
structures as possible, those going in bits/ headers that at least people
expect to have multiple variants).
Thus, we should aim to eliminate the hppa-specific variant of pthread.h by
creating a bits/ header that has the minimum information required to
encapsulate the hppa variations (or putting such information in an
existing bits/ header, if appropriate), and likewise for whatever the
differences are in your x86 variant. We should certainly not create a new
x86 variant of the whole of pthread.h.
Joseph S. Myers