This is the mail archive of the gdb@sources.redhat.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: 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

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