Re: [RFA]: Fix gdb.base/callfwmall.exp for platforms without malloc

Re: [RFA]: Fix gdb.base/callfwmall.exp for platforms without malloc

[Michael Elizabeth Chastain]

As other people have pointed out, gdb needs a way to allocate memory in
the inferior.  The chosen way is: call "malloc".

If the inferior program truly has no function named "malloc",
then gdb will produce this error:

  evaluation of this expression requires the program to have a function "malloc"

If the inferior program has a function named "malloc", then gdb will
call it.  Sometimes this is non-trivial.  In particular, on hppa*-*-hpux*
targets, the inferior program uses a pair of function stubs for each
call to a shared library function.  These stubs do some bookkeeping
for the address space change from the program text to the shared library
text.

Ordinarily the inferior program sets up these stubs and gdb piggybacks on
that work.  But if a function is available in a shared library, but the
inferior does not call it, then gdb has to do additional work to find the
right place to call.  There are actually different code paths for "call an
inferior function which the inferior itself calls" and "call an inferior
function which the inferior itself does not call".  This is a feature,
and it needs testing.

Also, callfwmall.exp has 11 FAILs on native Red Hat Linux 6.2:

  FAIL: gdb.base/callfwmall.exp: p t_float_values(3.14159,-2.3765)
  FAIL: gdb.base/callfwmall.exp: p t_float_values(float_val1,float_val2)
  FAIL: gdb.base/callfwmall.exp: p t_float_values(3.14159,float_val2)
  FAIL: gdb.base/callfwmall.exp: p t_float_values(float_val1,-2.3765)
  FAIL: gdb.base/callfwmall.exp: p t_float_values2(3.14159,float_val2)
  FAIL: gdb.base/callfwmall.exp: p t_double_values(45.654,-67.66)
  FAIL: gdb.base/callfwmall.exp: p t_double_values(double_val1,double_val2)
  FAIL: gdb.base/callfwmall.exp: p t_double_values(45.654,double_val2)
  FAIL: gdb.base/callfwmall.exp: p t_double_values(double_val1,-67.66)
  FAIL: gdb.base/callfwmall.exp: call inferior func with struct - returns float
  FAIL: gdb.base/callfwmall.exp: call inferior func with struct - returns double

The same tests in callfuncs.exp PASS.

Michael

Re: [RFA]: Fix gdb.base/callfwmall.exp for platforms without malloc

[Michael Snyder]

Stephane Carrez wrote:
> 
> Hi!
> 
> The test gdb.base/callfwmall.exp checks for the GDB ability to
> 'call/print' a function of the inferior.  Several print commands
> require the program to have 'malloc' so that GDB allocates a string
> for input parameters.  The 'callfwmall.c' file does not have any
> reference to malloc, which means that the final executable may not
> have it.  This is my case for HC11.  This means that the test fails
> with:
> 
>  (gdb) FAIL: gdb.base/callfwmall.exp: p t_string_values("string 1","string 2")
> p t_string_values("string 1",string_val2)
> evaluation of this expression requires the program to have a function "malloc".

This is the whole purpose of the callfwmall.c test.  The name stands for
"call functions without malloc".  It tests whether GDB can call functions
without the presence of malloc, and if it cannot (as in your case),
then the test should fail.  Or else be skipped.


> The following patch uses a new 'gdb,nomalloc' configuration variable
> to check whether these 't_string_values' tests can be made or not.
> 
> Can you approve this patch?

No -- but perhaps we could approve a patch that would cause this
test to be skipped (or xfailed) for targets in which we know it
cannot pass.


