From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6528 Path: news.gmane.org!not-for-mail From: Ivan Kanakarakis Newsgroups: gmane.linux.lib.musl.general Subject: Re: Possible bug: MINSIGSTKSZ values Date: Mon, 17 Nov 2014 03:26:24 +0200 Message-ID: References: <20141115031843.GA3679@brightrain.aerifal.cx> <54694CD4.5070501@i-soft.com.cn> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3d28453cc96050803e0ac X-Trace: ger.gmane.org 1416187644 14818 80.91.229.3 (17 Nov 2014 01:27:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Nov 2014 01:27:24 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6541-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 17 02:27:19 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XqB66-000758-TW for gllmg-musl@m.gmane.org; Mon, 17 Nov 2014 02:27:19 +0100 Original-Received: (qmail 30371 invoked by uid 550); 17 Nov 2014 01:27:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 30363 invoked from network); 17 Nov 2014 01:27:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=0sZer/n1d84XrfOGc95y9j7zpdA6Lfoo7BbmVyN2FEM=; b=oKWtCN6livjZAT5Nl7noLjSioK56haHotSpL6uB2EnTPrqkhXVFDtbTMjQ/IJQH/22 WWylsGrRMHJScUT4/Xk0FvMK92DTNcIKRVSvbk+UY2SyzvukbCAVN/Nd81XDFFiM8i3N 6+S9AtstCx4p24OxdLutImKwgKU1m1gghs3iSZjD/ypbM26IVXnZVL9fxu2RrJqqOZEx z46LmXB7ubk/Ueh4ktLo0+SvMtyZjtZcmFKg5izYArLrICDZ3A/MtKJ197FZuqF83cHV 1kwVZKCY64RqX93OFZTbgleKcjovRmw0lUSlwBNgOqWYf3a32JYV8hMco/xWEmUODjln ByHw== X-Received: by 10.224.89.69 with SMTP id d5mr30718465qam.84.1416187625051; Sun, 16 Nov 2014 17:27:05 -0800 (PST) In-Reply-To: <54694CD4.5070501@i-soft.com.cn> Xref: news.gmane.org gmane.linux.lib.musl.general:6528 Archived-At: --001a11c3d28453cc96050803e0ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There will never be a __MUSL__ macro. Please, see FAQ entry #2 for explanation http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F On 17 November 2014 03:18, =E9=BB=84=E5=BB=BA=E5=BF=A0 wrote: > Hi, Rich, > > If that means some opensource projects need to be modified to fit Musl, > would you consider to add a "__MUSL__" macro? > > I think such a special macro will make upstream patch easy to be accepted= . > > > =E5=9C=A8 11/15/14 11:18, Rich Felker =E5=86=99=E9=81=93: > > Currently musl has MINSIGSTKSZ hard-coded as 2048. This is >> insufficient to store the ucontext_t for many archs. I'd like to keep >> it small on archs where that's possible, but the current value might >> not even work for modern x86 with large AVX state, etc. that needs to >> be saved. I don't have a proposed fix yet, but I think we should >> survey the values that are needed for different archs and either make >> it vary per-arch, or if they're all comparable, just increase the >> value to something that works for all archs. >> >> Note that the min pthread stack size is also well below the size of >> ucontext_t for many archs, but I don't think this is a problem. If you >> make a thread with a stack smaller than MINSIGSTKSZ+epsilon, you just >> need to start it with all signals blocked and leave them blocked (or >> avoid using signal handlers at all). >> >> Rich >> >> > > -- > Huang JianZhong > > > > --=20 *Ivan c00kiemon5ter Kanakarakis* >:3 --001a11c3d28453cc96050803e0ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There will never be a __MUSL__ macro.
Please,= see FAQ entry #2 for explanation
http://wiki.musl-libc.org= /wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F


On = 17 November 2014 03:18, =E9=BB=84=E5=BB=BA=E5=BF=A0 <<= a href=3D"mailto:jianzhong.huang@i-soft.com.cn" target=3D"_blank">jianzhong= .huang@i-soft.com.cn> wrote:

Currently musl has MINSIGSTKSZ hard-coded as 2048. This is
insufficient to store the ucontext_t for many archs. I'd like to keep it small on archs where that's possible, but the current value might not even work for modern x86 with large AVX state, etc. that needs to
be saved. I don't have a proposed fix yet, but I think we should
survey the values that are needed for different archs and either make
it vary per-arch, or if they're all comparable, just increase the
value to something that works for all archs.

Note that the min pthread stack size is also well below the size of
ucontext_t for many archs, but I don't think this is a problem. If you<= br> make a thread with a stack smaller than MINSIGSTKSZ+epsilon, you just
need to start it with all signals blocked and leave them blocked (or
avoid using signal handlers at all).

Rich



--
Huang JianZhong






--
Ivan c00kiem= on5ter Kanakarakis =C2=A0>:3=C2=A0
--001a11c3d28453cc96050803e0ac--