This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/16291] feature request: provide simpler ways to compute stack and tls boundaries
- From: "konstantin.s.serebryany at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 04 Dec 2013 14:49:46 +0000
- Subject: [Bug libc/16291] feature request: provide simpler ways to compute stack and tls boundaries
- Auto-submitted: auto-generated
- References: <bug-16291-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16291
--- Comment #6 from Kostya Serebryany <konstantin.s.serebryany at gmail dot com> ---
(In reply to Ondrej Bilka from comment #5)
> Adding a thread-local variable with current bounds would be more
You mean, glibc can export thread-local variables for stack bounds and TLS
bounds?
That will be very convenient for us, but will consume some amount of TLS,
so if I were a glibc developer I would think twice.
> appropriate. It is interesting from other reasons, for example deciding if
> memory should be allocated by alloca or malloc.
Hmm. Interesting indeed, although a bit scary.
Suppose you have a deep recursion and before the recursion starts
(i.e. you have plenty of stack) you decide to replace large malloc with alloca.
One should use this nice hack with caution.
>
> As performance is concerned you cannot do much better, as malloc already
> uses tls you can avoid that overhead.
>
> Also how do you handle split-stacks? Its gcc feature that does more harm
> than good so do you support that?
I don't think anyone ever used split-stacks with AddressSanitizer,
they will hardly work together.
--
You are receiving this mail because:
You are on the CC list for the bug.