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
