New target method returning the name of the malloc function?
Andrew Cagney
ac131313@ges.redhat.com
Mon Sep 9 21:06:00 GMT 2002
> 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...)
>
>
>
More information about the Gdb-patches
mailing list