From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Elizabeth Chastain <chastain@cygnus.com>
To: ezannoni@cygnus.com, kevinb@cygnus.com
Cc: fnasser@cygnus.com, gdb-patches@sources.redhat.com, keiths@cygnus.com, msnyder@cygnus.com
Subject: Re: [RFA] Assuming malloc exists in callfwmall.exp
Date: Wed, 14 Feb 2001 14:17:00 -0000
Message-id: <200102142217.OAA29927@bosch.cygnus.com>
X-SW-Source: 2001-02/msg00229.html

> There are a number of platforms which pass these tests, but only
> because malloc() is sneaks in because it's required by the dynamic
> linker.  If HPUX passes for a similar reason, this is cheating.  OTOH,
> if the HPUX port uses some other mechanism entirely, it might be a
> good idea for us to adapt this mechanism so that other targets can
> use it too.

I've got hpux scars all over my body which say that hpux 10.20 native
calls malloc() to do this.

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")

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

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

Michael