This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: gdb stack in stub
- To: "davidwilliams at ozemail dot com dot au" <davidwilliams at ozemail dot com dot au>
- Subject: Re: gdb stack in stub
- From: jtc at redback dot com (J.T. Conklin)
- Date: 02 Dec 1999 11:12:01 -0800
- Cc: "'gdb mail list'" <gdb at sourceware dot cygnus dot com>
- References: <01BF3D52.CD93EEA0.davidwilliams@ozemail.com.au>
- Reply-To: jtc at redback dot com
>>>>> "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