[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20121019184135.GQ254@brightrain.aerifal.cx>
Date: Fri, 19 Oct 2012 14:41:35 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: TLS (thread-local storage) support
On Sat, Oct 20, 2012 at 02:39:43AM +0800, orc wrote:
> > 4) Compile musl with '-fsplit-stack' and add no_split_stack attribute
> > to appropriate functions (at least all functions called before
> > pthread_self_init because %gs or %fs register is unusable before this
> > call).
> >
> > 5) set main thread stack limit to 0 (pthread_self_init) : the main
> > thread stack grow is handled by the kernel.
> >
> > 6) add no-split-stack note to every asm file.
> Why anything works only after putting a weak spikes that break after a
> slight touch?
I don't follow what you're saying here.
> > 7) make split stack support optional (either by checking the
> > -fsplit-stack option in CFLAGS or with a specific option :
> > --enable-split-stack) : split stack adds overhead to every functions
> > (except for those with the 'no_split_stack' attribute).
> >
> > > Do you have any concern about adding those features in musl ?
> > >
> > > Let me know if you see other issues I haven't noticed.
> > >
> > >
> > > Regards,
> > >
> > > Boris
>
> After reading whole thread I agree with Rich that this one is not only
> hard to implement, but completely useless. From other point of view:
I think it's hard (read: probably impossible) to implement in a way
that's robust and correct, but it may not be too hard to implement the
minimal support code so that folks who insist on using -fsplit-stack
will not get pathologically bad behavior due to the calling code being
unaware that is already has a plenty pre-allocated stack space to run
on.
> people expect from musl an easy to read and understand code, that not
> only works, but is easy to understand, modify, debug and build. Why
> extend it with features not even related to libc? (It is mostly a hack
> from gcc-binutils again?)
I agree. I definitely don't want to compromise on
correctness/robustness for the sake of this, and I'd also like to
avoid adding complexity or maintenance burdens.
Rich
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.
