This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gdb stack in stub


>>>>> "David" == David Williams <davidwilliams@ozemail.com.au> writes:
David> Hi all, I noticed that a 10K local stack is allocated in the
David> m68k-stub.c for it own use when communcating with gdb. This
David> seems excessive. I would like to leave the stub code in my
David> final application so that I can debug in the field (via a
David> special option). However it would be better if the stub
David> consumed the least amount of system resources as possible.
David>
David> Is there any problem with using my applications stack (if
David> enough room is allocated for GDB usage in addition to normal
David> usage)? My application always runs in supervisor mode.

Yes.  The problem occurs when you attempt an inferior function call.
GDB starts constructing a dummy stack frame at the saved stack ptr,
which overwrites the stack memory being used by the stub itself.

David> What is likely max stack usage of GDB?

The stub code itself doesn't use much stack, but the user-supplied
putDebugChar() and getDebugChar() functions might.  I typically do
i/o with loops polling UART registers, which isn't stack intensive.

I've measured stack use of our PowerPC based stub at less than 100
bytes.  A CPU like the m68k where function arguments and return
addresses are passed on the stack may take a bit more.

You might want to allocate a stack you know will be big enough,
initialize it with a given pattern, use the stub for a while and then,
examine the stack to determine where the pattern has been overwritten.
That should give you a good idea how to size the stack in your system.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]