|
From: | Paul Eggert |
Subject: | Re: Preview: portable dumper |
Date: | Mon, 28 Nov 2016 13:14:38 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
* The portable dumper doesn't work with modules. Although this should be OK for Emacs builds since they don't use modules either, what is your thought about this? Will the module API need to change to support dumping?
* I am working on getting Emacs to work with gcc -fcheck-pointer-bounds, and will boost the priority of that task and CC: you when I have something ready. The portable dumper should work in such an environment. I don't see any fundamental problems with this; just giving you a heads-up.
* Functions like do_dump_relocation should use intptr_t or uintptr_t, not ptrdiff_t, to access pointers as integers (whether relocated or not). In theory this would support architectures where intptr_t and ptrdiff_t have different widths. Although Emacs doesn't run on such architectures now, conceivably it could and in the meantime the code might as well be clear about the distinction between pointers and offsets.
* pdumper_load should check that S_ISREG (stat.st_mode) (I suppose this won't be needed if we load from the emacs executable....).
* I suggest using the type bits_word (defined in lisp.h) rather than unsigned. This should work better on 64-bit machines (plus, on weird platforms).
* For pdumper_read a more-portable limit is MAX_RW_COUNT (see sysdep.c) instead of SSIZE_MAX. Maybe that value needs to move into a .h file.
* A nit: pdumper_marked_p relies on implicit conversion to bool, a style I find confusing for bool values. In a bool function it's clearer to write 'return E != 0;' instead of 'return E;' when E might have values other than 0 or 1.
* I haven't thought through all the implications of this and may have more comments later.
[Prev in Thread] | Current Thread | [Next in Thread] |