Re: PDUMP questions
On Tue, Jan 25, 2000 at 06:47:48PM -0800, Martin Buchholz wrote:
I suggest the following as being more intuitive, more maintainable,
and also being more correct. You are making the non-portable
assumption that the compiler lays out structs like an array. In fact,
the compiler can order key and value any way it likes. You did call
it the _portable_ dumper.
If you do such a "fix", do it everywhere. There are a lot of places
where I do this assumption. I do others, btw, like the fact that all
pointers are of the same size.
In particular, I'm interessed in how you're going to handle that one:
#define BUFFER_SLOTS_SIZE (offsetof (struct buffer, BUFFER_SLOTS_LAST_NAME) - offsetof
(struct buffer, BUFFER_SLOTS_FIRST_NAME) + sizeof (Lisp_Object))
#define BUFFER_SLOTS_COUNT (BUFFER_SLOTS_SIZE / sizeof (Lisp_Object))
static const struct lrecord_description buffer_slots_description_1[] = {
{ XD_LISP_OBJECT, 0, BUFFER_SLOTS_COUNT },
{ XD_END }
};
Cf buffer.c and bufslots.h. This one (and the other slots thingies)
are the fundamental reason of the assumption in the first place.
I don't understand where the zero'ed ends of strings and
hash_tables
are being stored and/or restored. The size of the data member in a
string or a hash_table refers to the "real" data, but strings have a
NUL byte at the end, and hash table entries have a null sentinel entry
at the end. How are these being restored?
static const struct lrecord_description string_description[] = {
{ XD_BYTECOUNT, offsetof(Lisp_String, size) },
{ XD_OPAQUE_DATA_PTR, offsetof(Lisp_String, data), XD_INDIRECT(0, 1) },
{ XD_LISP_OBJECT, offsetof(Lisp_String, plist), 1 },
{ XD_END }
};
XD_INDIRECT(0, 1) means "the value pointed by the line number zero in
the description" (i.e. size) "plus 1". This is documented in
lrecord.h with all the other description stuff.
const struct lrecord_description hash_table_description[] = {
{ XD_SIZE_T, offsetof(Lisp_Hash_Table, size) },
{ XD_STRUCT_PTR, offsetof(Lisp_Hash_Table, hentries), XD_INDIRECT(0, 1),
&hentry_description },
{ XD_LO_LINK, offsetof(Lisp_Hash_Table, next_weak) },
{ XD_END }
};
Same here. This particular one is one of the reasons why we can find
all-zero lisp objects at dump time. Afair, it's not the only one.
I've been purifying xemacs built with pdump. creating the dump
file
runs cleanly for me now. However, after running the test suite, I get
lots of memory leak warnings I don't understand like this:
The only possibility I can see is finalize_hash_table called with
for_disksave being one when it should be zero.
Is for_disksave ever used nowadays? Should we kill it?
OG.