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
