[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: |
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
Re: [Tinycc-devel] [PATCH] arm: Handle __builtin_frame_address(1) correctly, grischka, 2012/12/06