This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Remote protocol tune up...
- To: Todd Whitesel <toddpw at wrs dot com>, Stan Shebs <shebs at cygnus dot com>
- Subject: Re: Remote protocol tune up...
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 15 Oct 1999 12:00:33 +1000
- CC: GDB Developers <gdb at sourceware dot cygnus dot com>
- Organization: Cygnus Solutions
- References: <199910142159.OAA09943@alabama.wrs.com>
Todd Whitesel wrote:
>
> > regard to ``(256*1024)'', foke law has it that some hosts do not handle
> > alloca()s larger than 64k. If you're going to allow large transfers
> > then it will need to avoid alloca().''
>
> Alloca really should not be used for stuff that is going to get arbitrarily
> large. Many people have their stacksize limit at 8 megs or so, and some of
> the NetBSD ports (arm32, pc532, vax) have their default hard limit set at
> 8 megs also. (Not sure why they felt it necessary to do this; it may have
> been an attempt to avoid something nasty in the VM hardware.)
Some history is probably in order:
The original remote.c code had compile time PBUFSIZE constant and that
was used to allocate scratch buffers on the stack vis:
char buf[PBUFSIZE];
Since PBUFSIZE is small (for all known cases :-) the operation was
reasonably safe.
Then multi-arch arrived and the assumption that PBUFSIZE (based on
REGISTER_BYTES) was constant went out the window. Fortunatly it was
still small so, the pragmatic decision was to convert the array's into
alloca() (1):
char *buf = alloca (PBUFSIZE);
(Looking through remote.c I notice that several array style declarations
have crept back in - GCC accepts them ...).
The current proposal (and thanks to IA64 a reflection of the new
reality) is to remove the assumption that PBUFSIZE is small. Doing this
involves xmalloc() and (*!&^#(*@!#) cleanups and incremental changes
(JimB you are not allowed to talk about GUILE :-)
As for alloca(). It stinks. Unfortunatly it is a reliable mechanism for
allocating small arbitrary sized data that has a well defined lifetime.
GDB typically uses a cleanup when creating a data structure that should
out live the current function;s lifetime but, if an error occures,
should be re-claimed. Alloca gets used when the programmer knew that
the data's lifetime was determined by that of the bounding function.
Before this goes any further I think I'll just mention that it was a
Nazi that made me do it :-)
( http://www.wins.uva.nl/~mes/jarg320.old/g/GodwinsLaw.html )
enjoy,
Andrew
(1) If you look through the code you'll notice that multi-arch
introduced several other alloca()s but again where it was known that the
buffer involved while dynamic was small.