Re: And now, for an exploding XEmacs
Olivier Galibert <galibert(a)pobox.com> writes:
Now the portable dumper dumps the data, and when restarting loads
the
The next step is having it go through init_console_stream. The
problem is, I don't understand yet what should and shouldn't be done.
The situation is a bit weird, with initialize=1, all dumped variables
available, but with Vterminal_{console,device,frame} not dumped. For
now it breaks on Fset('device, device *) with 'device unbounded.
Any help or hints about how it should work welcome.
Are you sure this isn't simply a problem with the new dumping code?
If I force an ordinary dumped XEmacs into the same code path (by using a
debugger to force it into the Fmake_device branch of
init_console_stream, then everything seems to work OK.
It is simply setting the value of the 'device' symbol with that
variable previous value being a symbol_forward of type
SYMVAL_UNBOUND_MARKER. Are you sure you are dumping variables like
that correctly?
Breakpoint 1, Fset (sym=-1607917740, newval=539754752)
at /scratch/vroonhof/cvs/xemacs-20/src/symbols.c:1610
1610 CHECK_SYMBOL (sym);
(gdb) pobj sym
$19 = (struct Lisp_Symbol *) 0x291f54
$20 = {next = 0x0, name = 0x1a4db0, value = 539232016, function = 539232016,
plist = -1608015868, obarray_flags = 7}
Symbol name: device
(gdb) step
1613 valcontents = XSYMBOL (sym)->value;
(gdb) next
1614 if (NILP (sym) || EQ (sym, Qt) || SYMBOL_VALUE_MAGIC_P (valcontents)
(gdb) next
1628 switch (XSYMBOL_VALUE_MAGIC_TYPE (valcontents))
(gdb) pobj valcontents
$21 = (struct symbol_value_forward *) 0x240710
$22 = {magic = {lcheader = {lheader = {implementation = 0x17cc30}, next = 0x0,
uid = 69, free = 0}, type = SYMVAL_UNBOUND_MARKER},
magicfun = 0x16c80c <lrecord_subr>}
(gdb) step