New target method returning the name of the malloc function?

New target method returning the name of the malloc function?

[Joel Brobecker]

Hello,

The name of the function used to allocate some memory in the inferior is
currently hard-coded to "malloc" in valops.c:

     struct value *
     value_allocate_space_in_inferior (int len)
     {
       struct value *blocklen;
       struct value *val = find_function_in_inferior ("malloc");
                                                       ^^^^^^

Unfortunately, on interix, the malloc function is not always there.
Quoting Donn Terry:
<<
malloc() won't necessarily be present; the way our namespace pollution
prevention stuff works, if the user application doesn't call an entry
point at all, it just won't be there.  However, _malloc is always
present (at least in any real program) because it's called from within
the library.
>>

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.

-- 
Joel

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

[Pierre Muller]

At 02:23 06/09/2002 , Joel Brobecker a écrit:
>Hello,
>
>The name of the function used to allocate some memory in the inferior is
>currently hard-coded to "malloc" in valops.c:
>
>      struct value *
>      value_allocate_space_in_inferior (int len)
>      {
>        struct value *blocklen;
>        struct value *val = find_function_in_inferior ("malloc");
>                                                        ^^^^^^
>
>Unfortunately, on interix, the malloc function is not always there.
>Quoting Donn Terry:
><<
>malloc() won't necessarily be present; the way our namespace pollution
>prevention stuff works, if the user application doesn't call an entry
>point at all, it just won't be there.  However, _malloc is always
>present (at least in any real program) because it's called from within
>the library.
> >>
>
>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...
By the way, how is this allocated memory freed after the call to the 
inferior function ?
Does it use another C function for this, or how is it done.
if it also need to find free then we should 
also add a NAME_OF_FREE.

   Would it be possible to add a language field containing this info ?


Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

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

[Daniel Jacobowitz]

On Fri, Sep 06, 2002 at 09:17:11AM +0200, Pierre Muller wrote:
> At 02:23 06/09/2002 , Joel Brobecker a écrit:
> >Hello,
> >
> >The name of the function used to allocate some memory in the inferior is
> >currently hard-coded to "malloc" in valops.c:
> >
> >      struct value *
> >      value_allocate_space_in_inferior (int len)
> >      {
> >        struct value *blocklen;
> >        struct value *val = find_function_in_inferior ("malloc");
> >                                                        ^^^^^^
> >
> >Unfortunately, on interix, the malloc function is not always there.
> >Quoting Donn Terry:
> ><<
> >malloc() won't necessarily be present; the way our namespace pollution
> >prevention stuff works, if the user application doesn't call an entry
> >point at all, it just won't be there.  However, _malloc is always
> >present (at least in any real program) because it's called from within
> >the library.
> > >>
> >
> >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...
> By the way, how is this allocated memory freed after the call to the 
> inferior function ?
> Does it use another C function for this, or how is it done.
> if it also need to find free then we should 
> also add a NAME_OF_FREE.

It doesn't release the memory.  There's some comments in the code about
why not - we have no way of knowing whether the called function stored
a pointer in a global variable somewhere.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Kevin Buettner]

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

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

Kevin

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

[Michael Snyder]

Joel Brobecker wrote:
> 
> Hello,
> 
> The name of the function used to allocate some memory in the inferior is
> currently hard-coded to "malloc" in valops.c:
> 
>      struct value *
>      value_allocate_space_in_inferior (int len)
>      {
>        struct value *blocklen;
>        struct value *val = find_function_in_inferior ("malloc");
>                                                        ^^^^^^
> 
> Unfortunately, on interix, the malloc function is not always there.
> Quoting Donn Terry:
> <<
> malloc() won't necessarily be present; the way our namespace pollution
> prevention stuff works, if the user application doesn't call an entry
> point at all, it just won't be there.  However, _malloc is always
> present (at least in any real program) because it's called from within
> the library.
> >>
> 
> 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.

Joel, 

This is a known limitation.  Certain things in GDB simply will not
work if the target program doesn't contain malloc.  It's been like 
that for 10 years.

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

[Joel Brobecker]

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

Do we have a mechanism already in place that would handle both target
and language? I could not find any. An alternative is for me to add a
target method (for interix), and Pierre adds a language method (for
Pascal).

We then change the code in valops to be something like:

  if (language_special_name_of_malloc ())
    name_of_malloc = language_special_name_of_malloc ();
  else
    name_of_malloc = NAME_OF_MALLOC ();

I am slightly confused by Michael Snyder's message, though. Did it mean
that GDB has no intention of handling the cases where malloc is named
differently?

-- 
Joel

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

[Andrew Cagney]

> 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

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

[muller]

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

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

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

[Andrew Cagney]

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