From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Michael Elizabeth Chastain , 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:37:00 -0000 Message-id: <1010214223731.ZM6735@ocotillo.lan> References: <200102142217.OAA29927@bosch.cygnus.com> X-SW-Source: 2001-02/msg00233.html On Feb 14, 2:17pm, Michael Elizabeth Chastain wrote: > 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") I think the present behavior is acceptable. It looks for malloc() anyway to see if it has snuck in via some other means; if it can't find it, it prints out a message to that effect. > Should gdb have a target-specific mechanism to try? For an embedded > target, it could have a scratch area which it manages itself. For specific targets, this could no doubt be done, but maintaining it would be a nightmare. I don't see any point to adding this kind of complexity to gdb. If you're debugging an embedded program where you need to be able to do ``print strlen("foo")'' (or perhaps something more interesting), it's easy to add a dummy call to malloc() somewhere in your application code so that you'll be able to do it. > And if there is no mechanism available, what should gdb print? Again, I think the present behavior is acceptable. So... what should become of callfwmall.exp? As I recall, this test is identical to another test (callfuncs.exp) except that it simply lacks a call to malloc(), right? If that's the case, I think callfwmall.exp ought to go away. There's no point in running the same tests twice. I just took a quick look and the diffs between callfwmall.exp / callfuncs.exp and callfwmall.c / callfuncs.c was rather larger than I expected. Someone will have to examine these differences carefully to make sure that the callfuncs.exp tests are a superset of the callfwmall.exp tests. Kevin