tinycc-devel
[Top][All Lists]
Advanced

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

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


From: Kirill Smelkov
Subject: Re: [Tinycc-devel] Fixes to bcheck and how it works correctly
Date: Fri, 21 Dec 2012 20:54:56 +0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Dec 12, 2012 at 04:19:50PM +0100, grischka wrote:
> 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
>    vdrop/vpop.
> 
> But I guess I like your solution best, for now.  ;)

I too, first tried similiar steps, then come to vstack macro :)


> >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
> arithmetics.
> 
> 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 ;)

Aaaargh, no time!!! I mean I could possibly do it in between
distant-future and never...


> By the way the issue reminds me of some email that I received from
> Fabrice once in 2007, where he wrote:
> 
> >Hi,
> >
> [1]
> >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 !
> >
> [2]
> >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.
> >
> [3]
> >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 ?
> >
> >Regards,
> >
> >Fabrice.
> 
> As to [1] "TCG", see also this (Fabrice's reply below):
>     http://landley.net/notes.html#14-05-2012
> 
> 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:
>     https://play.google.com/store/apps/details?id=com.n0n3m4.droidc&hl=en
> 
> Thanks,
> 
> --- grischka


On Wed, Dec 12, 2012 at 08:49:34PM +0100, grischka wrote:
> Kirill Smelkov wrote:
> >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...
> 
> Actually in bcheck.c:__bound_ptr_add there appears to be a special case
> for code such as
> 
>       int a[10], *p;
>       for (p = a; p < a + 10; ++p)
>               *p = p - a;
> 
> to ignore the off by one pointer addition at end of region.  Now what
> about the also not so uncommon reverse case
> 
>       int a[10], *p;
>       for (p = a + 10; --p >= a;)
>               *p = p - a;
> 
> I don't think I would like to change that just for bcheck.  Then again
> if that were allowed, the vtop stuff in TCC could stay as it was, I
> suppose?

Grischka, I agree bcheck has its limitations in desing and in order to
operate correctly on every C code should be reworked. But sorry, I can't
digg into this - as it is now I'm not using it - it was just a weekend
etude to fix what was broken...


Sorry,
Kirill



reply via email to

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