From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52707 invoked by alias); 13 Nov 2017 16:34:52 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 52232 invoked by uid 89); 13 Nov 2017 16:34:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Subject: Re: [PATCH 2/2] jmpbuf: Add paddings for target specific usage To: "H.J. Lu" Cc: GNU C Library References: <20171107223908.GB46190@intel.com> <33f4a80e-b377-a9c8-1fba-c136211154be@redhat.com> <7874b7d1-bf58-4fb2-b3e3-aba07db76bfa@redhat.com> From: Florian Weimer Message-ID: <3a270ef7-eae6-e8cb-f7bb-7de8b9a926dc@redhat.com> Date: Mon, 13 Nov 2017 16:34:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-11/txt/msg00403.txt.bz2 On 11/13/2017 03:05 PM, H.J. Lu wrote: > On Mon, Nov 13, 2017 at 5:09 AM, Florian Weimer wrote: >> On 11/08/2017 07:27 PM, H.J. Lu wrote: >>> >>> +/* The biggest signal number + 1 */ >>> +#define _JUMP_BUF_SIGSET_NSIG 257 >>> +/* Number of longs to hold all signals. */ >>> +#define _JUMP_BUF_SIGSET_NWORDS \ >>> + ((_JUMP_BUF_SIGSET_NSIG - 1 + 7) / (8 * sizeof (unsigned long int))) >> >> >> Where does 257 come from? 65 or 129 I would understand considering the >> kernel sources, but 257 is odd. Oh. I'm not sure if we should put this into installed header. Maybe we can use a different approach? Something similar to the pthread types? Or just not change the external type at all and just ad some internal space reuse mechanism? We had problems with people poking at supposedly invisible jmpbuf contents in the past, and I'm worried that adding even __ members will encourage that. >> I think it would be clearer to hard-code the array sizes and explain why the >> values where chosen in that way. >> >> We also need a test that setprocmask does not read from the previously > > Did you mean "sigprocmask"? Right. >> unused part. I can move the existing next_to_fault bits to support/ if that >> would help. > > Yes, please. Okay, I'll move it to support/ soon. Thanks, Florian