This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Use malloca instead alloca
On 01/09/2013 05:44 PM, Rich Felker wrote:
On Wed, Jan 09, 2013 at 05:09:23PM +0100, Florian Weimer wrote:
On 01/08/2013 09:41 PM, OndÅej BÃlka wrote:
One technical issue is if we want to use STACKINFO_BP_DEF. It would make
getting base pointer more portable but must be added to each function
that uses __libc_use_alloca.
I'm interested in extending GCC to provide a better alloca,
including one that can fail. Parts of the split stacks support
might reusable for obtaining the stack boundary.
We spent a bit of time analyzing whether split stack is useful on the
musl list, and concluded that for the most part it's just harmful. For
64-bit systems, it has no significant advantages over just allocating
large stacks and letting the kernel do overcommit.
This really depends on your environment. Some systems have lightweight
processes with a baseline cost of less than a page. I agree that if you
need more than a page for other reasons, split stacks are probably not
that interesting.
Anyway, to clarify, I'm not interested in enabling split stacks per se.
But the split stack support records the stack boundary in a TLS
variable, and __builtin_alloca could use that to check (reasonably
cheaply, both in terms of code size and run-time cost) that the
allocation attempt doesn't exceed the available space. It would be a
bit like -fcheck-stack, but hopefully much cheaper because the stack
banging logic isn't needed.
I'm a bit skeptical about the whole alloca-if-we-have-room concept.
We must make sure that we keep sufficient stack space for further
operation. But I'm not sure how to determine the magic number of
bytes to reserve.
I agree entirely. It strikes me as just as misguided as when
application developers ask "how to I check how much memory the system
has so I can hoarde it all?" If you're making what you use
proportional to what's available rather than to what you need, you're
doing something wrong.
Good analogy.
Honestly, my recommendation would be to ban use of alloca and VLA
entirely and replace them by small fixed-size arrays (like 256-1024
bytes depending on the expected usage), and simply call malloc when
the need is greater than the fixed size. This makes the free logic
easy (if (ptr!=fixed_buf) free(ptr);) and reduces the code size and
improves performance in the common cases (since the compiler can
generate better, simpler code when it does not need to do the
frame-pointer-like logic for managing dynamic-size allocations on the
stack.
As long as there's alloca, developers will use it. It's quite popular
even in new code. I suspect it's not just the performance aspect, the
implicit free() is likely a factor, too.
I'm not sure if we can change this preference, at least until we have
conservative garbage collection as part of libc (so that heap allocation
and stack allocation are equally simple).
--
Florian Weimer / Red Hat Product Security Team