From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Elizabeth Chastain <chastain@cygnus.com>
To: chastain@cygnus.com, fnasser@redhat.com
Cc: ac131313@cygnus.com, gdb-patches@sources.redhat.com, keiths@cygnus.com
Subject: Re: [RFA] Assuming malloc exists in callfwmall.exp
Date: Thu, 15 Feb 2001 07:54:00 -0000
Message-id: <200102151553.HAA17146@bosch.cygnus.com>
X-SW-Source: 2001-02/msg00253.html

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