Re: [Tinycc-devel] Zeroing stack variables CValue
Michael Matz wrote: Thanks. While it doesn't crash for me on x86-64 (with rev aa561d70, i.e. before your memset patch) I do see the wrong vset flowing into init_putv; it's unary(), case TOK_LAND, which does vset(s-type, VT_CONST | VT_SYM, 0); vtop-sym = s; Using vpushsym(s-type, s); instead of the two lines above seems to fix it. Also I renamed the CValue member void *ptr to addr_t ptr_offset and started to use that in some obvious places. This could help avoiding target size confusions. Also: __attribute__ ((noreturn)): gnuism http://repo.or.cz/w/tinycc.git/commitdiff/5879c854fb94f722a7ffdd4e895c9ce418548959 Thanks, --- grischka Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
Hi,
On Fri, 28 Mar 2014, Domingo Alvarez Duarte wrote:
It's simple remove the zeroing CValues and try make clean, make and
make test you'll see that on linux 32 bits and linux 64 bits and you'll
I see no errors on x86_64, I do see these errors on i386:
--
-Test C99 VLA 5 (bounds checking (might be disabled)): PASSED PASSED
PASSED PASSED PASSED PASSED PASSED PASSED
+Test C99 VLA 5 (bounds checking (might be disabled)): FAILED PASSED
FAILED PASSED FAILED PASSED FAILED PASSED
...
-I.. -I../include -b -run tcctest.c test.out3
Runtime error: bad pointer in strlen()
at 0xf74e7f60 __bound_strlen()
../libtcc.c:255: by 0xf74dd261 tcc_strdup() (included from ../tcc.c)
--
Everything else works.
I see these error right before your commit 4bc83ac39 (CValue clearing),
and also with that commit, so for me it's not fixing anything. So, again,
please give us a testcase for the suspected bug you're trying to fix.
And I did not create that code I only found it as is an the bug pointed
Yes, it's pre-existing code, and yes, it _may_ contain a bug somewhere.
If there's a bug then it is accessing the wrong union member. Up to now
the bug hasn't been found.
and found this solution to be a good programming pratice.
Well, not if it merely hides a real bug that therefore then goes unfixed.
Now again can you explain me why zeroing CValues will produce incorrect
results on big-endian platforms, I didn't found this anywhere !
Sure, easy. Given:
union { int i; long long l;} u;
(assume 32bit int and 64bit long long)
Setting u.i=1 on little endian will make reading out u.l come out as 1 as
well. On big endian setting u.i will have set the _high_ 32 bit of u.l,
and hence reading out u.l will come out as 1LL32. You simply can't
transfer values via different-sized members of unions. That's why the
real bug must be found and fixed.
Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
Thanks a lot for your explanation of unions on big endian, with that in
mind I can see now that we have a bigger problem that what I thought at
first, the problem that you explained seem to not been taken in account in
several places in tinycc.
How do you propose to solve this specific problem ?
ST_FUNC void vset(TCCState* tcc_state, CType *type, int r, int v)
{
CValue cval;
memset(cval, 0, sizeof(CValue));
cval.i = v; //, here is the main bug that mix with garbage
vsetc(tcc_state, type, r, cval);
}
/* store a value or an expression directly in global data or in local array */
static void init_putv(TCCState* tcc_state, CType *type, Section *sec,
unsigned long c,
int v, int expr_type)
{
...
case VT_PTR:
if (tcc_state-tccgen_vtop-r VT_SYM) {
greloc(tcc_state, sec, tcc_state-tccgen_vtop-sym, c,
R_DATA_PTR);
}
// on the next line is where we try to get the assigned value to
cvalue.i as cvalue.ull
*(addr_t *)ptr |= (tcc_state-tccgen_vtop-c.ull
bit_mask) bit_pos;
break;
On Sat, Mar 29, 2014 at 5:20 PM, Michael Matz matz@frakked.de wrote:
Hi,
On Fri, 28 Mar 2014, Domingo Alvarez Duarte wrote:
It's simple remove the zeroing CValues and try make clean, make and
make test you'll see that on linux 32 bits and linux 64 bits and you'll
I see no errors on x86_64, I do see these errors on i386:
--
-Test C99 VLA 5 (bounds checking (might be disabled)): PASSED PASSED
PASSED PASSED PASSED PASSED PASSED PASSED
+Test C99 VLA 5 (bounds checking (might be disabled)): FAILED PASSED
FAILED PASSED FAILED PASSED FAILED PASSED
...
-I.. -I../include -b -run tcctest.c test.out3
Runtime error: bad pointer in strlen()
at 0xf74e7f60 __bound_strlen()
../libtcc.c:255: by 0xf74dd261 tcc_strdup() (included from ../tcc.c)
--
Everything else works.
I see these error right before your commit 4bc83ac39 (CValue clearing),
and also with that commit, so for me it's not fixing anything. So, again,
please give us a testcase for the suspected bug you're trying to fix.
And I did not create that code I only found it as is an the bug pointed
Yes, it's pre-existing code, and yes, it _may_ contain a bug somewhere. If
there's a bug then it is accessing the wrong union member. Up to now the
bug hasn't been found.
and found this solution to be a good programming pratice.
Well, not if it merely hides a real bug that therefore then goes unfixed.
Now again can you explain me why zeroing CValues will produce incorrect
results on big-endian platforms, I didn't found this anywhere !
Sure, easy. Given:
union { int i; long long l;} u;
(assume 32bit int and 64bit long long)
Setting u.i=1 on little endian will make reading out u.l come out as 1 as
well. On big endian setting u.i will have set the _high_ 32 bit of u.l,
and hence reading out u.l will come out as 1LL32. You simply can't
transfer values via different-sized members of unions. That's why the real
bug must be found and fixed.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
Hi,
On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:
How do you propose to solve this specific problem ?
ST_FUNC void vset(TCCState* tcc_state, CType *type, int r, int v)
{
CValue cval;
memset(cval, 0, sizeof(CValue));
cval.i = v; //, here is the main bug that mix with garbage
vsetc(tcc_state, type, r, cval);
}
/* store a value or an expression directly in global data or in local array
*/
static void init_putv(TCCState* tcc_state, CType *type, Section *sec, unsig
ned long c,
int v, int expr_type)
{
...
case VT_PTR:
if (tcc_state-tccgen_vtop-r VT_SYM) {
greloc(tcc_state, sec, tcc_state-tccgen_vtop-sym, c, R_DA
TA_PTR);
}
// on the next line is where we try to get the assigned value to cvalue.
i as cvalue.ull
*(addr_t *)ptr |= (tcc_state-tccgen_vtop-c.ull bit_mask)
bit_pos;
break;
There is no specific problem with the above snippets. It's simply two
unrelated functions, one setting cval1.i and another accessing cval2.ull.
There is only a problem when the cval set by vset is used in init_putv in
the VT_PTR case. _That_ would be a problem, but from the above two
snippets it's not clear that this happens. That's why I asked for a
testcase, we need to know _which_ vset call (only setting .i) leaks into
init_putv. E.g. such code would be okay:
vset (type, 0, 42);
vtop-c.ull = 42;
...
init_putv called accessing above vtop.
Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
Ok now I understand your point, here is the minimal program that I was
using to trace it:
int main() {
int x;
static void *label_return = lbl_return;
//printf(label_return = %p\n, label_return);
goto *label_return; // here segfault on linux X86_64 without the
memset on vset
//printf(unreachable\n);
lbl_return:
return 0;
}
On Sat, Mar 29, 2014 at 5:57 PM, Michael Matz matz@frakked.de wrote:
Hi,
On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:
How do you propose to solve this specific problem ?
ST_FUNC void vset(TCCState* tcc_state, CType *type, int r, int v)
{
CValue cval;
memset(cval, 0, sizeof(CValue));
cval.i = v; //, here is the main bug that mix with garbage
vsetc(tcc_state, type, r, cval);
}
/* store a value or an expression directly in global
data or in local array
*/
static void init_putv(TCCState* tcc_state, CType *
type, Section *sec, unsig
ned long c,
int v, int expr_type)
{
...
case VT_PTR:
if (tcc_state-tccgen_vtop-r VT_SYM) {
greloc(tcc_state, sec, tcc_state-tccgen_
vtop-sym, c, R_DA
TA_PTR);
}
// on the next line is where we try to get the
assigned value to cvalue.
i as cvalue.ull
*(addr_t *)ptr |= (tcc_state-tccgen_vtop-c.
ull bit_mask)
bit_pos;
break;
There is no specific problem with the above snippets. It's simply two
unrelated functions, one setting cval1.i and another accessing cval2.ull.
There is only a problem when the cval set by vset is used in init_putv in
the VT_PTR case. _That_ would be a problem, but from the above two
snippets it's not clear that this happens. That's why I asked for a
testcase, we need to know _which_ vset call (only setting .i) leaks into
init_putv. E.g. such code would be okay:
vset (type, 0, 42);
vtop-c.ull = 42;
...
init_putv called accessing above vtop.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
Hi,
On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:
Ok now I understand your point, here is the minimal program that I was using
to trace it:
int main() {
int x;
static void *label_return = lbl_return;
//printf(label_return = %p\n, label_return);
goto *label_return; // here segfault on linux X86_64 without the memset
on vset
//printf(unreachable\n);
lbl_return:
return 0;
}
Thanks. While it doesn't crash for me on x86-64 (with rev aa561d70, i.e.
before your memset patch) I do see the wrong vset flowing into init_putv;
it's unary(), case TOK_LAND, which does
vset(s-type, VT_CONST | VT_SYM, 0);
vtop-sym = s;
next();
break;
Where s-type will be VT_PTR. Indeed vset as it is right now cannot be
used to initialize values of such type. One could extend vset (together
with vpush64 the only routine that accepts an arbitrary type but sets a
specific CValue member) to check for the type and initialize the correct
member. Possibly it's better to try to get rid of as many explicit vset
calls as possible (many of the current ones actually don't need the
immediate value, as it's always zero, and those others that actually pass
some offset or location seem mostly dubious in that they might incorrectly
truncate the value while passing it to vset). Needs some pondering ...
Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
Not at all, now you also could see what I saw there and then decided for
the short path to see it working, probably you don't see the problem
because it's erratic depending on what exists on the stack at the function
call and for some reason on my machine it always have garbage there and
always the same 0xff7f .
That's why I put memset on every call that use CValue on the stack without
explicitly initialize/zero/reset it, as we know use of non initialized
variables can lead to erratic results.
Cheers !
On Sun, Mar 30, 2014 at 12:19 AM, Michael Matz matz@frakked.de wrote:
Hi,
On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:
Ok now I understand your point, here is the minimal program that I was
using
to trace it:
int main() {
int x;
static void *label_return = lbl_return;
//printf(label_return = %p\n, label_return);
goto *label_return; // here segfault on linux X86_64 without the
memset
on vset
//printf(unreachable\n);
lbl_return:
return 0;
}
Thanks. While it doesn't crash for me on x86-64 (with rev aa561d70, i.e.
before your memset patch) I do see the wrong vset flowing into init_putv;
it's unary(), case TOK_LAND, which does
vset(s-type, VT_CONST | VT_SYM, 0);
vtop-sym = s;
next();
break;
Where s-type will be VT_PTR. Indeed vset as it is right now cannot be
used to initialize values of such type. One could extend vset (together
with vpush64 the only routine that accepts an arbitrary type but sets a
specific CValue member) to check for the type and initialize the correct
member. Possibly it's better to try to get rid of as many explicit vset
calls as possible (many of the current ones actually don't need the
immediate value, as it's always zero, and those others that actually pass
some offset or location seem mostly dubious in that they might incorrectly
truncate the value while passing it to vset). Needs some pondering ...
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
I even thought of using a static const initialized CValue and then when
declaring CValues on the stack do this:
CValue cv = ConstInitializedCValue;
But as you've pointed out it doesn't solve the real problem of setting one
member of the union and trying to get another meber of different size.
And even thought about using macros to set/get CValues that will check for
the correct values with an assert and then forbid as a rule to use get/set
CValues directly.
Cheers !
On Sun, Mar 30, 2014 at 12:40 AM, Domingo Alvarez Duarte mingo...@gmail.com
wrote:
Not at all, now you also could see what I saw there and then decided for
the short path to see it working, probably you don't see the problem
because it's erratic depending on what exists on the stack at the function
call and for some reason on my machine it always have garbage there and
always the same 0xff7f .
That's why I put memset on every call that use CValue on the stack without
explicitly initialize/zero/reset it, as we know use of non initialized
variables can lead to erratic results.
Cheers !
On Sun, Mar 30, 2014 at 12:19 AM, Michael Matz matz@frakked.dewrote:
Hi,
On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:
Ok now I understand your point, here is the minimal program that I was
using
to trace it:
int main() {
int x;
static void *label_return = lbl_return;
//printf(label_return = %p\n, label_return);
goto *label_return; // here segfault on linux X86_64 without the
memset
on vset
//printf(unreachable\n);
lbl_return:
return 0;
}
Thanks. While it doesn't crash for me on x86-64 (with rev aa561d70, i.e.
before your memset patch) I do see the wrong vset flowing into init_putv;
it's unary(), case TOK_LAND, which does
vset(s-type, VT_CONST | VT_SYM, 0);
vtop-sym = s;
next();
break;
Where s-type will be VT_PTR. Indeed vset as it is right now cannot be
used to initialize values of such type. One could extend vset (together
with vpush64 the only routine that accepts an arbitrary type but sets a
specific CValue member) to check for the type and initialize the correct
member. Possibly it's better to try to get rid of as many explicit vset
calls as possible (many of the current ones actually don't need the
immediate value, as it's always zero, and those others that actually pass
some offset or location seem mostly dubious in that they might incorrectly
truncate the value while passing it to vset). Needs some pondering ...
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
Hi,
On Wed, 26 Mar 2014, Domingo Alvarez Duarte wrote:
On my commit
It would be easier if you wrote your reasons for doing things in mails,
not only in commit messages, it makes quoting much harder. Anyway, in the
commit message you wrote:
I found the problem it was because CValue stack variables have rubish
as it inital values
and assigning to a member that is smaller than the big union item
and trying to
recover it later as a different member gives bak garbage.
ST_FUNC void vset(TCCState* tcc_state, CType *type, int r, int v)
{
CValue cval;
memset(cval, 0, sizeof(CValue));
cval.i = v; //, here is the main bug that mix with garbage
vsetc(tcc_state, type, r, cval);
}
...
vset only initializes the .i member, that's an invariant. If you want to
read out something else later you have to use other functions, or set
vtop-correctmember after vset yourself ...
static void init_putv(TCCState* tcc_state, CType *type, Section *sec,
unsigned long c,
int v, int expr_type)
{
...
case VT_PTR:
if (tcc_state-tccgen_vtop-r VT_SYM) {
greloc(tcc_state, sec, tcc_state-tccgen_vtop-sym, c,
R_DATA_PTR);
}
// on the next line is where we try to get the assigned value to
cvalue.i as cvalue.ull
*(addr_t *)ptr |= (tcc_state-tccgen_vtop-c.ull bit_mask)
bit_pos;
... like here. You either need to find out which vset() it was that
created the vtop used above and fix that (to initialize -c.ull), or
access only -c.i here and extend it to unsigned long long yourself,
depending on what's the right thing. (That will generally require looking
at the type of vtop and access the right member according to that).
The thing you did (simply zeroing all local CValues) doesn't fix the bug
(it papers over it, and on big-endian platforms doesn't even do that), and
generates needless code. Please revert and fix it correctly. Or post a
testcase here that breaks without that zeroing, in which case I'll promise
to take a look.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
It's simple remove the zeroing CValues and try make clean, make and
make test you'll see that on linux 32 bits and linux 64 bits and you'll
see that it doesn't pass the tests, on linux 32 bits try make test -i and
you'll see garbage been generated.
And I did not create that code I only found it as is an the bug pointed and
found this solution to be a good programming pratice.
Now again can you explain me why zeroing CValues will produce incorrect
results on big-endian platforms, I didn't found this anywhere !
Thanks in advance for your time, attention and great work !
On Fri, Mar 28, 2014 at 7:58 PM, Michael Matz matz@frakked.de wrote:
Hi,
On Wed, 26 Mar 2014, Domingo Alvarez Duarte wrote:
On my commit
It would be easier if you wrote your reasons for doing things in mails,
not only in commit messages, it makes quoting much harder. Anyway, in the
commit message you wrote:
I found the problem it was because CValue stack variables have rubish
as it inital values
and assigning to a member that is smaller than the big union item and
trying to
recover it later as a different member gives bak garbage.
ST_FUNC void vset(TCCState* tcc_state, CType *type, int r, int v)
{
CValue cval;
memset(cval, 0, sizeof(CValue));
cval.i = v; //, here is the main bug that mix with
garbage
vsetc(tcc_state, type, r, cval);
}
...
vset only initializes the .i member, that's an invariant. If you want to
read out something else later you have to use other functions, or set
vtop-correctmember after vset yourself ...
static void init_putv(TCCState* tcc_state, CType *type, Section *sec,
unsigned long c,
int v, int expr_type)
{
...
case VT_PTR:
if (tcc_state-tccgen_vtop-r VT_SYM) {
greloc(tcc_state, sec, tcc_state-tccgen_vtop-sym,
c, R_DATA_PTR);
}
// on the next line is where we try to get the assigned value to
cvalue.i as cvalue.ull
*(addr_t *)ptr |= (tcc_state-tccgen_vtop-c.ull
bit_mask) bit_pos;
... like here. You either need to find out which vset() it was that
created the vtop used above and fix that (to initialize -c.ull), or access
only -c.i here and extend it to unsigned long long yourself, depending on
what's the right thing. (That will generally require looking at the type
of vtop and access the right member according to that).
The thing you did (simply zeroing all local CValues) doesn't fix the bug
(it papers over it, and on big-endian platforms doesn't even do that), and
generates needless code. Please revert and fix it correctly. Or post a
testcase here that breaks without that zeroing, in which case I'll promise
to take a look.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
Not only vtop, tok, tokc, error message was one of the bigs as well, with
this first attempt I've tried to keep the name of variable and line numbers
in a way that is more or less easy to compare before and after code
refactoring.
After doing it I realize that a better design should be done, like trapping
error and warning messages to user defined function, prefix global
functions, structures to avoid name clashes with third party
libraries/code, a better connection between code generation specific for
each platform, ...
As I said this was a first attempt and is somehow working, now the
community have one start point to decide and compare the pros cons of a
such code change.
Cheers !
On Thu, Mar 27, 2014 at 3:44 PM, Thomas Preudhomme robo...@celest.frwrote:
Le 2014-03-27 07:23, Domingo Alvarez Duarte a écrit :
Again my mistake, it does pass vla tests on linux 32 bits, the bounds
check tests fail with garbage being passed to strlen.
On arm it also works.
Hi Domingo,
I took a look at your patch and although I agree there is some problems, I
find the approach a bit intrusive. For instance, in the vset case instead
of zeroing the cval it would be better to fix the places that read the .ull
field when it was initialized with vset. Normally a code would check the
type before reading .ull and any caller of vset should do the right thing
if the type needs to use the .ull field.
There is also get_tok_str that would require fixing as (as was pointed out
by mobi phil) many caller of that function gives NULL as second parameter.
It would be easily fixed with:
CValue cval;
if (!cv) {
cval.ull = 0;
cv = cval;
}
The only place that should be fixed is when a variable is read but not
initialized. When the wrong field of an union is read, either another field
should be read or another field should have been set. Also, if tcc was used
some day to compile on a big endian system the zeroing would also lead to
garbage being read (only on little endian does it have no impact).
By the way, I'll try my best to take a look at your patch after the
release. We'll then figure out how to best merge it. Maybe it's better in
one big commit, I need to look at it first. I guess vtop, tok and tok are
the biggest reason to have TCCState sneak in all function prototype, is
that it?
Best regards,
Thomas
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
When I found this problem and looked at how CValue is defined I saw a
potential for later new field been added changed and then I decided to
always start with generic well known state (everything zeroed) otherwise
bugs like this one that can manifest randomly depending on the garbage at
the execution time, also any usage of unitialized structs/vars can
potentially be the source of hard to find bugs.
So I do not see your suggestion as a good replacement for zeroing then
before use, and I'm not aware about the difference it will make on
little/big endian machines the fact that structures are zeroed. Are you
sure about that ?
Cheers !
On Thu, Mar 27, 2014 at 3:44 PM, Thomas Preudhomme robo...@celest.frwrote:
Le 2014-03-27 07:23, Domingo Alvarez Duarte a écrit :
Again my mistake, it does pass vla tests on linux 32 bits, the bounds
check tests fail with garbage being passed to strlen.
On arm it also works.
Hi Domingo,
I took a look at your patch and although I agree there is some problems, I
find the approach a bit intrusive. For instance, in the vset case instead
of zeroing the cval it would be better to fix the places that read the .ull
field when it was initialized with vset. Normally a code would check the
type before reading .ull and any caller of vset should do the right thing
if the type needs to use the .ull field.
There is also get_tok_str that would require fixing as (as was pointed out
by mobi phil) many caller of that function gives NULL as second parameter.
It would be easily fixed with:
CValue cval;
if (!cv) {
cval.ull = 0;
cv = cval;
}
The only place that should be fixed is when a variable is read but not
initialized. When the wrong field of an union is read, either another field
should be read or another field should have been set. Also, if tcc was used
some day to compile on a big endian system the zeroing would also lead to
garbage being read (only on little endian does it have no impact).
By the way, I'll try my best to take a look at your patch after the
release. We'll then figure out how to best merge it. Maybe it's better in
one big commit, I need to look at it first. I guess vtop, tok and tok are
the biggest reason to have TCCState sneak in all function prototype, is
that it?
Best regards,
Thomas
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Zeroing stack variables CValue
Hello ! On my commit I posted that it solves the vla tests on linux 32bits, it was a mistake from my part, the vla test still fail with garbage. Probably what the comments say is happening: /* Overwrite a VLA. This will overwrite the return address if SP is incorrect */ Cheers ! ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Zeroing stack variables CValue
Again my mistake, it does pass vla tests on linux 32 bits, the bounds check tests fail with garbage being passed to strlen. On arm it also works. On Wed, Mar 26, 2014 at 8:30 PM, Domingo Alvarez Duarte mingo...@gmail.comwrote: Hello ! On my commit I posted that it solves the vla tests on linux 32bits, it was a mistake from my part, the vla test still fail with garbage. Probably what the comments say is happening: /* Overwrite a VLA. This will overwrite the return address if SP is incorrect */ Cheers ! ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
