[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJnvVWVXhyJG5BSpEaQioXjEnoMS98qvNqFxy7N5sjZ=rRZuyA@mail.gmail.com>
Date: Mon, 17 Nov 2014 03:26:24 +0200
From: Ivan Kanakarakis <ivan.kanak@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Possible bug: MINSIGSTKSZ values
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, 黄建忠 <jianzhong.huang@...oft.com.cn> 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.
>
>
> 在 11/15/14 11:18, Rich Felker 写道:
>
> 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
>
>
>
>
--
*Ivan c00kiemon5ter Kanakarakis* >:3
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
