From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Stephane Carrez Cc: Michael Snyder , Keith Seitz , gdb-patches@sources.redhat.com Subject: Re: [RFA]: Fix gdb.base/callfwmall.exp for platforms without malloc Date: Mon, 21 May 2001 22:45:00 -0000 Message-id: References: <3B095A01.D85C9E5D@cygnus.com> <3B098795.1CD78B21@worldnet.fr> X-SW-Source: 2001-05/msg00411.html Stephane Carrez 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.