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

Reply via email to