This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: alloca is bad?
Christopher Faylor wrote:
>
> On Fri, Nov 10, 2000 at 11:42:48AM -0500, Fernando Nasser wrote:
> >Chris Faylor wrote:
> >>
> >> On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
> >> >> Date: Thu, 9 Nov 2000 21:20:32 -0500
> >> >> From: Christopher Faylor <cgf@redhat.com>
> >> >>
> >> >> I was surprised by this assertion and so I thought I'd ask for a
> >> >> consensus here. Should the use of alloca be deprecated in gdb?
> >> >
> >> >In my experience, there's nothing wrong with alloca as long as it is
> >> >used for allocating small buffers. The only consideration is that not
> >> >every platform supports alloca.
> >>
> >> But, since alloca is already entrenched in gdb and available in liberty
> >> I don't think this is an issue, is it?
> >>
> >
> >Warning: if the "liberty" alloca() is used a "alloca(0)" must be added to
> >our interpreter's command loops or the garbage collection becomes somewhat
> >random (it will only happen when you call alloca() for allocating some
> >other stuff and will only clean what was allocated by code that executed on frames
> >below the current stack position.
> >
> >I think we have this bug when alloca() gets used right now.
> >
> >(Nothing difficult, we just need to remember to do it)
>
> % fgrep 'alloca (0)' *.c
> gnu-regex.c: alloca (0);
> gnu-regex.c: alloca (0);
> gnu-regex.c: alloca (0);
> regcache.c: alloca (0);
> top.c: alloca (0);
That takes care of the CLI commands. (MI and Insight are probably broken)
Any other interpreter that uses the libgdb exported functions instead
of the CLI execute_command will have to do the same. How can we control
that this is done if a script, for instance, calls random libgdb functions?
Maybe we will have to add a call to alloca(0) to every libgdb call.
(Or not used the darn thing!)
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9