[Top][All Lists]

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

Re: [Tinycc-devel] Largish mob update from me

From: grischka
Subject: Re: [Tinycc-devel] Largish mob update from me
Date: Tue, 20 Dec 2016 18:17:27 +0100
User-agent: Thunderbird (Windows/20090812)

Michael Matz wrote:
Unfortunately I had to add one other place where it checks nocode_wanted
and that's in the ugly dealing with VT_CMP/VT_JMP values in vtop.  See
testcases in the above, and my comment included here for citing/discussing:

+       Don't do this when nocode_wanted.  vtop might come from
+       !nocode_wanted regions (see 88_codeopt.c) and transforming
+       it to a register without actually generating code is wrong
+       as their value might still be used for real.  All values
+       we push under nocode_wanted will eventually be popped
+       again, so that the VT_CMP/VT_JMP value will be in vtop
+       when code is unsuppressed again.  */
+    if (vtop >= vstack && !nocode_wanted) {
         v = vtop->r & VT_VALMASK;
         if (v == VT_CMP || (v & ~1) == VT_JMP)

I hope I haven't broken anything that you've fixed with your three nocode_wanted patches ...

No, I guess it makes sense.  Except there is the same clause in
vswap() down below which we'll probably want to treat the same way.

Also I'd share the assumption that nocode-branches must be neutral
to vstack and it is up to the nocode-user to care about.

The gsym() in vpop() is ok IMO, it will fixup a jump chain on
vtop to the current "ind" pointer. That 'ind' doesn't change
under 'nocode' does not matter.

Btw, what's "pseudo leak" in a one-shot tool, in libtcc will write
to memory that already has been free'd by the underlying "TAL" manager.
Sorry if I didn't fix it it was just to watch my new memtest at work ;)

Vlad Vissoultchev's T(iny) AL(locater):

If someone wants to try the difference, comment out tccpp.c:112:
    #define USE_TAL

--- grischka

reply via email to

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