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
|