From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: Kevin Buettner <kevinb@cygnus.com>, Elena Zannoni <ezannoni@cygnus.com>, Michael Snyder <msnyder@cygnus.com>, Fernando Nasser <fnasser@cygnus.com>, Keith Seitz <keiths@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] Assuming malloc exists in callfwmall.exp
Date: Thu, 15 Feb 2001 10:34:00 -0000
Message-id: <3A8C1FF9.C7539E09@cygnus.com>
References: <Pine.SOL.3.91.1010214082014.13194C-100000@ryobi.cygnus.com> <3A8ABA01.C25B0FD2@cygnus.com> <3A8AEFEA.A2E2A61E@cygnus.com> <1010214211043.ZM6538@ocotillo.lan> <14986.63606.73968.332165@kwikemart.cygnus.com> <1010214214059.ZM6607@ocotillo.lan> <3A8B5654.9A9DA3A2@cygnus.com> <3A8B9D49.4C17E7C3@redhat.com>
X-SW-Source: 2001-02/msg00259.html

> > 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.
> >
> 
> But then it is equivalent to callfuncs.exp, which has already run.

It is subtly different.

callfuncs.exp has an explictly linked malloc and the malloc
run-time-link is forced (using the next over the malloc() call). 
callfwamll doesn't have the explicit malloc and doesn't force final
linkage of malloc().  GDB when it goes to call malloc() indirectly is
forcing that linkage indirectly.

Subtle I know.  I suspect the test as it currently stands is over kill
though.

	Andrew