On Wed, 2005-02-16 at 07:19, Gerald Heinig wrote:
Gerald Heinig wrote:
Ulrich Spoerlein wrote:
[stuff snipped]
Other than that, remote gdb is working. Poking inside the fwmem itself is however not working, I get this after setting eui64_{hi,lo} % kgdb -c /dev/fwmem0.0 kernel.debug ... 0x00000000 in ?? ()
I got this as well. In my case I assumed it's due to the fact that I wasn't using the same kernel file for the debugger as was running on the target machine. I didn't investigate further because I can't spend any more time on this problem at the moment.
I'd be interested to know whether that is the problem though.
I just tried it (had to compile new kernel anyway). It's not due to a symbol mismatch.
ENOCLUE :(
With this way of debugging you can only read the memory of the target machine and NOT the state of the CPU. This means that you can not get a current stack backtrace or the current pc. You can however go through the list of processes, find the currently running thread, look at data structures, get backtraces of non-running threads ....
That makes sense.
Are there any macros with which one can get the thread table address, the address of the currently running thread etc etc?
I noticed in Greg's paper he makes several .gdbinit files. Does any of that work/exist under 5.3?
_______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
