Hi -
2010/11/12 Bingfeng Mei <b...@broadcom.com>:
> Hello,
> In our port, I created a new NOTE to preserve pragma info. The
> note is generated as follows in expanding builtins.
>
> rtx note = emit_note(NOTE_INSN_LOOPCOUNT_PRAGMA_BEG);
> rtx vector = gen_rtx_PARALLEL (VOIDmode,
> gen_rtvec(4, op0, op1, op2, op3));
> XCEXP(note, 4, NOTE) = vector;
>
> After the creation:
> (gdb) p vector->u.fld[0].rt_rtvec
> $15 = (rtvec) 0x2a95905028
> (gdb) p *(vector->u.fld[0].rt_rtvec)
> $13 = {num_elem = 4, elem = {0x2a955944a0}}
>
> and I ran into an issue that GC sometimes reclaims the rtvec after
> combine pass and causes segmentation fault.
>
> (gdb) p vector->u.fld[0].rt_rtvec
> $15 = (rtvec) 0x2a95905028
> (gdb) p *(vector->u.fld[0].rt_rtvec)
> $16 = {num_elem = -1515870811, elem = {0xa5a5a5a5a5a5a5a5}}
>
> I really have no clue on how to debug such issue.
> Any suggestion is greatly appreciated.
Too bad I'm not too familiar with RTL data structures, but here's my
take. You have to find where the pointer chain breaks between any GC
root and vector.
In this case vector is collected but note isn't and there is a pointer
from note to vector?
If that's correct then you can confirm that the pointer chain is valid
up to note by setting a breakpoint on ggc_set_mark with condition that
its arg == address of note. If it is triggered during the ggc_collect
in question, OK. The chain is correct up to note.
Then you have to find out why the chain is breaking between note and
vector. You can use the same breakpoint and then step into the
gengtype-generated marker routine and see why it's skipping the field
pointing to vector.
--
Laurynas
