mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Solar Designer <solar@openwall.com>
To: musl@lists.openwall.com
Subject: Re: tough choice on thread pointer initialization issue
Date: Fri, 10 Feb 2012 11:40:02 +0400	[thread overview]
Message-ID: <20120210074002.GA13559@openwall.com> (raw)
In-Reply-To: <20120210025824.GA25414@brightrain.aerifal.cx>

Hi Rich,

Thank you for posting this!

On Thu, Feb 09, 2012 at 09:58:25PM -0500, Rich Felker wrote:
> approach 1: hack the signal-return "restore" function to save the
> current thread register value into the struct sigcontext before
> calling SYS_sigreturn, so that it will be preserved when the
> interrupted code resumes.
> 
> pros: minimal costs, never adds any syscalls versus current musl.
> 
> cons: ugly hack, and gdb does not like non-canonical sigreturn
> functions (it refuses to work when the instruction pointer is at
> them).
> 
> 
> approach 2: call pthread_self() from sigaction(). this will ensure
> that a signal handler never runs prior to the thread pointer being
> initialized.
> 
> pros: minimal code changes, and avoids adding syscalls except for
> programs that use signals but not threads.
> 
> cons: adds a syscall, and links unnecessary thread code when static
> linking, in any program that uses signal handlers.

I think another con of the two approaches above is that they'll fail if
a program sets up a signal handler in a way bypassing musl (and other
prerequisites of the problem are met as well, as you described them).
Indeed, this makes it even more of a special case, but it's still legal
(or not? that's a musl policy thing I guess).

> approach 3: always initialize the thread pointer from
> __libc_start_main (befoe main runs). (this is the glibc approach)
...

> before i make a decision, i'd like to hear if anyone from the
> community has strong opinions one way or the other. i've almost ruled
> out approach #1 and i'm leaning towards #3, with the idea that
> simplicity is worth more than a couple trivial syscalls.

Not a strong opinion, but how about:

approach 4: initialize the thread pointer register to zero at program
startup.  Then before its use, just check it for non-zero instead of
checking a global flag.  (I presume that you're doing the latter now,
based on your description of the problem.)

Alexander


  reply	other threads:[~2012-02-10  7:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-10  2:58 Rich Felker
2012-02-10  7:40 ` Solar Designer [this message]
2012-02-10  7:58   ` Rich Felker
2012-02-10 10:42     ` Solar Designer
2012-02-10 11:22       ` Solar Designer
2012-02-10 17:00       ` Rich Felker
2012-02-10 19:12         ` Solar Designer
2012-02-25  6:56 ` Rich Felker
2012-02-25 13:32   ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120210074002.GA13559@openwall.com \
    --to=solar@openwall.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).