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").
> 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?
Dave
