Hi again,
I'm stuck on a linker problem I think. Yesterday I investigated why my
entry to the powerpc64 kernel would not work right by setting a few "trap"
commands in the locore0.S asm source. I came to the conclusion that whenever
it tries to jump to a location provided by C source code it would get a 380
exception. After investigating the kernel with objdump and nm I noticed that
the C function .initppc does not have a T (for text) in an nm output. To show
you a comparison between 2 other archs there is a lot of T symbols in the
kernel:
(amd64)
beta# nm /bsd | awk '$2 == "T" {print}'| wc -l
23265
(octeon)
zeta# nm bsd | awk '$2 == "T" {print}'|wc -l
10900
and wait for it..my kernel:
aimee# nm obj/bsd | awk '$2 == "T" {print}'| wc -l
35
This tells me that something is wrong, but I'm not sure what's to blame. I
wrote about it here http://enhancedrisc.de/#20181024
I also tried "fixing" the binutils patch I got from someone by placing this:
aimee# more elf64ppc_obsd.sh
. ${srcdir}/emulparams/elf64ppc.sh
. ${srcdir}/emulparams/elf_obsd.sh
TRAP=0x0000000000000000 # guaranteed always illegal
TEXT_START_ADDR=0x0
...
(that is from /usr/src/gnu/usr.bin/binutils-2.17/ld/emulparams/elf64ppc_obsd.sh)
Really I don't know what I'm doing at this point and have to count on you guys
once again.
What could cause the lack of T(ext) symbols in my kernel? I'm getting a feeling
it's the linker other than that it would be the GNU assembler that I'm using.
Regards,
-peter
