[Tinycc-devel] alloca for tcc (x86) - second cut

[David A. Wheeler]

Here's a new and more wonderful (?) version of alloca for x86.  The last 
version was just the inner logic; this patch actually modifies the makefile and 
test infrastructure so it actually gets invoked automagically.

This patch doesn't reflect any of Rob Landley's comments (just got 'em), so I 
guess I'll comment on them here:

Rob Landley:
> Last I checked, tcc could also produce arm output.  I take it this is going 
> to 
> need an arm version of the .S file?  (This goes in... libtcc?)

Yes.  The final results will need to go into libtcc1.a.  I find it easier to 
write short assembly language files, compile each to .o files, and then use ar 
to snarf them up.  See the patches' changes to the Makefile for more.

I'm not planning to write the ARM code, but once the x86 code is working it 
shouldn't be hard to add by someone who wants it.

> There's no included change to the makefile to make anything actually use 
> this, 
> I take it you just make a .o from the .S, #include the .h and give it a try?  
> (I assume this isn't something I should attempt to merge just yet. :)

Right, I should have made that clearer.  I was mainly posting to show the 
direction I was going, so that people could comment on the approach.  Like 
these comments you posted :-).

> I'm not convinced increasing the size of the allocation is a plus...
> best thing I can do is make the results of their stupidity show up as 
> promptly and obviously as possible).

People are smart but make mistakes.  Unfortunately, mistakes often don't show 
up promptly... it's easy to smash the stack and not see the impact of it til 
WAY later.

> Could the extra memory for the bounds checker be guarded with an #ifdef of 
> some kind, please?

Yes, that's a good idea.  Of course, then we get to fight over the default :-).

I'll add that to the next version of the patch.

> The man page warns that the broken glibc headers unconditionally #define 
> alloca() as __builtin_alloca().  We might as well use that name rather than 
> trying to fight the FSF brain damage.

I decided to use _alloca_tcc instead.  In theory, any compiler's alloca() can 
be radically different, since it's dependent on the compiler's internals, and 
you might link in libraries compiled by something else (e.g., a tcc program 
calling a gcc-compiled library where BOTH use alloca).  By using different 
names, if gcc decides to do something really weird with alloca(), it won't 
affect us.

> Other than that, it looks good. :)

Good!

I need to add a padding configuration option, but otherwise I think this 
version's ready to go.  Thoughts?

--- David A. Wheeler

alloca.patch
Description: Text Data