Commented out the kl_signal problem references, and applied the change to
alloc.c. Clapped a little when it actually linked. I had high hopes, but it
looks like I still have the same problem as before I left on vacation (actually
slightly worse, before I got to get_page index=4):
(gdb) run
Starting program: /usr/src/linux/cmd/lcrash/./lcrash
map = /boot/System.map, vmdump = /dev/mem, outfile = stdout
Please wait...................
Program received signal SIGSEGV, Segmentation fault.
0x1200278d0 in enqueue (list=0x12024d898, new=0x20251000) at alloc.c:58
58 alloc.c: No such file or directory.
(gdb) where full
#0 0x1200278d0 in enqueue (list=0x12024d898, new=0x20251000) at alloc.c:58
head = (element_t *) 0x0
#1 0x120028930 in get_page (index=3) at alloc.c:441
i = 0
b = (block_t *) 0x20251000
page = (void *) 0x120028e04
p = (page_t *) 0x12024d880
#2 0x1200292ac in alloc_block (size=80, flag=2, ra=0x0) at alloc.c:698
i = 3
j = 0
blk = (void *) 0x11ffffaf0
p = (page_t *) 0x120034e44
b = (block_t *) 0x0
#3 0x120003c48 in kl_block_alloc_func (size=80, flag=2, ra=0x0) at util.c:303
b = (void *) 0x120038494
#4 0x1200384ec in _kl_alloc_block (size=80, flags=2, ra=0x0) at kl_alloc.c:22
blk = (void *) 0x1200040b0
#5 0x1200040d0 in register_cmds (cmds=0x120153350) at command.c:20
i = 0
ret = 1
max_depth = 539181536
cmd_rec = (cmd_rec_t *) 0x100000000
#6 0x120002d90 in main (argc=1, argv=0x11ffffc18) at main.c:205
i = 1
c = 512
errflg = 0
(gdb)
On 31-May-2000 Tom Morano wrote:
> Brian Hall wrote:
>>
>> Local consensus is to stick with 2.2 for now. I think I have done most of
>> the
>> changes necessary in my 2.2 tree to work with 64 bit already, since I can
>> successfully (though possibly not correctly, still unverified) create a
>> dump.
>> My problem has been getting lcrash to work.
>>
>> OK, I've gotten the 2.2 and 2.3 trees from SourceForge. I've updated my tree
>> to
>> match as closely as possible, and brought the relevant arch changes over to
>> the Alpha tree also. However, I'm having a new problem with the build in
>> libklib. The new signal handler stuff, kl_signal.c, can't find a definition
>> for
>> "greg_t", and neither can I. Doesn't seem to be defined in the 2.2 or 2.3
>> cvs
>> trees.
>>
>> [root@localhost libklib]# mm
>> /bin/rm -f include/asm
>> (cd include ; /bin/ln -s asm-alpha asm; cd ..)
>> cc -gstabs -D__KERNEL__ -I/usr/src/linux/include -I. -Iinclude -c -o
>> kl_signal.o kl_signal.c
>> kl_signal.c: In function `klib_sig_handler':
>> kl_signal.c:70: `greg_t' undeclared (first use in this function)
>> kl_signal.c:70: (Each undeclared identifier is reported only once
>> kl_signal.c:70: for each function it appears in.)
>> kl_signal.c:70: `gregs' undeclared (first use in this function)
>> kl_signal.c:70: structure has no member named `gregs'
>> kl_signal.c:71: parse error before `esi'
>> kl_signal.c:73: `esi' undeclared (first use in this function)
>> kl_signal.c:73: `ESI' undeclared (first use in this function)
>> kl_signal.c:74: `esp' undeclared (first use in this function)
>> kl_signal.c:74: `ESP' undeclared (first use in this function)
>> kl_signal.c:76: `badaddr' undeclared (first use in this function)
>> kl_signal.c:76: parse error before `sip'
>> make: *** [kl_signal.o] Error 1
>>
>
> Brian,
>
> I had this same problem when working on ia64 stuff in the 2.3 tree. It's
> because
> the signal handler has i386 specific stuff in it. I got around this by moving
> the kl_signal.c module into the arch specific portion of the tree. I haven't
> rearranged the 2.2 tree to be 64 bit friendly yet (or non i386 architecture
> friendly for that matter), since I've been doing all my recent work in
> the 2.3 tree. I guess I'm going to have to do this soon. In the mean time,
> I would just comment out the portions of the code which are breaking your
> build (the references to esi, esp, etc.). Also, I found a problem with the
> alloc.c module that was really a pain to track down (you might have been
> bitten by this one already). The minimum size bucket is hard coded at 8
> bytes. Since the buckets get strung on a doubly linked list, the prev
> pointer overshoots the end of the bucket (2 64-bit points are > 8 bytes).
> Just make the smallest bucket in the bucket_size[] array be 16 bytes. I'll
> let you know when I get my 2.3 arch related changes back ported to the 2.2
> tree so you can stay in synch with what I have. Sorry, but it's sometimes
> a pain keeping two moving targets lined up with each other. :]
>
> Tom
--
|