[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Fixes to bcheck and how it works correctly

From: grischka
Subject: Re: [Tinycc-devel] Fixes to bcheck and how it works correctly
Date: Wed, 12 Dec 2012 16:19:50 +0100
User-agent: Thunderbird (Windows/20090812)

Kirill Smelkov wrote:
Overall I liked original vstack and vtop assignment rules, only it had
to deal with initial vstack-1 somehow. And documentation about vstack
and vtop and everything else stays the same. I don't insist my way is
good 100% good though...

Yeah, that is the problem: we like the original and still it seems that
we need to change it.

Anyway, I tried both:
1) stay with pre-increment vtop, but replace any "vstack" by
   "vstack + 1" in place.

   Conclusion: doable but ruins the original design, somehow.

2) switch to post-increment vtop, using macros also:

       ST_DATA SValue vstack[VSTACK_SIZE], *vstack_top;
       #define vtop (vstack_top - 1)
       #define vdrop(n) (vstack_top -= n)

   and replace all "vtop--" by "vdrop(1)"

   Conclusion: pervasive but doable, does not waste vstack[0],
   might be slightly slower because all access "vtop->xxx"
   now includes offset -1.  vtop as macro is not that nice but
   has the advantage that it can't be lvalue, so that one can
   find any real vstack modification more easily by searching

But I guess I like your solution best, for now.  ;)

Let's imagine that bcheck checks pointers only on dereference. Then
let's consider following:

    int a[10], b[10];

If we have p=&b[0], then do p--, how do we know whether there is no
bounds error for p? p points to correct memory &a[9], but it is out of
bounds - it started from b and crossed the limit.

That's why in lib/bcheck pointers are checked not only on indir, but
also on add. And that's why we have to pay the price. Btw - maybe "not
ansi" comment was there for a reason...

Yes, that was I wondered: How can it track relation between some
specific pointer variable and the associated memory region?  So as
you explain the trick (and price) is to watch (and restrict) pointer

I'm figuring that there could be a way to just "memorize" pointer
arithmetics and postpone the check until real access later.  But that
might be a bigger project.

Nevermind. Here is what I've learned about how lib/bcheck.c works:

Memory is treated as regions. Every region could be either [...]

Great.  Please feel encouraged to put such details (also restrictions,
supported platforms etc.) into tcc-doc.html.  In order to help the
"1st class citizen bcheck" theme, I mean ;)

By the way the issue reminds me of some email that I received from
Fabrice once in 2007, where he wrote:


For your information I working on a new code generator for QEMU. I am designing
it so that it is possible to use it in TCC, but it will require a non negligible
amount of work !

Another point is that I realized that the bound check region algorithm used in
TCC is completely broken (the code to search the region associated to a pointer
does not work in all cases). I think the only way to make it work reliably is
to tag each allocated byte with one bit.

A last point is that I wonder whether it would be good to change the TCC license
to BSD like. Would you agree on that ?



As to [1] "TCG", see also this (Fabrice's reply below):

As to [2] "bcheck", I didn't plan to fix it so I didn't ask what exactly
he meant.  Maybe you know better, by now.

As to [3] "BSD", I think I was trying to ask on this list but the echo
wasn't like pursuing and the question is probably over by now.

Also I think that LGPL probably does fit quite well our "mob" approach
because as quite some people (except maybe Rob L.) would agree:  If one
wanted to lift tinycc onto a more say professionally attractive level,
it would be easier to rewrite some substantial parts than to fiddle
with existing complications.

Apropos, some people appear to do Android Apps using arm_tcc to run C
on the fly in the phone:


--- grischka

reply via email to

[Prev in Thread] Current Thread [Next in Thread]