> 
>         Stephane
> 
> 2001-05-20  Stephane Carrez  <Stephane.Carrez@worldnet.fr>
> 
>         * gdb.base/callfwmall.exp (do_function_calls): Check for gdb,nomalloc
>         and don't execute the tests that require the program to have malloc.
> 
>   ----------------------------------------------------------------------------------------------------
> Index: testsuite/gdb.base/callfwmall.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.base/callfwmall.exp,v
> retrieving revision 1.2
> diff -u -p -r1.2 callfwmall.exp
> --- callfwmall.exp      2001/03/06 08:21:50     1.2
> +++ callfwmall.exp      2001/05/20 11:39:27
> @@ -167,18 +167,24 @@ proc do_function_calls {} {
> 
>      }
> 
> -    gdb_test "p t_string_values(string_val2,string_val1)" " = 0"
> -    gdb_test "p t_string_values(string_val1,string_val2)" " = 1"
> -    gdb_test "p t_string_values(\"string 1\",\"string 2\")" " = 1"
> -    gdb_test "p t_string_values(\"string 1\",string_val2)" " = 1"
> -    gdb_test "p t_string_values(string_val1,\"string 2\")" " = 1"
> -
> +    # Calling a function with a string as parameter requires the
> +    # program to provide malloc().  The string is allocated in
> +    # malloc area (and... by the way never freed!!!).
> +    # Don't execute this test on platforms that don't provide malloc.
> +    if ![target_info exists gdb,nomalloc] {
> +       gdb_test "p t_string_values(string_val2,string_val1)" " = 0"
> +       gdb_test "p t_string_values(string_val1,string_val2)" " = 1"
> +       gdb_test "p t_string_values(\"string 1\",\"string 2\")" " = 1"
> +       gdb_test "p t_string_values(\"string 1\",string_val2)" " = 1"
> +       gdb_test "p t_string_values(string_val1,\"string 2\")" " = 1"
> +    }
>      gdb_test "p t_char_array_values(char_array_val2,char_array_val1)" " = 0"
>      gdb_test "p t_char_array_values(char_array_val1,char_array_val2)" " = 1"
> -    gdb_test "p t_char_array_values(\"carray 1\",\"carray 2\")" " = 1"
> -    gdb_test "p t_char_array_values(\"carray 1\",char_array_val2)" " = 1"
> -    gdb_test "p t_char_array_values(char_array_val1,\"carray 2\")" " = 1"
> -
> +    if ![target_info exists gdb,nomalloc] {
> +       gdb_test "p t_char_array_values(\"carray 1\",\"carray 2\")" " = 1"
> +       gdb_test "p t_char_array_values(\"carray 1\",char_array_val2)" " = 1"
> +       gdb_test "p t_char_array_values(char_array_val1,\"carray 2\")" " = 1"
> +    }
>      gdb_test "p doubleit(4)" " = 8"
>      gdb_test "p add(4,5)" " = 9"
>      gdb_test "p t_func_values(func_val2,func_val1)" " = 0"
> @@ -222,10 +228,12 @@ proc do_function_calls {} {
>      gdb_test "p t_enum_value2(enum_val2)" " = 1"
>      gdb_test "p t_enum_value2(enum_val1)" " = 0"
> 
> -    gdb_test "p sum_args(1,{2})" " = 2"
> -    gdb_test "p sum_args(2,{2,3})" " = 5"
> -    gdb_test "p sum_args(3,{2,3,4})" " = 9"
> -    gdb_test "p sum_args(4,{2,3,4,5})" " = 14"
> +    if ![target_info exists gdb,nomalloc] {
> +       gdb_test "p sum_args(1,{2})" " = 2"
> +       gdb_test "p sum_args(2,{2,3})" " = 5"
> +       gdb_test "p sum_args(3,{2,3,4})" " = 9"
> +       gdb_test "p sum_args(4,{2,3,4,5})" " = 14"
> +    }
>      gdb_test "p sum10 (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)" " = 55"
> 
>      gdb_test "p t_structs_c(struct_val1)" "= 120 'x'" \

Re: [RFA]: Fix gdb.base/callfwmall.exp for platforms without malloc

[Keith Seitz]

On Mon, 21 May 2001, Michael Snyder wrote:

> No -- but perhaps we could approve a patch that would cause this
> test to be skipped (or xfailed) for targets in which we know it
> cannot pass.

Somewhere I am sitting on patches to change the behavior of this to XFAIL
if malloc does not exist. It does not rely on a particular config
variable. Instead, it queries gdb if malloc exists in the symbol table.

Would this be better? (Didn't we have this discussion a little while ago?
Deja vu?)

Keith

Re: [RFA]: Fix gdb.base/callfwmall.exp for platforms without malloc

[Michael Snyder]

Keith Seitz wrote:
> 
> On Mon, 21 May 2001, Michael Snyder wrote:
> 
> > No -- but perhaps we could approve a patch that would cause this
> > test to be skipped (or xfailed) for targets in which we know it
> > cannot pass.
> 
> Somewhere I am sitting on patches to change the behavior of this to XFAIL
> if malloc does not exist. It does not rely on a particular config
> variable. Instead, it queries gdb if malloc exists in the symbol table.
> 
> Would this be better? (Didn't we have this discussion a little while ago?
> Deja vu?)

Yes it did, and no that would not be better.  ;-)
The idea of the test is to confirm that GDB can pass the test 
even if there is no malloc.  I know this is counter-intuitive, 
because we are all used to the idea that gdb can NOT pass this
test if there is no malloc -- but apparently there are some 
targets (at least one) on which it can.

Re: [RFA]: Fix gdb.base/callfwmall.exp for platforms without malloc

[Stephane Carrez]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

Hi!

Michael Snyder a écrit :
> 
> Keith Seitz wrote:
> >
> > On Mon, 21 May 2001, Michael Snyder wrote:
> >
> > > No -- but perhaps we could approve a patch that would cause this
> > > test to be skipped (or xfailed) for targets in which we know it
> > > cannot pass.
> >
> > Somewhere I am sitting on patches to change the behavior of this to XFAIL
> > if malloc does not exist. It does not rely on a particular config
> > variable. Instead, it queries gdb if malloc exists in the symbol table.
> >
> > Would this be better? (Didn't we have this discussion a little while ago?
> > Deja vu?)
> 
> Yes it did, and no that would not be better.  ;-)
> The idea of the test is to confirm that GDB can pass the test
> even if there is no malloc.  I know this is counter-intuitive,
> because we are all used to the idea that gdb can NOT pass this
> test if there is no malloc -- but apparently there are some
> targets (at least one) on which it can.

