Re: malloc in inferior

["John S. Yates, Jr." <jyates@netezza.com>]

From: "Paul Koning" <pkoning@equallogic.com>
Sent: Thursday, May 29, 2003 1:24 PM


> Are you talking about remote target debug?  I don't know of anything
> that uses malloc in the remote target protocol implementations I've
> seen.   That ignores function call (which I've never used, it doesn't
> seem to work in any implementation I've ever worked on).

Paul,

I work in an environment with a number of senior engineers
each with decades of experience doing OS and embedded systems
work.  An informal poll indicates that none of them has ever
seen gdb's function call capability work reliably.

On reflection I think that this is because RSP hides from the
stub the fact that a continue is being performed on behalf of
a gdb call versus an actual continue of the stopped application.
These users' typical expectations are that a gdb call should be
utterly uninvaisive (principle of least astonishment).  This is
why the gdb stub executes in exception context with interrupts
disabled.  Having a call to a debug dump utility restore full
thread context including reenabling interrupts, triggering who
knows what churning of carefully inspected state, makes gdb's
call capability just too risky for these developers.

This only makes invisible gdb calls even more pernicious.  Some
of the developers I talked to were aware of the malloc behavior
thought none were able to articulate precisely the conditions
under which it occurs.  They simply chalk it up to gdb flakiness
and restrict themselves to some collection of debugging actions
that experience has shown to be reliable.

/john