First of all, thanx to everyone - as was always, your advices were
greate helpful to me.

In fact, among some advices you gave to me, there were something that
I'd also found somewhat independently by trial-and-error or some
investigation, but then another prolem occured, and another, and
another... so I could not post them to the list. Sorry for my laziness
;)

Well, summarizing the current status, I think I've succeeded in
getting symbol table :) this message comes out instead of the past
erraneous messages
----
[ using 149896 bytes of netbsd ELF symbol table ]
----

What I've done was

1) use dbsym before making a raw binary file from an ELF kernel image,
by inserting some commands directly into the machine-dependent
makefile (arch/powerpc/conf/Makefile.powerpc, because sandpoint is a
PowerPC-based platform).

2) Set load address and entry point to 0x90000, which is the start
address of the text section. Of course, for a raw binary file.

3) Add a header to the image file, which contains the load address,
entry point, OS type, etc., that helps the bootloader - in my case
U-Boot - boot the kernel.

To Martin:
>I hope this didn't sound rude - it was just meant to be a hint.
Oh, I understood what you meant. If there are the same posts here and
there, maybe later that will make it hard to keep lists neat. I posted
it on several lists because I didn't know that and I was to eager to
solve the problem.

>Heh, but this was too obvious - could you try the attached patch, re-run
>config and see if your kernel gets symbols now?
Was there 'NEED_SYMTAB' flag already? I didn't know that and I
overrode it by defining it as a flag that is used for my customized
Makefile.

To Jared:
>>3) And I'm also a little bit suspicious about the bootloader. When I
>>printed directly the parameters given to ddb_init(), it says that the
>>start and the end of the symbol table address is 0x7f1ffc8 and 0x0,
>>respectively. Do you think the bootloader is doing what it is assumed
>>to do?

>This may be a big problem. Some ports expect the starting/ending address o=
f
>the symbol table to be passed as parameters when booting the kernel. I hav=
e
>ran into this on another PowerPC port I was working on. I was able to get
>around this by ignoring the passed in parameters and forcing locore.S to
>look for the symbol table in a known location.

I also thought that I might have to try that - pushing parameters into
somewhere and forcing the kernel to use them. But it would be a
tremendous work for me, a NetBSD kernel novice. Happily, I think I
could help the extremely sad situation.
Just my guess - I think that the reason the end of the symbol table
was NULL is that I didn't execute dbsym. I don't know whether the end
of the symbol is calculated by the bootloader and passed to the
kernel, or kernel itself calculates it only using the start address of
the symbol. I think the later would be write.