Re: [RFA]: Fix gdb.base/callfwmall.exp for platforms without malloc

[Jim Blandy <jimb@zwingli.cygnus.com>]

Stephane Carrez <Stephane.Carrez@worldnet.fr> writes:
> Hum... if I understand, the only good fix is to fix GDB so that it
> no longer calls 'malloc'.  I would be very happy to see that fix in
> GDB.  You cannot rely on a possible 'malloc'.  I have two examples
> in mind here: 68HC11 programs and... ChorusOS kernel.
> 
> Do you have any patch or are you working on any fix so that GDB does
> not call 'malloc' any more?
> 
> For example, by allocating the string on the stack, as it does for
> the arguments.  Ok, it's more complex; you'll need a two-pass
> argument processing, one for string allocation, and one to really
> push the arguments.

That test file is a confused piece of code, and everyone who reads it
seems to get confused, too.  GDB can call any function just fine
without ever using malloc, and GDB may need to use malloc even when
the user has never entered a function call to evaluate.

GDB calls malloc in the inferior to evaluate even simple expressions
like this:

    (gdb) print str = "hi there"

(where `str' is a char *).  Allocating strings on the stack isn't an
acceptable implementation for uses like this: the inferior's code
might not be prepared to have its frame size changed, and you have no
way to know whether the string's lifetime is shorter than that of the
frame anyway.

Basically, in order to evaluate string literals, GDB must have some
reliable way to find storage in the inferior which will never be used
for anything else.  Calling malloc is one way to do this.  If malloc
isn't available, the target should provide an alternative, or GDB
should say, "Sorry, can't evaluate string literals on this target."

I think callfwmall.{exp,c} should simply be deleted.  They do a bad
job of testing functionality that GDB cannot promise to provide.  HP
created the test file because their run-time support is guaranteed to
include malloc; at the very least, callfwmall.{exp,c} should be moved
into gdb.hp.