From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3022 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: pthread_getattr_np Date: Sun, 31 Mar 2013 22:51:39 +0200 Message-ID: <20130331205139.GI30576@port70.net> References: <20130331173518.GH30576@port70.net> <20130331180717.GI20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1364763109 1517 80.91.229.3 (31 Mar 2013 20:51:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Mar 2013 20:51:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3023-gllmg-musl=m.gmane.org@lists.openwall.com Sun Mar 31 22:52:17 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UMPEe-0007JA-6V for gllmg-musl@plane.gmane.org; Sun, 31 Mar 2013 22:52:16 +0200 Original-Received: (qmail 5965 invoked by uid 550); 31 Mar 2013 20:51:51 -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 5957 invoked from network); 31 Mar 2013 20:51:51 -0000 Content-Disposition: inline In-Reply-To: <20130331180717.GI20323@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3022 Archived-At: * Rich Felker [2013-03-31 14:07:17 -0400]: > Getting the high address (or "top" as you've called it) is trivial; > your efforts to find the end of the last page that's part of the > "stack mapping" are unnecessary. Any address that's past the address > of any automatic variable in the main thread, but such that all pages > between are valid, is a valid choice for the upper-limit address. The yes but rlimit counts from the high end of the stack so if [highend-rlimit, highend] method is used then you have to find the real high end to have a good lowend > hard part is getting the lower-limit. The rlimit is not a valid way to > measure this. For example, rlimit could be unlimited, or the stack > might have already grown large before the rlimit was reduced. yes but there is no valid way: the libs i saw queried this info once, even though rlimit can change and one can map or unmap areas in the way of the stack growth so the api only makes sense if one does not do such things, in which case rlimit gives a useful estimate > In practice, it seems like GC applications only care about the start > (upper limit) of the stack, not the other end; they use the current > stack pointer for the other limit. We could probe the current stack > pointer of the target thread by freezing it (with the synccall magic), > but this seems like it might be excessively costly for no practical > benefit... eg. address sanitizer creates a shadow map for the stack so at least it needs a reasonably sized upper bound on the stack size (but it does the /proc parsing magic itselfs for the main thread at startup so we don't have to support that) if the lowend is not used otherwise then we can give arbitrary result (eg always returning highend-5MB or using the rlimit truncated to some value when it's unlimited) all the calls to this function seem to use pthread_self() at thread creation or startup time, so synccall is probably not needed to get a sp to get a 'precize' lowend one can: 1) parse /proc/self/maps which gives the current [low,high] mapping and 'prev' the high end of the last mapping below the stack 2) if we are the main thread check if low <= sp <= high 3) check rlimit lowend = min(max(prev, high-rlimit, high-1G), low) then we can return [lowend,high] or [lowend,libc_high] (where libc_high is below the real high, but we need the real one for the calculations)