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

[Rob Landley]

On Wednesday 09 May 2007 12:56 am, David A. Wheeler wrote:
> 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. 

I need to get back up to speed on assembly language.  I am _hideously_ rusty 
at it, and it's getting in my way...

> > 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.  

I know.  But expanding the allocation for the purpose of hiding bugs isn't an 
improvement, either.  It makes it harder to find the bugs.  (Even if the bug 
never manifests in behavior, the code is still _wrong_ and future changes by 
people who didn't write the original code are the worst possible time to find 
out about it.)

I haven't used the bounds checking code, but I thought the purpose of that was 
to make the consequences of errors show up sooner rather than 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 :-). 

Um, what does CONFIG_TCC_BCHECK default to now?  (It's used in tcc.c...)

> 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.

Hmmm...  If we #include <alloca.h> do we get the tcc one first, or the glibc 
one first?  (I just glanced at tcc_set_output_type() and received eyestrain 
rather than enlightenment.)  It looks like on non-PE systems (a WEIRD way of 
saying "Linux") /usr/local/include and /usr/include are included first 
(except that I install tcc in /usr not /usr/local), and then the tcc library 
path is set from CONFIG_TCCDIR which config.h has as /usr/lib/tcc which comes 
_third_.

So unless this is getting searched in reverse order (quite possible, I haven't 
looked yet) the glibc version will get found first and the tcc built-in 
alloca won't get used (unless maybe you're linking against uClibc or klibc).

Ooh, there's a fun project: setup a system where tcc builds stuff against 
klibc.  (Hey, whatever libc.so is symlinked to, tcc will use...)


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

The padding configuration option would do what?  (You mean use 
CONFIG_TCC_BCHECK?)

> --- David A. Wheeler

Rob