Kyoto Common Lisp (KCL) on 3Bn

Pete Yadlowsky pmy at vivaldi.acc.virginia.edu
Fri Feb 24 07:41:09 AEST 1989





We've been struggling off and on for some time trying to get KCL to run on
AT&T equipment, specifically, 3B2s and '15s. The kernel has always compiled
and executed without problems. But, anything produced with (save)
invariably crashed, with a core dump and 'illegal instruction' message.

So, I decided to take a peek at the 'save'd image, to see what its
sections looked like, particularly the .text section. It didn't look
like the kernel's .text section at all. In fact, it looked more like
data than code. Then I noticed something peculiar about an #ifdef block
in source file unixsave.c. There's an #ifdef ATT3B1 block nested
within an #ifdef ATT block. Within that ATT3B1 block, there's a call
to 'filecpy', which is supposed to copy the kernel's .text section to the
newly-generated image. The implication here is that any AT&T image *not*
targeted for a 3B1 would not get a copy of the .text section. Bingo.
When I moved the call to 'filecpy' outside the #ifdef ATT3B1 block
(still keeping it within the ATT block), everything was fine. We're
now running KCL on our 3B2s and '15s (SysV ver 3.0 for the most part).

Following is a diff-generated ed script for patching the KCL source file,
unixsave.c

-------------------------------- cut ---------------------------------
271a
	filecpy(save, original, header.a_text);
.
270d
----------------------------------------------------------------------


Please, please somebody tell me I'm not the last person in the known
universe to figure this one out. :-) Geez, what a forehead-slapper.



Peter M. Yadlowsky
Academic Computing Center
University of Virginia
pmy at Virginia.EDU



More information about the Comp.sys.att mailing list