Re: New target method returning the name of the malloc function?

[Andrew Cagney <ac131313@ges.redhat.com>]

> 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...)
> 
> 
>