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

Michael Elizabeth Chastain
2001-02-15T07:54:00Z

Hi Fernando,

> The other case to be tested is when there isn't a malloc() available at
> all (that is why the test Keith and you proposed is so nice). But the
> FAILs are wrong. Not having malloc() available is not GDB's fault and
> it may be just a limitation of the target environment.

I think there are four use cases.

Use case #1:

. malloc is available
. the user types: call abs(-10)
. gdb expected response: "$1 = 10"

Use case #2:

. malloc is available
. the user types: call strlen("foo")
. gdb expected response: "$1 = 3"

Use case #3:

. malloc is not available
. the user types: call abs(-10)
. gdb expected response: "$1 = 10"

Use case #4:

. malloc is not available
. the user types: call strlen("foo")
. gdb expected responses: either one of
. "$1 = 3"
. error: evaluation of this expression requires the program to have a function "malloc"

callfuncs.exp tests #1 and #2.
callfuncs.exp can never test #3 or #4.

callfwmall.exp, as written, tests use case #3 (on some platforms).

callfwmall.exp, as written, has an incorrect test for #4. It accepts only
the first response, but gdb can produce either response, and the current
gdb produces the second response.

Keith's patch removes use case #4 from the test coverage.

Michael's patch makes callfwmall.exp verify that it gdb+inferior is in the
regime of #3 and #4. If gdb+inferior is not, then callfwmall.exp returns
UNTESTED. If gdb+inferior is in that regime (inferior has no malloc),
then it tests #3 only. I could make it test #4 properly by adding more RE's.

Fernando's proposal is to remove coverage of #3 and #4.

Kevin's evidence is that Linux native, and probably every glibc platform,
never enters the regime of #3 and #4 anyways.

Michael