On Sun, Jun 16 2024, Gerd Möllmann wrote:

> If we don't dump_fwd, we would have to make sure though not to overwrite
> the existing values for symbols in lispsym, which happens in
> dump_do_dump_relocation
>
>     case RELOC_DUMP_TO_EMACS_PTR_RAW:
>       {
>         uintptr_t value = dump_read_word_from_dump (dump_base, reloc_offset);
>         eassert (dump_reloc_size (reloc) == sizeof (value));
>         value += emacs_basis ();
>         dump_write_word_to_dump (dump_base, reloc_offset, value);
>         break;
>       }
>
> The name dump_write_word_to_dump is misleading. It does a memcpy to
> Emacs' data segment.

Hm, why do you think it writes to the data segment?  Confusing names
aside, it seems to read a value, which presumably is a pointer, adjusts
it to the new basis and then writes it back.

> Maybe one could introduce a new RELOC_xyz type to signify that a
> forwarding symbol is patched and save the fwd value around the memcpy if
> needed.
>
> Or something like that?

Yes, looks like a better reloc kind is needed.

Below is what I currently have.  Tracing those IGC_OBJ_DUMPED_FWD
objects seems problematic, especially while the binding of the symbol is
temporarily swapped out.