[RFA] Move alloca(0) to wait_for_inferior() from registers_changed()
Fernando Nasser
fnasser@cygnus.com
Thu Dec 14 08:44:00 GMT 2000
Nick Duffek wrote:
>
> On 14-Dec-2000, Fernando Nasser wrote:
>
> >The event loop (or the interpreter's loop for the ones not using the event loop)
> >and the libgdb calls are the best places for those alloca(0).
>
> There's already an alloca(0) in execute_command(), which is pretty close
> to the bottom of at least the CLI and GDBTK interpreter loops. Changing
> that is beyond the scope of what I'm trying to accomplish with this patch.
>
gdbtk does not always go through execute_command(). Actually, soon it will never
go through it. Neither will other interfaces (script languages) or the MI.
That is why all libgdb calls will have to call alloca(0).
> >> Are you suggesting that alloca(0) be called somewhere other than the
> >> bottom of the wait-for-inferior loop?
>
> >I does not make much sense calling it from there. It only cleans up
> >things that are inner in the stack. At that point, gdb is deep down in its
> >stack so there are high chances that not much will be cleaned up.
>
> The original alloca(0) in registers_changed() is even deeper in the stack,
> so by your argument, it doesn't make much sense either.
>
It doesn't.
> But whoever added it thought it made sense because:
>
> 1. GDB can perform an unbounded number of software watchpoint checks
> between two interpreter loop iterations.
>
Doesn't matter the number. At each time someone calls alloca() the garbage
collection is done. So, only the last iteraction counts.
> 2. Therefore, libiberty's alloca can allocate an unbounded amount of
> heap memory between two interpreter loop iterations.
>
Only if you are talking about a recursion, but I don't think it is the case.
> I don't understand why they chose registers_changed() as a
> garbage-collection point. I do understand why one might choose the loop
> in wait_for_inferior(), though: it iterates once per software watchpoint
> check.
>
A mistake?
> I'm just trying to move that garbage collection to a location that's more
> comprehensible, at least to me.
>
The wfi loop is not much better.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
More information about the Gdb-patches
mailing list