emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MPS: Forwording symbols


From: Helmut Eller
Subject: Re: MPS: Forwording symbols
Date: Sun, 16 Jun 2024 21:27:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

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.


Attachment: 0001-WIP-Allocate-the-dump-as-a-single-MPS-block.patch
Description: Text Data

Attachment: 0002-WIP-Trace-the-FWD-objects-in-the-dump.patch
Description: Text Data

Attachment: 0003-WIP-Remove-uses-of-pdumper_object_p.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]