Hum... if I understand, the only good fix is to fix GDB so that it no longer
calls 'malloc'.  I would be very happy to see that fix in GDB.  You cannot rely
on a possible 'malloc'.  I have two examples in mind here: 68HC11 programs
and... ChorusOS kernel.

Do you have any patch or are you working on any fix so that GDB does not call
'malloc' any more?

For example, by allocating the string on the stack, as it does for the arguments.
Ok, it's more complex; you'll need a two-pass argument processing, one for
string allocation, and one to really push the arguments.

	Stephane

-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@worldnet.fr               Stephane.Carrez@sun.com
WWW:    http://home.worldnet.fr/stcarrez   http://www.sun.com
Mail:   17, rue Foucher Lepelletier        6, avenue Gustave Eiffel
        92130 Issy Les Moulineaux          78182 Saint Quentin en Yvelines
        France

Re: [RFA]: Fix gdb.base/callfwmall.exp for platforms without malloc

[Michael Snyder]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

Stephane Carrez wrote:
> 
> Hi!
> 
> Michael Snyder a écrit :
> >
> > Keith Seitz wrote:
> > >
> > > On Mon, 21 May 2001, Michael Snyder wrote:
> > >
> > > > No -- but perhaps we could approve a patch that would cause this
> > > > test to be skipped (or xfailed) for targets in which we know it
> > > > cannot pass.
> > >
> > > Somewhere I am sitting on patches to change the behavior of this to XFAIL
> > > if malloc does not exist. It does not rely on a particular config
> > > variable. Instead, it queries gdb if malloc exists in the symbol table.
> > >
> > > Would this be better? (Didn't we have this discussion a little while ago?
> > > Deja vu?)
> >
> > Yes it did, and no that would not be better.  ;-)
> > The idea of the test is to confirm that GDB can pass the test
> > even if there is no malloc.  I know this is counter-intuitive,
> > because we are all used to the idea that gdb can NOT pass this
> > test if there is no malloc -- but apparently there are some
> > targets (at least one) on which it can.
> 
> Hum... if I understand, the only good fix is to fix GDB so that it no longer
> calls 'malloc'. 

No, I think the fix is to fix the testcase so that it will be skipped
for all targets except for the few (only one that I know of) that is
capable of performing this functionality without relying on malloc.

Of course, if you WANT to undertake to fix GDB so that it does not
need to rely on malloc, please feel free.  But I do not think it will
be easy.

Michael

Re: [RFA]: Fix gdb.base/callfwmall.exp for platforms without malloc

[Jim Blandy]

Stephane Carrez <Stephane.Carrez@worldnet.fr> writes:
> Hum... if I understand, the only good fix is to fix GDB so that it
> no longer calls 'malloc'.  I would be very happy to see that fix in
> GDB.  You cannot rely on a possible 'malloc'.  I have two examples
> in mind here: 68HC11 programs and... ChorusOS kernel.
> 
> Do you have any patch or are you working on any fix so that GDB does
> not call 'malloc' any more?
> 
> For example, by allocating the string on the stack, as it does for
> the arguments.  Ok, it's more complex; you'll need a two-pass
> argument processing, one for string allocation, and one to really
> push the arguments.

That test file is a confused piece of code, and everyone who reads it
seems to get confused, too.  GDB can call any function just fine
without ever using malloc, and GDB may need to use malloc even when
the user has never entered a function call to evaluate.

GDB calls malloc in the inferior to evaluate even simple expressions
like this:

    (gdb) print str = "hi there"

(where `str' is a char *).  Allocating strings on the stack isn't an
acceptable implementation for uses like this: the inferior's code
might not be prepared to have its frame size changed, and you have no
way to know whether the string's lifetime is shorter than that of the
frame anyway.

Basically, in order to evaluate string literals, GDB must have some
reliable way to find storage in the inferior which will never be used
for anything else.  Calling malloc is one way to do this.  If malloc
isn't available, the target should provide an alternative, or GDB
should say, "Sorry, can't evaluate string literals on this target."

I think callfwmall.{exp,c} should simply be deleted.  They do a bad
job of testing functionality that GDB cannot promise to provide.  HP
created the test file because their run-time support is guaranteed to
include malloc; at the very least, callfwmall.{exp,c} should be moved
into gdb.hp.

Re: [RFA]: Fix gdb.base/callfwmall.exp for platforms without malloc

[Andrew Cagney]

> Hum... if I understand, the only good fix is to fix GDB so that it no longer
> calls 'malloc'.  I would be very happy to see that fix in GDB.  You cannot rely
> on a possible 'malloc'.  I have two examples in mind here: 68HC11 programs
> and... ChorusOS kernel.


A patch to call sbrk() or rgnAllocate(ulgh!) et.al. instead of malloc() 
would be interesting.

	Andrew