Re: MPS: native comp

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>>> Current_thread is staticpro'd, so in Emacs we'll fix that if a
>>> thread_sate moves in memory. But what does/could GCC assume about this,
>>> or maybe comp?
>>
>> I think we'll have to update "struct comp_thread_state * *
>> current_thread_reloc" as well if 'current_thread' moves.
>
> Thanks.
>
> BTW, is there a way to let libgccjit keep to .o file together with the
> .c file?
>
> I'm asking because the .elns don't have debug info on macOS (for a
> long-winded reason that made macOS handle DWARF differently from the
> rest). If I had a .o with debug info, I could maybe generate .dSYM
> files.

Good news! I think I know what's going on, 100% - epsilon.

The error occurs in an Emacs that has a pdump loaded. (I submitted a bug
concerning the build process. The workaround for this made it much
easier for me to recognize what's going on.)

The loaded dump contains, among other things, native compilation unit
objects. These objects contain pointers into the loaded .eln for things
that we need to trace. For CUs that are in MPS memory, this is done by
fix_comp_unit and all it good. For CUs in the dump this is not done,
simply because they are not in MPS memory but in the hot segment of the
loaded dump. Result is that references in these .eln are not fixed, and
so on.

In the end, it's always the same problem with the dump. The dump is not
in MPS, MPS knows only traces as an ambig root.

I guess we should do something about this. Maybe we could try Helmut's
idea of copying the objects to MPS.

Meanwhile, I'll try to come up with a workaround.