This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Assuming malloc exists in callfwmall.exp
- To: ezannoni at cygnus dot com, kevinb at cygnus dot com
- Subject: Re: [RFA] Assuming malloc exists in callfwmall.exp
- From: Michael Elizabeth Chastain <chastain at cygnus dot com>
- Date: Wed, 14 Feb 2001 14:17:28 -0800
- Cc: fnasser at cygnus dot com, gdb-patches at sources dot redhat dot com, keiths at cygnus dot com, msnyder at cygnus dot com
> 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