From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17860 invoked by alias); 10 Sep 2002 04:06:20 -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 17851 invoked from network); 10 Sep 2002 04:06:17 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 10 Sep 2002 04:06:17 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 584223F43; Tue, 10 Sep 2002 00:06:10 -0400 (EDT) Message-ID: <3D7D6FB2.8070205@ges.redhat.com> Date: Mon, 09 Sep 2002 21:06: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: muller@cerbere.u-strasbg.fr Cc: Kevin Buettner , Joel Brobecker , 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> <3.0.6.32.20020910005447.00f25b20@ics.u-strasbg.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00143.txt.bz2 > At 16:10 09/09/02 -0400, Andrew Cagney wrote: > >>> 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? > > > The most basic function to get memory is > GetMem(var p : pointer;size : longint); > It is a procedure (function returning no value) > passing two parameters: > one is a var parameter (analogus to the reference parameter in GNU C > if I understood that correctly) Yes. > the second is the size. > The problem is that I am not even sure that GPC and Free Pascal > use exactly the same declaration and the same method to pass these parameters > to the function. > For Free Pascal, I know that size is pushed first on stack > followed by the pushing of the location of the p variable, > but I don't know exactly for GPC and the feedback from GPC people > is rather rare. Ah, ok. I think this should be considered separatly. Implementing it will involve reworking the function value_allocate_space_in_inferior() so that it is language aware. Have you tried: nm pascalprogram | grep malloc to see if there is any malloc like function in a pascal executable. >>> 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. > > > As said, GPC might need a different mecanism than Free Pascal > (as GPC is based on the GCC compiler, its even possible > that malloc is always linked into the executable...) > > >