On Wed, 27 Nov 2019, Herman ten Brugge wrote:
Exactly. So we need to make a decision if we want that extension of the
bounds-checking feature in TCC under these constraints. In my opinion we
don't want to, but I won't stand in the way of extending it to locals (but
then the comment needs adjustment to talk about the expected larger
overhead for each local).
I found some other code that uses the address off a local variable. See
I can find more code like this :-(
Exactly my point. bounds-checking in TCC is a cute hack, but nothing
more. With other compilers gaining capabilities like sanitizers, plus
valgrind and friends, I think the value of that feature in tcc
asymptotically goes to zero.
So these hooks are deprecated. We could fix this by including our own
malloc/free routines. For a simple one see for example:
Yeah, well, there are many allocators out there, simple and complex. I
don't think we should include any for this half-broken feature, especially
because it doesn't really help. You would have to rewrite all calls to
malloc/free/realloc in the sources you see to redirect to the new
allocator. The sources you don't see can't be rewritten, so any pointers
you get from libraries can't be bounds-checked. That's the whole point of
using the malloc hooks, you can intercept _all_ calls to the allocation
routines, even from foreign libraries. Without hooks you aren't going to
Of course the same can be achieved on ELF platforms via symbol
interposition. And once you do that, you don't need hooks anymore, but
you also don't need a custom allocator.
Indeed. But some more things are wrong: even with your full bounds patch,
but moving the definition of 's' to file global level, the output is still
You just found another bounds checking problem :-)
I fixed this with some push/pop trickery. This probably could be
improved. I have now added a minimum patch so bounds checking works a
little bit. We need still to fix the shared lib reloc problems and the
Do we? Can we perhaps also simply declare bounds checking to work only
with the main executable? Or remove that whole feature altogether?
Probably we also need to track the address off so
code runs faster.
I don't see a way for that except giving up on the single pass nature of
TCC, at which point it wouldn't be a tiny C compiler anymore.