From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Kevin Buettner Cc: Elena Zannoni , Michael Snyder , Fernando Nasser , Keith Seitz , gdb-patches@sources.redhat.com Subject: Re: [RFA] Assuming malloc exists in callfwmall.exp Date: Wed, 14 Feb 2001 20:13:00 -0000 Message-id: <3A8B5654.9A9DA3A2@cygnus.com> References: <3A8ABA01.C25B0FD2@cygnus.com> <3A8AEFEA.A2E2A61E@cygnus.com> <1010214211043.ZM6538@ocotillo.lan> <14986.63606.73968.332165@kwikemart.cygnus.com> <1010214214059.ZM6607@ocotillo.lan> X-SW-Source: 2001-02/msg00241.html Kevin Buettner wrote: > 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'd describe it as bending the truth rather than cheating. To the best of my knolwedge, the objective of the test is to ensure that GDB can still handle code like: print strlen ("foo") when the target doesn't link in malloc(). Well, to be more precice, the target doesn't explicitly link in malloc(). GDB is forced to grub around in shared library information (or, gasp, the target rom) to obtain a malloc() function. As far as I can tell, the proposed change defeats this test. Yes, there are targets that really don't have malloc() and on those targets the test should probably xfailed. However, on any target with a shared library() I think it should be allowed to run. How many targets currently fail the test? Andrew