unlike FreeBSD, NetBSD requires the kernel be compiled
with USE_KGDB to use remote gdb. so, I could end up
looking at a machine that was not pre-compiled for
that and have to extract max info from that scenario.
how stable is the #ifdef KGDB code wrt DDB btw?
thanks
-kamal

--- Andrew Cagney <cagney@mac.com> wrote:
> > Kamal Prasad <kamalpr@yahoo.com> writes:
> > 
> > 
> >> I am using ddb in macppc-netbsd to look at
> >> panics,deadlocks etc.. I cannot/may not be able
> to
> >> -access this via gdb.
> >> assuming I have a stack from trace /t ... in
> ddb:-
> > 
> > 
> >> 1. How do I evaluate parameters to a function
> call
> >> inside a stack frame?
> > 
> > 
> > This is hard. Like most other RISC architectures,
> powerpc uses
> > registers to pass the first several (six for ppc)
> arguments. For
> > functions other than the most recent, the register
> values may be
> > stored on the stack, but only if their values were
> live at the moment
> > of the function call. You need something that can
> parse the full
> > debugging information built into a -g kernel to
> figure this out, and
> > even then you are likely to not have all the
> values saved any more.
> 
> Why not teach GDB to (gulp) talk to ddb?  See
> gdb/remote-rom.c for the 
> general theory.
> 
> Andrew
> 
> 
> >> 2. the local variables inside a stack frame
> > 
> > 
> > Also requires parsing debug information beyond the
> basic symbol
> > table. I usually find it easist to have another
> computer with a
> > debugger or objdump, disassemble the functions in
> question, and
> > interpolate the storage locations of variables
> from the action of the
> > machine code.
> > 
> >         - Nathan
> 
> 


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com