[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.
0001-WIP-Allocate-the-dump-as-a-single-MPS-block.patch
Description: Text Data
0002-WIP-Trace-the-FWD-objects-in-the-dump.patch
Description: Text Data
0003-WIP-Remove-uses-of-pdumper_object_p.patch
Description: Text Data
Re: MPS: Forwording symbols, Gerd Möllmann, 2024/06/16