From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10500 invoked by alias); 6 Sep 2002 13:03:52 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10491 invoked from network); 6 Sep 2002 13:03:51 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 6 Sep 2002 13:03:51 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17nJi2-0004Yn-00; Fri, 06 Sep 2002 09:03:43 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17nIls-0001oM-00; Fri, 06 Sep 2002 09:03:36 -0400 Date: Fri, 06 Sep 2002 06:03:00 -0000 From: Daniel Jacobowitz To: Pierre Muller Cc: Joel Brobecker , gdb-patches@sources.redhat.com Subject: Re: New target method returning the name of the malloc function? Message-ID: <20020906130336.GA6908@nevyn.them.org> Mail-Followup-To: Pierre Muller , Joel Brobecker , gdb-patches@sources.redhat.com References: <20020906002319.GW1169@gnat.com> <4.2.0.58.20020906091206.021019b8@ics.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4.2.0.58.20020906091206.021019b8@ics.u-strasbg.fr> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00085.txt.bz2 On Fri, Sep 06, 2002 at 09:17:11AM +0200, Pierre Muller wrote: > At 02:23 06/09/2002 , Joel Brobecker a écrit: > >Hello, > > > >The name of the function used to allocate some memory in the inferior is > >currently hard-coded to "malloc" in valops.c: > > > > struct value * > > value_allocate_space_in_inferior (int len) > > { > > struct value *blocklen; > > struct value *val = find_function_in_inferior ("malloc"); > > ^^^^^^ > > > >Unfortunately, on interix, the malloc function is not always there. > >Quoting Donn Terry: > ><< > >malloc() won't necessarily be present; the way our namespace pollution > >prevention stuff works, if the user application doesn't call an entry > >point at all, it just won't be there. However, _malloc is always > >present (at least in any real program) because it's called from within > >the library. > > >> > > > >May I suggest a new architecture method called for instance > >NAME_OF_MALLOC or MALLOC_FUNCTION_NAME? The default would be to return > >"malloc", but we could then change it to "_malloc" for the interix > >target. > That would be great ! > Because Pascal also does not define malloc... > By the way, how is this allocated memory freed after the call to the > inferior function ? > Does it use another C function for this, or how is it done. > if it also need to find free then we should > also add a NAME_OF_FREE. It doesn't release the memory. There's some comments in the code about why not - we have no way of knowing whether the called function stored a pointer in a global variable somewhere. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer