This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]