Re: [RFA] Assuming malloc exists in callfwmall.exp

[Kevin Buettner <kevinb at cygnus dot com>]

On Feb 14,  2:17pm, Michael Elizabeth Chastain wrote:

> I grepped around for "allocate_space_in_inferior" and it looks like the
> malloc() call is the single hardwired implementation for every platform.
> If that call doesn't work, gdb doesn't get the memory.
> 
> Forget the test script.  What should gdb do if:
> 
>   . I am on a platform with no malloc()
>   . I type: print strlen("foo")

I think the present behavior is acceptable.  It looks for malloc()
anyway to see if it has snuck in via some other means; if it can't
find it, it prints out a message to that effect.

> Should gdb have a target-specific mechanism to try?  For an embedded
> target, it could have a scratch area which it manages itself.

For specific targets, this could no doubt be done, but maintaining it
would be a nightmare.

I don't see any point to adding this kind of complexity to gdb.  If
you're debugging an embedded program where you need to be able to do
``print strlen("foo")'' (or perhaps something more interesting), it's
easy to add a dummy call to malloc() somewhere in your application
code so that you'll be able to do it.

> And if there is no mechanism available, what should gdb print?

Again, I think the present behavior is acceptable.

So...  what should become of callfwmall.exp?  As I recall, this test
is identical to another test (callfuncs.exp) except that it simply
lacks a call to malloc(), right?

If that's the case, I think callfwmall.exp ought to go away.  There's
no point in running the same tests twice.  I just took a quick look
and the diffs between callfwmall.exp / callfuncs.exp and callfwmall.c
/ callfuncs.c was rather larger than I expected.  Someone will have to
examine these differences carefully to make sure that the
callfuncs.exp tests are a superset of the callfwmall.exp tests.

Kevin