From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16458 invoked by alias); 9 Sep 2002 20:10:25 -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 16451 invoked from network); 9 Sep 2002 20:10:24 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 9 Sep 2002 20:10:24 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3AE023F43; Mon, 9 Sep 2002 16:10:24 -0400 (EDT) Message-ID: <3D7D002F.9040308@ges.redhat.com> Date: Mon, 09 Sep 2002 13:10:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner , Joel Brobecker Cc: Pierre Muller , gdb-patches@sources.redhat.com Subject: Re: New target method returning the name of the malloc function? References: <4.2.0.58.20020906091206.021019b8@ics.u-strasbg.fr> <1020906161422.ZM26295@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00130.txt.bz2 > On Sep 6, 9:17am, Pierre Muller wrote: > > >> >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... How does pascal allocate [raw] memory? > This would suggest that something other than a target dependent method > is needed. (It seems to me that it's both target and language dependent.) (Ah, the old ``which target'' problem --- target architecture, target os, target abi, target inferior, .... :-) Yes. I think these are functions of the ABI and not the inferior. Any interix inferior (local, remote) needs this override. Hence they live in the architecture vector and not the target vector. I'm not sure what to do about the language side of this though. It could always be parameterized with the current frame's language -> not sure if that is sufficient though. enjoy, Andrew