This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]