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

Kevin Buettner
2001-02-14T14:37:00Z

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