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 ....
Stephan
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
