> On Tue, 2020-09-22 at 20:39 +0200, Jan Hubicka wrote:
> > David,
> > with jit I get the following:
> > /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed:
> > nonrepresentable section on output
> > collect2: error: ld returned 1 exit status
> > make[3]: *** [../../gcc/jit/Make-lang.in:121: libgccjit.so.0.0.1]
> > Error
> >
> > Is there a fix/workaround?
>
> I don't recognize that specific error, but googling suggests it may
> relate to position-independent code.
>
> Are you configuring with --enable-host-shared ? This is needed when
> enabling "jit" in --enable-languages (but slows down the compiler by a
> few percent, which is why "jit" isn't in "all").
Yes --enable-languages=all,jit --enable-host-shared.
I suppose my binutils may show the age, I will check that tomorrow. It
looks like weird error.
>
>
> > Patch I am trying to test/debug is attached, it fixes the selftest
> > issue
> > and the destructor.
>
> Thanks.
>
> Sadly it doesn't fix the jit crashes, which are now in bugzilla (as PR
> jit/97169).
>
> Without the patch, the jit testcases crash at the end of the 1st in-
> process iteration, in the dtor for the the new pass.
>
> With the patch the jit testcases crash inside the 3rd in-process
> iteration, invoking a modref_summaries finalizer at whichever GC-
> collection point happens first, I think, where the modref_summaries *
> seems to be pointing at corrupt data:
>
> (gdb) p *(modref_summaries *)p
> $2 = {<fast_function_summary<modref_summary*, va_gc>> =
> {<function_summary_base<modref_summary>> = {
> _vptr.function_summary_base = 0x200000001,
> m_symtab_insertion_hook = 0x1, m_symtab_removal_hook = 0x100000004,
> m_symtab_duplication_hook = 0x0, m_symtab = 0x644210,
> m_insertion_enabled = 112, m_allocator = {m_allocator = {
> m_name = 0x0, m_id = 0, m_elts_per_block = 1,
> m_returned_free_list = 0x7afafaf01,
> m_virgin_free_list = 0xafafafafafaf0001 <error: Cannot access
> memory at address 0xafafafafafaf0001>,
> m_virgin_elts_remaining = 0, m_elts_allocated =
> 140737080343888, m_elts_free = 0, m_blocks_allocated = 0,
> m_block_list = 0x0, m_elt_size = 6517120, m_size = 13,
> m_initialized = false, m_location = {
> m_filename = 0x0, m_function = 0x0, m_line = 1, m_origin =
> 2947481856, m_ggc = false}}}},
> m_vector = 0x0}, ipa = false}
>
> I think this latter crash may be a pre-existing bug in how the jit
> interacts with gc finalizers. I think the finalizers are accumulating
> from in-process run to run, leading to chaos, but I need to debug it
> some more to be sure. Alternatively, is there a way that a finalizer
> is being registered, and then the object is somehow clobbered without
> the finalizer being unregistered from the vec of finalizers?
It looks like released memory. I saw similar problem with ggc calling
finalizer in "wrong" order. David's modref tree has two layers and
destructor of one was freeing the anohter that is good if you destroy
first the outer type, but not good if you do it in wrong order.
I will try to reproduce it. I also plan to turn the classes to pods and
put them directly into the vectors.
I should not have allowed David to make a template at first place :)
Honza
>
> Dave
>
