This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]