Firewire blues

[Gerald Heinig]

Stephan Uphoff wrote:
> 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?