Re: [RFA] Assuming malloc exists in callfwmall.exp

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

I was going to drop this, but ...

> This is irrelevant.  The GDB test suite exists to verify that GDB
> behaves as documented.  If a test checks for behavior which is not
> guaranteed, the test is in error, and should simply be removed.

callfwmalls.exp checks that "call foo(10)" works in a target program
that does not call malloc.  That check is useful.

It also checks that "call foo("bar")" works in a target program that
does not call malloc.  That check is useless.

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Hi Michael,

> No, the check is not useful.  "call foo(10)" has nothing
> to do with malloc.

We've been through this.

How do you know that "call foo(10) does not use malloc"?
What is the source of your knowledge?

I know that "call foo(10) does not use malloc" because:

  . I inspected the code
  . I ran callfwmall.exp and it PASSed that test.

> Um -- Michael, did you get those two mixed up?

No.

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Hi Jim,

> So the real disagreement is whether this is a valuable thing to test
> for.  Since I cannot imagine any reasonable inferior function
> invocation mechanism that would rely on the existence of malloc, I
> think it's as useless to test for that as to test for, say, the
> ability of GDB to handle functions named `t_structs_i' (which
> callfwmall also tests for us!).

Ah, yeah, now we are talking about the same thing, just disagreeing.
Which is how I hope to leave it.

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

[I thought about whether to reply to this ... I want to mention one data
 point, and that's all I will write].

Jim Blandy writes:
> Not if you link statically.

I did link statically.

  [chastain@delta chastain]$ cat bar.c
  main ()
  {
    write (1, "Howdy.\n", 7);
  }
  [chastain@delta chastain]$ gcc --version
  2.9-gnupro-99r1
  [chastain@delta chastain]$ gcc bar.c -o bar -g -static
  [chastain@delta chastain]$ gdb bar
  GNU gdb 4.18-gnupro-99r1
  Copyright 1998 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain conditions.
  Type "show copying" to see the conditions.  This version of GDB is supported
  for customers of Cygnus Solutions.  Type "show warranty" for details.
  This GDB was configured as "sparc-sun-solaris2.5"...
  (gdb) break main
  Breakpoint 1 at 0x101fc: file bar.c, line 3.
  (gdb) run
  Starting program: /home/chastain/bar 

  Breakpoint 1, main () at bar.c:3
  3         write (1, "Howdy.\n", 7);
  (gdb) write (1, "bye", 3);   
  Undefined command: "write".  Try "help".
  (gdb) call write (1, "bye", 3)
  bye$1 = 3
  (gdb) p malloc
  $2 = {<text variable, no debug info>} 0x140ac <malloc>

So malloc does get pulled in on my Solaris configuration.

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Jim Blandy]

This is irrelevant.  The GDB test suite exists to verify that GDB
behaves as documented.  If a test checks for behavior which is not
guaranteed, the test is in error, and should simply be removed.

GDB does not, and should not, promise to make array literals work on
every target.  GDB should promise to make them work when:
- GDB has the ability to invoke functions on this architecture,
- the inferior is running, and
- malloc is available and working.
If these conditions are not met, the inability to evaluate array
literals is not a failure.

The only reason to hedge on this question at all is that HP seemed to
think, a while back, that GDB should guarantee to make array literals
work on HP-UX.  I don't know the reasoning.  They may simply have been
misled.

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Fernando,

> And I think this thread is too long for such a small thing.
> I have better things to do.

Okay.  I give up, too.

> If this test file stays it will stay in its abbreviated form.

You're the maintainer.  You can do whatever you want to callfwmall.exp.

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Fernando,

chastain> How do you know whether calling an inferior function uses malloc or not?

fernando> If it does not call a string it does not.

This is a very literal question.

OK, so you know that when gdb calls an inferior function with no string
arguments (or arrays, or big structures, whatever), and the target
program does not itself call malloc(), that the call works properly.

*How* do you know?

I know because I ran callfwmall.exp, callfwmall.exp tested this behavior,
and told me that it PASSed.

I also know because I read the source code in gdb/valops.c, which is a
different avenue of knowledge.

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Jim Blandy]

I think I see what Michael C. is getting at now.

We've (or at least I've) been asserting that callfwmall expects
behavior from GDB which is not promised or guaranteed --- the ability
to evaluate array literals in inferiors that don't explicitly link in
malloc.

However, any test actually exercises a zillion things.  For example,
callfwmall exercises GDB's command parser, its symbol table reader,
etc.

Michael's pointing out that callfwmall also tests GDB's ability to
*invoke inferior functions* in programs that don't explicitly link in
malloc.  Which, frankly, hadn't occurred to me, since inferior
function invocation itself has zippo to do with malloc.  But the
file's name does suggest that this is its purpose.  You have to know
its contents and history to see what's really going on.

So the real disagreement is whether this is a valuable thing to test
for.  Since I cannot imagine any reasonable inferior function
invocation mechanism that would rely on the existence of malloc, I
think it's as useless to test for that as to test for, say, the
ability of GDB to handle functions named `t_structs_i' (which
callfwmall also tests for us!).

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Hi Fernando,

> And if he/she is a really good maintainer he/she will reject your patch
> as it would be adding a restriction to inferior function calls that we
> do not currently have.

This is bothering me.

I've seen some real "this is so embarrassing I should wear a brown
paper bag over my head" bugs:

  (gdb) set input-radix 2
  Input radix now set to decimal 4294967295, hex ffffffff, octal 37777777777.

Sorry if I make the author of that bug blush.   My point is that this
happens in software, and that it's the job of the test suite to detect
when it happens.

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Fernando Nasser]

Michael Elizabeth Chastain wrote:
> 
> Hi Fernando,
> 
> > And if he/she is a really good maintainer he/she will reject your patch
> > as it would be adding a restriction to inferior function calls that we
> > do not currently have.
> 
> This is bothering me.
> 
> I've seen some real "this is so embarrassing I should wear a brown
> paper bag over my head" bugs:
> 
>   (gdb) set input-radix 2
>   Input radix now set to decimal 4294967295, hex ffffffff, octal 37777777777.
> 
> Sorry if I make the author of that bug blush.   My point is that this
> happens in software, and that it's the job of the test suite to detect
> when it happens.
> 

I don't see a relation to what we were discussing.

And I think this thread is too long for such a small thing.
I have better things to do.

If this test file stays it will stay in its abbreviated form.

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Hi Jim,

> I think it's simply a property of HP's system --- perhaps a
> characteristic of the dynamic linker, perhaps something else --- that
> malloc is always available to the debugger, whether the program uses
> it or not.

As Kevin Buettner pointed out, it's the normal behavior on Red Hat Linux
natives.

It's also the normal behavior on Solaris native.  (Tested on Solaris 2.6
native with 2.9-gnupro-99r1 and with Sun's cc 4.2).

It's the normal behavior on i586-sco-sysv5uw7.1.1, as shown in test
results where callfwmall.exp passes all its tests.

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Eli Zaretskii]

> From: Michael Elizabeth Chastain <chastain@cygnus.com>
> Date: Thu, 15 Feb 2001 12:15:58 -0800
> 
> As Kevin Buettner pointed out, it's the normal behavior on Red Hat Linux
> natives.
> 
> It's also the normal behavior on Solaris native.  (Tested on Solaris 2.6
> native with 2.9-gnupro-99r1 and with Sun's cc 4.2).
> 
> It's the normal behavior on i586-sco-sysv5uw7.1.1, as shown in test
> results where callfwmall.exp passes all its tests.

FWIW, it is also the normal behavior of the DJGPP programs, since the
startup code calls malloc.

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

> Aren't we trying to be a little bit too pro-active here?  We are missing
> tests for things that are already in the code.  Adding tests for things
> that may or may not be in the code is somewhat new.

That's not pro-active.  callfwmall.exp already exists.  I'm explaining
what it tests, and why callfunc.exp does not test that.

> And if he/she is a really good maintainer he/she will reject your patch
> as it would be adding a restriction to inferior function calls that we
> do not currently have.

How do you know whether calling an inferior function uses malloc or not?

You know because callfwmall.exp tests it.

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Fernando Nasser]

Michael Elizabeth Chastain wrote:
> 
> > And if he/she is a really good maintainer he/she will reject your patch
> > as it would be adding a restriction to inferior function calls that we
> > do not currently have.
> 
> How do you know whether calling an inferior function uses malloc or not?
> 

If it does not call a string it does not.


> You know because callfwmall.exp tests it.
> 

???


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

> I don't get it.  malloc is not used at all when the argument is not a
> string.  So, what malloc() being available or not has to do with this
> situation?

The point is that use case #3 should keep working, even if
someone changes gdb.

Suppose I check in a patch tomorrow to allocate the call dummy in malloc'd
memory instead of the target's stack.

Would that be a problem?
If it is a problem, what test case can catch it?

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Fernando Nasser]

Michael Elizabeth Chastain wrote:
> 
> > I don't get it.  malloc is not used at all when the argument is not a
> > string.  So, what malloc() being available or not has to do with this
> > situation?
> 
> The point is that use case #3 should keep working, even if
> someone changes gdb.
> 

Aren't we trying to be a little bit too pro-active here?  We are missing tests for things that are already in the code.  Adding tests for things that may or may not be in the code is somewhat new.

> Suppose I check in a patch tomorrow to allocate the call dummy in malloc'd
> memory instead of the target's stack.
> 

Then the good maintainer in charge of that code will suggest that you should also submit a test case for that.

And if he/she is a really good maintainer he/she will reject your patch as it would be adding a restriction to inferior function calls that we do not currently have.



In any case, having *one* useless test is still better than a test file full of them.  
If you are willing to get it in the shape suggested by Kevin and I you can add the #3 if you want. But please add the following comment (or similar):
# Gdb does not currently use malloc() for inferior calls with integer arguments
# If it ever does, it will be tested in here. 

Just to check if we are in the same page: there would be 3 tests in there:
.You test for malloc presence
.A test with the string argument
.The integer argument one

The last two, as you suggested, pass on both error message and success call.


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Jim Blandy]

Here's the whole story regarding callfwmall.{c,exp}.  Some of this is
repetition, but I want to put it all in one place:

Whenever GDB needs to construct a literal array in the target memory
(e.g., a string literal, or an array literal like {0, 1, 2}), it calls
malloc in the inferior to find space for the value, writes the
contents, and then uses the malloc'd block's address as the value of
the array literal.

Naturally, this only works if the inferior actually has a malloc
implementation linked in somewhere, and GDB has the ability to invoke
functions in the inferior for this target.

I think it's simply a property of HP's system --- perhaps a
characteristic of the dynamic linker, perhaps something else --- that
malloc is always available to the debugger, whether the program uses
it or not.

The callfwmall.{c,exp} test file was introduced to test this behavior,
as part of a grand merge of HP's changes in 1998.  One of the most...
um... memorable characteristics of the changes was that, when the work
was originally being done at HP, the engineers were told not to worry
about whether their version of GDB could still work on platforms other
than HP-UX.  So the changes the Cygnus folks were trying to merge were
often completely inappropriate for other platforms; they had to do
their best to fix them up for inclusion in the main sources.

So this file tests a behavior which is not promised or expected on
systems other than HP-UX.  It would be appropriate to move it to
gdb.hp, so the file would be omitted completely on non-HP systems, or
to xfail all the tests in the file on non-HP systems.

I agree with Kevin that it's not worth making it work on systems that
don't have malloc.  There is no portable way I can see to tell what
portions of the address space might be safe for GDB to use --- you
need intimate knowledge of the target program's environment.  But the
fact that someone *could* do so argues for the "XFAIL on all but a
selected set of systems, initially only HP" approach, instead of
moving it to gdb.hp.

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Hi Fernando,

> Both Kevin and I are now proposing a minimal test for #4

Oops, I missed that in my recapitulation.  Yes, you are.

To be correct, that test should accept either "$1 = 3" or
"error: evalation ... requires ... "malloc"".

> (#3 does not depend on malloc() so it is already tested in callfuncs).

No.  Look at use case #3:

  Use case #3:

    . malloc is not available
    . the user types: call abs(-10)
    . gdb expected response: "$1 = 10"

callfuncs.c contains an explicit call to malloc.  Therefore, callfuncs.exp
does not check use case #3.  It checks use case #1.

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Fernando Nasser]

Michael Elizabeth Chastain wrote:
> 
> > (#3 does not depend on malloc() so it is already tested in callfuncs).
> 
> No.  Look at use case #3:
> 
>   Use case #3:
> 
>     . malloc is not available
>     . the user types: call abs(-10)
>     . gdb expected response: "$1 = 10"
> 
> callfuncs.c contains an explicit call to malloc.  Therefore, callfuncs.exp
> does not check use case #3.  It checks use case #1.

I don't get it.  malloc is not used at all when the argument is not a
string.  So, what malloc() being available or not has to do with this
situation?




-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Hi Fernando,

> The other case to be tested is when there isn't a malloc() available at
> all (that is why the test Keith and you proposed is so nice).  But the
> FAILs are wrong.  Not having malloc() available is not GDB's fault and
> it may be just a limitation of the target environment.

I think there are four use cases.

Use case #1:

  . malloc is available
  . the user types: call abs(-10)
  . gdb expected response: "$1 = 10"

Use case #2:

  . malloc is available
  . the user types: call strlen("foo")
  . gdb expected response: "$1 = 3"

Use case #3:

  . malloc is not available
  . the user types: call abs(-10)
  . gdb expected response: "$1 = 10"

Use case #4:

  . malloc is not available
  . the user types: call strlen("foo")
  . gdb expected responses: either one of
    . "$1 = 3"
    . error: evaluation of this expression requires the program to have a function "malloc"

callfuncs.exp tests #1 and #2.
callfuncs.exp can never test #3 or #4.

callfwmall.exp, as written, tests use case #3 (on some platforms).

callfwmall.exp, as written, has an incorrect test for #4.  It accepts only
the first response, but gdb can produce either response, and the current
gdb produces the second response.

Keith's patch removes use case #4 from the test coverage.

Michael's patch makes callfwmall.exp verify that it gdb+inferior is in the
regime of #3 and #4.  If gdb+inferior is not, then callfwmall.exp returns
UNTESTED.  If gdb+inferior is in that regime (inferior has no malloc),
then it tests #3 only.  I could make it test #4 properly by adding more RE's.

Fernando's proposal is to remove coverage of #3 and #4.

Kevin's evidence is that Linux native, and probably every glibc platform,
never enters the regime of #3 and #4 anyways.

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Fernando Nasser]

Michael Elizabeth Chastain wrote:
> 
> Fernando's proposal is to remove coverage of #3 and #4.
> 

You may have missed some messages from me and Kevin.

Both Kevin and I are now proposing a minimal test for #4 (#3 does not
depend on malloc() so it is already tested in callfuncs).

It would consist of your test for the presence of malloc() and, if it
indeed is not there, a *single* test for the error message.


Michael Elizabeth Chastain wrote:
> 
> Hi Fernando,
> 
> > The other case to be tested is when there isn't a malloc() available at
> > all (that is why the test Keith and you proposed is so nice).  But the
> > FAILs are wrong.  Not having malloc() available is not GDB's fault and
> > it may be just a limitation of the target environment.
> 
> I think there are four use cases.
> 
> Use case #1:
> 
>   . malloc is available
>   . the user types: call abs(-10)
>   . gdb expected response: "$1 = 10"
> 
> Use case #2:
> 
>   . malloc is available
>   . the user types: call strlen("foo")
>   . gdb expected response: "$1 = 3"
> 
> Use case #3:
> 
>   . malloc is not available
>   . the user types: call abs(-10)
>   . gdb expected response: "$1 = 10"
> 
> Use case #4:
> 
>   . malloc is not available
>   . the user types: call strlen("foo")
>   . gdb expected responses: either one of
>     . "$1 = 3"
>     . error: evaluation of this expression requires the program to have a function "malloc"
> 
> callfuncs.exp tests #1 and #2.
> callfuncs.exp can never test #3 or #4.
> 
> callfwmall.exp, as written, tests use case #3 (on some platforms).
> 
> callfwmall.exp, as written, has an incorrect test for #4.  It accepts only
> the first response, but gdb can produce either response, and the current
> gdb produces the second response.
> 
> Keith's patch removes use case #4 from the test coverage.
> 
> Michael's patch makes callfwmall.exp verify that it gdb+inferior is in the
> regime of #3 and #4.  If gdb+inferior is not, then callfwmall.exp returns
> UNTESTED.  If gdb+inferior is in that regime (inferior has no malloc),
> then it tests #3 only.  I could make it test #4 properly by adding more RE's.
> 
> Fernando's proposal is to remove coverage of #3 and #4.
> 
> Kevin's evidence is that Linux native, and probably every glibc platform,
> never enters the regime of #3 and #4 anyways.
> 
> Michael


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Hi Fernando,

> Should we test GDB's ability to find malloc() from the shared libraries
> per se?  The little test code added by Keith and revamped by Michael
> could be used to do that.

Ah, I had that problem on hpux 10.20.  The section tables were messed up
and gdb was unable to call malloc().  It caused hundreds of FAILs.
So I think there is no need for a separate test.

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Hi Fernando,

> Unless the HP dependent code is capable of doing this, them we move it
> to gdb.hp with only the tests that are related to malloc() --

I can take care of this case.  If you look at valops.c, you can see that
there is no special code for hpux or any other target.  There is just one
implementation of value_allocate_space_in_inferior, and it always uses
"malloc".

I agree, if some target has special code, then it needs tests to
exercise the special code.

> But the reason we know that these tests will work without malloc() is
> because they independ on malloc().

So, suppose that next month someone changes call_function_by_hand so
that it always calls value_allocate_space_in_inferior.  callfuncs.exp
will not complain at all, but callfwmall.exp will raise a bunch of
FAILs.

That's what the test is for.  It tests that gdb can do "call foo(10)"
in a program that does not use malloc.  callfuncs.exp cannot test that.

> As there are no such targets I propose we get rid of callfwmall.exp.  I
> never liked the spelling anyway -- it is unpronounceable.

I'm not strongly attached to it.  It's OK with me if you kill it.

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Fernando Nasser]

Michael Elizabeth Chastain wrote:
> 
> So, suppose that next month someone changes call_function_by_hand so
> that it always calls value_allocate_space_in_inferior.  callfuncs.exp
> will not complain at all, but callfwmall.exp will raise a bunch of
> FAILs.
> 

Only if GDB does not find a malloc() in there.  

If malloc() is available, it doesn't matter if if was linked in because
of the program or not.  In any case, callfuncs.exp already test that
case.

The other case to be tested is when there isn't a malloc() available at
all (that is why the test Keith and you proposed is so nice).  But the
FAILs are wrong.  Not having malloc() available is not GDB's fault and
it may be just a limitation of the target environment.

In this second case what we have to test (only when malloc is not
available) is the GDB's reaction to this situation, i.e., the issue of
an appropriate error message.  It should not crash, silently return
without telling the user, etc.

> That's what the test is for.  It tests that gdb can do "call foo(10)"
> in a program that does not use malloc.  callfuncs.exp cannot test that.
> 

If someone has changed it to use malloc() as you said, it should fail. 
Again, we are looking for an error message here.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Here's a diff for consideration.

This script tests the following gdb features:

  [1] gdb can call functions in the inferior
  [2] gdb does not use the inferior's malloc to achieve feature [1].
      Thus, [1] works even for inferiors that have no malloc.

callfuncs.exp is incapable of testing [2] because it uses an inferior
program that is guaranteed to contain malloc.

If malloc is present in the inferior, then this script returns UNTESTED,
because it cannot verify [2] using this inferior program.  (Well,
it could, with enough work -- for instance, the script could set a
breakpoint on malloc and then FAIL if the breakpoint ever triggers).

If malloc is not present, the script proceeds to test a bunch of things
that we believe should work.  It does not test things that we know,
by design, don't work.

Keith, what do you think of this?  Does this work for you?

Michael

===

Index: callfwmall.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/callfwmall.exp,v
retrieving revision 1.1.1.3
diff -c -3 -p -r1.1.1.3 callfwmall.exp
*** callfwmall.exp	1999/09/09 00:00:21	1.1.1.3
--- callfwmall.exp	2001/02/15 03:18:14
*************** proc do_function_calls {} {
*** 169,183 ****
  
      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"
  
      gdb_test "p doubleit(4)" " = 8"
      gdb_test "p add(4,5)" " = 9"
--- 169,177 ----
*************** proc do_function_calls {} {
*** 222,231 ****
      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"
      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'" \
--- 216,221 ----
*************** if { $hp_aCC_compiler } {
*** 274,279 ****
--- 264,296 ----
  	    gdb_suppress_tests;
  	}
      }
+ }
+ 
+ # The point of this test script is to call a bunch of stuff in the inferior
+ # without using malloc in the inferior.  If malloc exists, then this test
+ # is pointless.
+ 
+ send_gdb "p malloc\n"
+ gdb_expect {
+   -re ".*No symbol \"malloc\".*$gdb_prompt $" {
+     # Cool, this is what I want.
+     pass "probe for malloc in inferior (malloc NOT present)"
+   }
+   -re ".*malloc.*$gdb_prompt $" {
+     untested "probe for malloc in inferior (malloc found, all tests skipped)"
+     remote_close host
+     return -1
+   }
+   -re ".*$gdb_prompt $" {
+     fail "probe for malloc in inferior"
+     remote_close host
+     return -1
+   }
+   timeout {
+     fail "probe for malloc in inferior (timeout)"
+     remote_class host
+     return -1
+   }
  }
  
  gdb_test "next" ".*"

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Fernando Nasser]

Michael Elizabeth Chastain wrote:
> 
> If malloc is not present, the script proceeds to test a bunch of things
> that we believe should work.  It does not test things that we know,
> by design, don't work.
> 

But the reason we know that these tests will work without malloc() is
because they independ on malloc().

Thus, they have already been tested in callfuncs.exp (doesn't matter
that the inferior had an malloc -- these things do not use it at all)
and this whole callfwmall.exp is just useless.


I am now lead to believe that these tests would only be useful for
targets that have an alternative way to deal with string arguments when
malloc() is not available in the inferior.

As there are no such targets I propose we get rid of callfwmall.exp.  I
never liked the spelling anyway -- it is unpronounceable.

Unless the HP dependent code is capable of doing this, them we move it
to gdb.hp with only the tests that are related to malloc() -- the other
are just repetition of callfuncs.exp in any case you may think of.



-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Fernando Nasser]

I may have found a use for this test:

test the error message issued when no malloc() is available.

We can use Michaels code to test for malloc() and skip the tests if
malloc() is present.

If malloc() is NOT present, then we leave (do not delete) one of the
tests that has a string argument -- just one is enough -- and check for
the error message that is issued.


Question: which target would not have malloc() available?  Some embedded
target linked with newlib where neither the program nor any of the
library functions it calls use malloc()?


I guess this test will not run very often :-)




Fernando Nasser wrote:
> 
> Michael Elizabeth Chastain wrote:
> >
> > If malloc is not present, the script proceeds to test a bunch of things
> > that we believe should work.  It does not test things that we know,
> > by design, don't work.
> >
> 
> But the reason we know that these tests will work without malloc() is
> because they independ on malloc().
> 
> Thus, they have already been tested in callfuncs.exp (doesn't matter
> that the inferior had an malloc -- these things do not use it at all)
> and this whole callfwmall.exp is just useless.
> 
> I am now lead to believe that these tests would only be useful for
> targets that have an alternative way to deal with string arguments when
> malloc() is not available in the inferior.
> 
> As there are no such targets I propose we get rid of callfwmall.exp.  I
> never liked the spelling anyway -- it is unpronounceable.
> 
> Unless the HP dependent code is capable of doing this, them we move it
> to gdb.hp with only the tests that are related to malloc() -- the other
> are just repetition of callfuncs.exp in any case you may think of.
> 

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Kevin Buettner]

On Feb 15,  4:19am, Fernando Nasser wrote:

> I may have found a use for this test:
> 
> test the error message issued when no malloc() is available.
> 
> We can use Michaels code to test for malloc() and skip the tests if
> malloc() is present.
> 
> If malloc() is NOT present, then we leave (do not delete) one of the
> tests that has a string argument -- just one is enough -- and check for
> the error message that is issued.

I am in favor of this very much abbreviated test.

> Question: which target would not have malloc() available?  Some embedded
> target linked with newlib where neither the program nor any of the
> library functions it calls use malloc()?

That sounds right to me.

It *seemed* to me that it should be possible to construct an
executable which wouldn't have malloc for nearly any target.  But this
turns out to be very difficult.  My idea was to take a small program
which didn't call malloc(), nor any C library functions and statically
link it.

To that end, I played around with the following program on my Linux
box...

int
main (int argc, char **argv)
{
  return 0;
}

I compiled it statically, so that malloc wouldn't creep in through
the dynamic linker (ld-linux.so.2 defines a rudimentary malloc via
a weak symbol that the dynamic linker uses to load shared libraries).
But, it turns out that malloc is still linked in anyway...

(gdb) b malloc
Breakpoint 1 at 0x8048c7a: file malloc.c, line 2691.
(gdb) r
Starting program: /home/kev/ctests/empty 

Breakpoint 1, __libc_malloc (bytes=8) at malloc.c:2697
2697    malloc.c: No such file or directory.
(gdb) bt
#0  __libc_malloc (bytes=8) at malloc.c:2697
#1  0x8053824 in _dl_important_hwcaps (platform=0x0, platform_len=0, 
    sz=0x809c470, max_capstrlen=0x809c474) at dl-support.c:189
#2  0x804d856 in _dl_init_paths (llp=0x0) at dl-load.c:576
#3  0x80536d7 in non_dynamic_init () at dl-support.c:143
#4  0x8053ba0 in __libc_init (argc=1, argv=0xbffffac4, envp=0xbffffacc)
    at set-init.c:23
#5  0x8053a1b in init (argc=1, argv=0xbffffac4, envp=0xbffffacc)
    at ../sysdeps/unix/sysv/linux/init-first.c:96
#6  0x8048294 in __libc_start_main (main=0x80481dc <main>, argc=1, 
    ubp_av=0xbffffac4, init=0x80480b4 <_init>, fini=0x808c680 <_fini>, 
    rtld_fini=0, stack_end=0xbffffabc) at ../sysdeps/generic/libc-start.c:109

I suspect that most targets which use glibc will show similar results.
It would be possible to supply alternate runtime initialization code,
but I think that putting the end result in the testsuite would result
in something that is hard to maintain.

Anyway, as I mentioned earlier, I am in favor of Fernando's abbreviated
tests.

Kevin

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Argh.  Let me say that again:

chastain> (1) Test for the presence of malloc the way Keith Seitz is doing
chastain>     (but put the test after runto_main).

cagney> it is testing exactly what it should be testing but the above would
cagney> disable malloc for this target.

I'm proposing that Keith move the "p malloc" line *after* the call
to "runto_main".  That would detect that malloc was available in the
inferior.

If malloc is available in the inferior, then callfwmall.exp should
stop execution.  If malloc is not available, then callfwmall.exp can
continue testing that gdb can make inferior calls in a target program
that does not have malloc.

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Another hour, another change of mind.

The point of callfwmall.exp is to show that gdb can call functions in
the inferior even if the inferior does not have "malloc".  callfuncs.exp
will never be able to do that.

So I think the right thing to do in callfwmall.exp is:

(1) Test for the presence of malloc the way Keith Seitz is doing
    (but put the test after runto_main).

(2) If malloc is present, disable the test script.

(3) If malloc is absent, go ahead and run the whole test script.

(4) Those lines like "call foo ("bar")" that do not work without malloc:

      send_gdb "call foo ("bar")\n"
      gdb_expect {
	-re "... works ok" ... {
	  pass ...
	}
	-re "unable to call target function 'malloc'" ... {
	  pass ...
	}
	default {
	  fail ...
	}
	timeout {
	  fail ... (timeout)
	}

In the interim, I'm in favor of Keith's patch (with the test after
runto_main).

Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Andrew Cagney]

Michael Elizabeth Chastain wrote:
> 
> Another hour, another change of mind.
> 
> The point of callfwmall.exp is to show that gdb can call functions in
> the inferior even if the inferior does not have "malloc".  callfuncs.exp
> will never be able to do that.
> 
> So I think the right thing to do in callfwmall.exp is:
> 
> (1) Test for the presence of malloc the way Keith Seitz is doing
>     (but put the test after runto_main).
> 
> (2) If malloc is present, disable the test script.
> 
> (3) If malloc is absent, go ahead and run the whole test script.

I don't think this logic is right.  Consider:

This GDB was configured as "i386-unknown-netbsdelf1.5.1."...
(gdb) p malloc
No symbol "malloc" in current context.
(gdb) p main
$1 = {int ()} 0x8048954 <main>
(gdb) b main
Breakpoint 1 at 0x8048959: file
/home/scratch/GDB/src/gdb/testsuite/gdb.base/callfwmall.c, line 177.
(gdb) run
Starting program:
/home/scratch/GDB/native/gdb/testsuite/gdb.base/callfwmall 

Breakpoint 1, main ()
    at /home/scratch/GDB/src/gdb/testsuite/gdb.base/callfwmall.c:177
177       t_structs_c(struct_val1);
(gdb) p malloc
$2 = {<text variable, no debug info>} 0x4804d020 <malloc>
(gdb) 

it is testing exactly what it should be testing but the above would
disable malloc for this target.

	Andrew

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Kevin Buettner writes:

> I think the present behavior is acceptable.  It looks for malloc()
> anyway to see if it has snuck in via some other means; if it can't
> find it, it prints out a message to that effect.

OK with me.  I've never actually seen that message, but the code
in "fund_function_in_inferior" throws an error if the symbol is
not found:

  evaluation of this expression requires the program to have a function \"%s\".

Keith, are you getting these in your gdb.log?

> So...  what should become of callfwmall.exp?  As I recall, this test
> is identical to another test (callfuncs.exp) except that it simply
> lacks a call to malloc(), right?

Let me bust a diff:

  1c1
  < Running /vittone/fsf/2001-02-13/source-src/gdb/testsuite/gdb.base/callfuncs.exp ...
  ---
  > Running /vittone/fsf/2001-02-13/source-src/gdb/testsuite/gdb.base/callfwmall.exp ...
  7d6
  < PASS: next
  57d55
  < PASS: p t_call_add(add,3,4)
  58a57
  > PASS: p t_call_add(add,3,4)
  70d68
  < PASS: p cmp10 (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
  78,86d75
  < PASS: gdb function calls preserve register contents
  < PASS: continue from call dummy breakpoint
  < PASS: bt after continuing from call dummy breakpoint
  < PASS: continue after stop in call dummy preserves register contents
  < PASS: finish from call dummy breakpoint returns correct value
  < PASS: bt after finishing from call dummy breakpoint
  < PASS: finish after stop in call dummy preserves register contents
  < PASS: back at main after return from call dummy breakpoint
  < PASS: return after stop in call dummy preserves register contents

Looks pretty subsetty to me.  Most of the differences are additions
to callfuncs.exp after callfwmall.exp was forked.

Somewhere we do need one test that builds an executable that does
not have malloc and then calls a function with implicit allocation --
to check that the error mechanism works properly.

> If that's the case, I think callfwmall.exp ought to go away.

I'm willing to file such a bug report.  Any objections?

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

> There are a number of platforms which pass these tests, but only
> because malloc() is sneaks in because it's required by the dynamic
> linker.  If HPUX passes for a similar reason, this is cheating.  OTOH,
> if the HPUX port uses some other mechanism entirely, it might be a
> good idea for us to adapt this mechanism so that other targets can
> use it too.

I've got hpux scars all over my body which say that hpux 10.20 native
calls malloc() to do this.

I grepped around for "allocate_space_in_inferior" and it looks like the
malloc() call is the single hardwired implementation for every platform.
If that call doesn't work, gdb doesn't get the memory.

Forget the test script.  What should gdb do if:

  . I am on a platform with no malloc()
  . I type: print strlen("foo")

Should gdb have a target-specific mechanism to try?  For an embedded
target, it could have a scratch area which it manages itself.

And if there is no mechanism available, what should gdb print?

Michael

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Kevin Buettner]

On Feb 14,  2:17pm, Michael Elizabeth Chastain wrote:

> I grepped around for "allocate_space_in_inferior" and it looks like the
> malloc() call is the single hardwired implementation for every platform.
> If that call doesn't work, gdb doesn't get the memory.
> 
> Forget the test script.  What should gdb do if:
> 
>   . I am on a platform with no malloc()
>   . I type: print strlen("foo")

I think the present behavior is acceptable.  It looks for malloc()
anyway to see if it has snuck in via some other means; if it can't
find it, it prints out a message to that effect.

> Should gdb have a target-specific mechanism to try?  For an embedded
> target, it could have a scratch area which it manages itself.

For specific targets, this could no doubt be done, but maintaining it
would be a nightmare.

I don't see any point to adding this kind of complexity to gdb.  If
you're debugging an embedded program where you need to be able to do
``print strlen("foo")'' (or perhaps something more interesting), it's
easy to add a dummy call to malloc() somewhere in your application
code so that you'll be able to do it.

> And if there is no mechanism available, what should gdb print?

Again, I think the present behavior is acceptable.

So...  what should become of callfwmall.exp?  As I recall, this test
is identical to another test (callfuncs.exp) except that it simply
lacks a call to malloc(), right?

If that's the case, I think callfwmall.exp ought to go away.  There's
no point in running the same tests twice.  I just took a quick look
and the diffs between callfwmall.exp / callfuncs.exp and callfwmall.c
/ callfuncs.c was rather larger than I expected.  Someone will have to
examine these differences carefully to make sure that the
callfuncs.exp tests are a superset of the callfwmall.exp tests.

Kevin

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

> But how is it possible that GDB needs malloc() when the target does not
> have it?

(gdb) print strlen("foo")

GDB needs some mechanism to grab scratch memory in the target.
malloc() is the only mechanism that it has.

Michael

  /* gdb/valops.c */
  /* Allocate NBYTES of space in the inferior using the inferior's malloc
     and return a value that is a pointer to the allocated space. */

  value_ptr
  value_allocate_space_in_inferior (int len)
  {
    value_ptr blocklen;
    register value_ptr val = find_function_in_inferior ("malloc");

    blocklen = value_from_longest (builtin_type_int, (LONGEST) len);
    val = call_function_by_hand (val, 1, &blocklen);
    if (value_logical_not (val))
      {
	if (!target_has_execution)
	  error ("No memory available to program now: you need to start the target first");
	else
	  error ("No memory available to program: call to malloc failed");
      }
    return val;
  }

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Elizabeth Chastain]

Hi Keith,

The idea looks good, but I see an implementation bug.  On a native
platform with shared libraries, "p malloc" fails because shared library
symbols are not available until the program starts running.

I'm seeing this on Red Hat Linux 7 native, FSF cvs gcc dated 2001-02-12,
FSF cvs gdb dated 2001-02-12 with some patches applied.

Can you move your "p malloc" test after the call to "runto_main"?

Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"

===

spawn /vittone/fsf/2001-02-12/gehman/build-src-native/gdb/testsuite/../../gdb/gdb -nw -nx ^M
GNU gdb 5.0^M
Copyright 2001 Free Software Foundation, Inc.^M
GDB is free software, covered by the GNU General Public License, and you are^M
welcome to change it and/or distribute copies of it under certain conditions.^M
Type "show copying" to see the conditions.^M
There is absolutely no warranty for GDB.  Type "show warranty" for details.^M
This GDB was configured as "i686-pc-linux-gnu".^M
(gdb) set height 0^M
(gdb) set width 0^M
(gdb) dir^M
Reinitialize source path to empty? (y or n) y^M
Source directories searched: $cdir:$cwd^M
(gdb) dir /vittone/fsf/2001-02-12/source-src/gdb/testsuite/gdb.base^M
Source directories searched: /vittone/fsf/2001-02-12/source-src/gdb/testsuite/gdb.base:$cdir:$cwd^M
(gdb) file /vittone/fsf/2001-02-12/gehman/build-src-native/gdb/testsuite/gdb.bas ^Me/callfwmall^M
Reading symbols from /vittone/fsf/2001-02-12/gehman/build-src-native/gdb/testsuite/gdb.base/callfwmall...done.^M
(gdb) set print sevenbit-strings^M
(gdb) PASS: gdb.base/callfwmall.exp: set print sevenbit-strings
set print address off^M
(gdb) PASS: gdb.base/callfwmall.exp: set print address off
set width 0^M
(gdb) PASS: gdb.base/callfwmall.exp: set width 0
p malloc^M
No symbol "malloc" in current context.^M

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Keith Seitz]

On Wed, 14 Feb 2001, Michael Elizabeth Chastain wrote:

> The idea looks good, but I see an implementation bug.  On a native
> platform with shared libraries, "p malloc" fails because shared library
> symbols are not available until the program starts running.
> 
> I'm seeing this on Red Hat Linux 7 native, FSF cvs gcc dated 2001-02-12,
> FSF cvs gdb dated 2001-02-12 with some patches applied.
> 
> Can you move your "p malloc" test after the call to "runto_main"?

Doh! Good catch.

Keith

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Fernando Nasser]

Michael Elizabeth Chastain wrote:
> 
> Hi Keith,
> 
> The idea looks good, but I see an implementation bug.  On a native
> platform with shared libraries, "p malloc" fails because shared library
> symbols are not available until the program starts running.
> 
> I'm seeing this on Red Hat Linux 7 native, FSF cvs gcc dated 2001-02-12,
> FSF cvs gdb dated 2001-02-12 with some patches applied.
> 
> Can you move your "p malloc" test after the call to "runto_main"?
> 

Good point.

Thanks Michael.


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Fernando Nasser]

Sounds reasonable.  Check it in (assuming you have already added yourself to the write after approval list).

Fernando

Keith Seitz wrote:
> 
> (let me try to get the right mailing list this time :-)
> 
> Hi,
> 
> The problem: When doing an inferior function call with a
> struct/array/string argument (aka 'print foo({2,1})' or 'print
> foo("bar")', gdb requires "malloc" in the executable... This leads to
> some trivial testsuite failures.
> 
> 2001-02-13  Keith Seitz  <kseitz@nwlink.com>
> 
>         * gdb.base/callfwmall.exp: Check for the existence of
>         malloc.
>         (do_function_calls): Do not do an inferior function
>         call which requires malloc if malloc doesn't exist.
> 
> Patch:
> Index: testsuite/gdb.base/callfwmall.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.base/callfwmall.exp,v
> retrieving revision 1.1.1.3
> diff -p -r1.1.1.3 callfwmall.exp
> *** testsuite/gdb.base/callfwmall.exp   1999/09/09 00:00:21     1.1.1.3
> --- testsuite/gdb.base/callfwmall.exp   2001/02/14 01:11:52
> *************** proc set_lang_c {} {
> *** 99,105 ****
>   proc do_function_calls {} {
>       global prototypes
>       global gcc_compiled
> !     global gdb_prompt
> 
>       # We need to up this because this can be really slow on some boards.
>       set timeout 60;
> --- 99,105 ----
>   proc do_function_calls {} {
>       global prototypes
>       global gcc_compiled
> !     global gdb_prompt have_malloc_p
> 
>       # We need to up this because this can be really slow on some boards.
>       set timeout 60;
> *************** proc do_function_calls {} {
> *** 169,183 ****
> 
>       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"
> 
>       gdb_test "p doubleit(4)" " = 8"
>       gdb_test "p add(4,5)" " = 9"
> --- 169,187 ----
> 
>       gdb_test "p t_string_values(string_val2,string_val1)" " = 0"
>       gdb_test "p t_string_values(string_val1,string_val2)" " = 1"
> !     if {$have_malloc_p} {
> !       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"
> !     if {$have_malloc_p} {
> !       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"
> *************** proc do_function_calls {} {
> *** 222,231 ****
>       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"
>       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'" \
> --- 226,237 ----
>       gdb_test "p t_enum_value2(enum_val2)" " = 1"
>       gdb_test "p t_enum_value2(enum_val1)" " = 0"
> 
> !     if {$have_malloc_p} {
> !       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'" \
> *************** gdb_load ${binfile}
> *** 255,260 ****
> --- 261,273 ----
>   gdb_test "set print sevenbit-strings" ""
>   gdb_test "set print address off" ""
>   gdb_test "set width 0" ""
> +
> + # Note whether malloc exists
> + set have_malloc_p 1
> + send_gdb "p malloc\n"
> + gdb_expect {
> +   "No symbol \"malloc\""  { set have_malloc_p 0 }
> + }
> 
>   if { $hp_aCC_compiler } {
>       # Do not set language explicitly to 'C'.  This will cause aCC

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Snyder]

Fernando Nasser wrote:
> 
> Sounds reasonable.  Check it in (assuming you have already added yourself to the write after approval list).

Hold on -- aren't you defeating the purpose of this test?
The test was added by HP precisely because these calls
fail when malloc isn't included in the target program.
The test is a duplicate of callfuncs.exp, except that it
doesn't link malloc.


> 
> Fernando
> 
> Keith Seitz wrote:
> >
> > (let me try to get the right mailing list this time :-)
> >
> > Hi,
> >
> > The problem: When doing an inferior function call with a
> > struct/array/string argument (aka 'print foo({2,1})' or 'print
> > foo("bar")', gdb requires "malloc" in the executable... This leads to
> > some trivial testsuite failures.
> >
> > 2001-02-13  Keith Seitz  <kseitz@nwlink.com>
> >
> >         * gdb.base/callfwmall.exp: Check for the existence of
> >         malloc.
> >         (do_function_calls): Do not do an inferior function
> >         call which requires malloc if malloc doesn't exist.
> >
> > Patch:
> > Index: testsuite/gdb.base/callfwmall.exp
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/testsuite/gdb.base/callfwmall.exp,v
> > retrieving revision 1.1.1.3
> > diff -p -r1.1.1.3 callfwmall.exp
> > *** testsuite/gdb.base/callfwmall.exp   1999/09/09 00:00:21     1.1.1.3
> > --- testsuite/gdb.base/callfwmall.exp   2001/02/14 01:11:52
> > *************** proc set_lang_c {} {
> > *** 99,105 ****
> >   proc do_function_calls {} {
> >       global prototypes
> >       global gcc_compiled
> > !     global gdb_prompt
> >
> >       # We need to up this because this can be really slow on some boards.
> >       set timeout 60;
> > --- 99,105 ----
> >   proc do_function_calls {} {
> >       global prototypes
> >       global gcc_compiled
> > !     global gdb_prompt have_malloc_p
> >
> >       # We need to up this because this can be really slow on some boards.
> >       set timeout 60;
> > *************** proc do_function_calls {} {
> > *** 169,183 ****
> >
> >       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"
> >
> >       gdb_test "p doubleit(4)" " = 8"
> >       gdb_test "p add(4,5)" " = 9"
> > --- 169,187 ----
> >
> >       gdb_test "p t_string_values(string_val2,string_val1)" " = 0"
> >       gdb_test "p t_string_values(string_val1,string_val2)" " = 1"
> > !     if {$have_malloc_p} {
> > !       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"
> > !     if {$have_malloc_p} {
> > !       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"
> > *************** proc do_function_calls {} {
> > *** 222,231 ****
> >       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"
> >       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'" \
> > --- 226,237 ----
> >       gdb_test "p t_enum_value2(enum_val2)" " = 1"
> >       gdb_test "p t_enum_value2(enum_val1)" " = 0"
> >
> > !     if {$have_malloc_p} {
> > !       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'" \
> > *************** gdb_load ${binfile}
> > *** 255,260 ****
> > --- 261,273 ----
> >   gdb_test "set print sevenbit-strings" ""
> >   gdb_test "set print address off" ""
> >   gdb_test "set width 0" ""
> > +
> > + # Note whether malloc exists
> > + set have_malloc_p 1
> > + send_gdb "p malloc\n"
> > + gdb_expect {
> > +   "No symbol \"malloc\""  { set have_malloc_p 0 }
> > + }
> >
> >   if { $hp_aCC_compiler } {
> >       # Do not set language explicitly to 'C'.  This will cause aCC
> 
> --
> Fernando Nasser
> Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Kevin Buettner]

On Feb 14, 12:51pm, Michael Snyder wrote:

> Fernando Nasser wrote:
> > 
> > Sounds reasonable.  Check it in (assuming you have already added yourself to the write after approval list).
> 
> Hold on -- aren't you defeating the purpose of this test?
> The test was added by HP precisely because these calls
> fail when malloc isn't included in the target program.
> The test is a duplicate of callfuncs.exp, except that it
> doesn't link malloc.

I sort of agree with Michael.  (I almost posted a similar remark.)

OTOH, given that GDB's mechanism for performing these tests is to
use malloc(), I'm not sure how these are supposed to succeed.  (As
someone else pointed out, they do succeed on some platforms because
malloc() sneaks into the picture through the dynamic loader.)

Does anyone know of any host/target combinations which manage to pass
these tests without using malloc()?

If there are some, or if this is a feature that we expect to work (in
the fullness of time), then perhaps the FAILing tests ought to be
XFAIL'd.  Otherwise, I think Keith's patch is reasonable.

Kevin

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Elena Zannoni]

Kevin Buettner writes:
 > On Feb 14, 12:51pm, Michael Snyder wrote:
 > 
 > > Fernando Nasser wrote:
 > > > 
 > > > Sounds reasonable.  Check it in (assuming you have already added yourself to the write after approval list).
 > > 
 > > Hold on -- aren't you defeating the purpose of this test?
 > > The test was added by HP precisely because these calls
 > > fail when malloc isn't included in the target program.
 > > The test is a duplicate of callfuncs.exp, except that it
 > > doesn't link malloc.
 > 
 > I sort of agree with Michael.  (I almost posted a similar remark.)
 > 

Yes, in callfwmall.c there is this comment:
/* Support program for testing gdb's ability to call functions
   in an inferior which doesn't itself call malloc, pass appropriate
   arguments to those functions, and get the returned result. */


 > OTOH, given that GDB's mechanism for performing these tests is to
 > use malloc(), I'm not sure how these are supposed to succeed.  (As
 > someone else pointed out, they do succeed on some platforms because
 > malloc() sneaks into the picture through the dynamic loader.)
 > 
 > Does anyone know of any host/target combinations which manage to pass
 > these tests without using malloc()?

HPUX should pass. That's why those tests were added in the first
place, I think.

 > 
 > If there are some, or if this is a feature that we expect to work (in
 > the fullness of time), then perhaps the FAILing tests ought to be
 > XFAIL'd.  Otherwise, I think Keith's patch is reasonable.
 > 

Maybe this file should be moved to the gdb.hp directory. But I think
there must have been a reason for which it wasn't put there in the
first place. So I would think it used to pass at some point.
I don't see anything interesting in the ChangeLog.

 > Kevin
 > 

Elena

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Kevin Buettner]

On Feb 14,  4:28pm, Elena Zannoni wrote:

>  > OTOH, given that GDB's mechanism for performing these tests is to
>  > use malloc(), I'm not sure how these are supposed to succeed.  (As
>  > someone else pointed out, they do succeed on some platforms because
>  > malloc() sneaks into the picture through the dynamic loader.)
>  > 
>  > Does anyone know of any host/target combinations which manage to pass
>  > these tests without using malloc()?
> 
> HPUX should pass. That's why those tests were added in the first
> place, I think.

Do you have any idea how this functionality is implemented?

There are a number of platforms which pass these tests, but only
because malloc() is sneaks in because it's required by the dynamic
linker.  If HPUX passes for a similar reason, this is cheating.  OTOH,
if the HPUX port uses some other mechanism entirely, it might be a
good idea for us to adapt this mechanism so that other targets can
use it too.

Kevin

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Elena Zannoni]

Kevin Buettner writes:
 > On Feb 14,  4:28pm, Elena Zannoni wrote:
 > 
 > >  > OTOH, given that GDB's mechanism for performing these tests is to
 > >  > use malloc(), I'm not sure how these are supposed to succeed.  (As
 > >  > someone else pointed out, they do succeed on some platforms because
 > >  > malloc() sneaks into the picture through the dynamic loader.)
 > >  > 
 > >  > Does anyone know of any host/target combinations which manage to pass
 > >  > these tests without using malloc()?
 > > 
 > > HPUX should pass. That's why those tests were added in the first
 > > place, I think.
 > 
 > Do you have any idea how this functionality is implemented?
 > 
 > There are a number of platforms which pass these tests, but only
 > because malloc() is sneaks in because it's required by the dynamic
 > linker.  If HPUX passes for a similar reason, this is cheating.  OTOH,
 > if the HPUX port uses some other mechanism entirely, it might be a
 > good idea for us to adapt this mechanism so that other targets can
 > use it too.
 > 

I think it looked up the malloc function using some hp linker specific
functions. Looking at hppa-tdep.c it seems like the code has changed,
so I am not sure anymore. But yes, I think it would fall into the
'cheating' category. Malloc is there. You just don't need to have a
call to it in the inferior.

 > Kevin
 > 

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Andrew Cagney]

Kevin Buettner wrote:

> There are a number of platforms which pass these tests, but only
> because malloc() is sneaks in because it's required by the dynamic
> linker.  If HPUX passes for a similar reason, this is cheating.  OTOH,
> if the HPUX port uses some other mechanism entirely, it might be a
> good idea for us to adapt this mechanism so that other targets can
> use it too.

I'd describe it as bending the truth rather than cheating.

To the best of my knolwedge, the objective of the test is to ensure that
GDB can still handle code like:

	print strlen ("foo")

when the target doesn't link in malloc().  Well, to be more precice, the
target doesn't explicitly link in malloc(). GDB is forced to grub around
in shared library information (or, gasp, the target rom) to obtain a
malloc() function.

As far as I can tell, the proposed change defeats this test.  Yes, there
are targets that really don't have malloc() and on those targets the
test should probably xfailed.  However, on any target with a shared
library() I think it should be allowed to run.

How many targets currently fail the test?

	Andrew

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Fernando Nasser]

Andrew Cagney wrote:
> 
> To the best of my knolwedge, the objective of the test is to ensure that
> GDB can still handle code like:
> 
>         print strlen ("foo")
> 
> when the target doesn't link in malloc().  Well, to be more precice, the
> target doesn't explicitly link in malloc(). GDB is forced to grub around
> in shared library information (or, gasp, the target rom) to obtain a
> malloc() function.
> 

Should we test GDB's ability to find malloc() from the shared libraries
per se?  The little test code added by Keith and revamped by Michael
could be used to do that.


> As far as I can tell, the proposed change defeats this test.  Yes, there
> are targets that really don't have malloc() and on those targets the
> test should probably xfailed.  However, on any target with a shared
> library() I think it should be allowed to run.
> 

But then it is equivalent to callfuncs.exp, which has already run.



> How many targets currently fail the test?
> 
>         Andrew

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Andrew Cagney]

> > As far as I can tell, the proposed change defeats this test.  Yes, there
> > are targets that really don't have malloc() and on those targets the
> > test should probably xfailed.  However, on any target with a shared
> > library() I think it should be allowed to run.
> >
> 
> But then it is equivalent to callfuncs.exp, which has already run.

It is subtly different.

callfuncs.exp has an explictly linked malloc and the malloc
run-time-link is forced (using the next over the malloc() call). 
callfwamll doesn't have the explicit malloc and doesn't force final
linkage of malloc().  GDB when it goes to call malloc() indirectly is
forcing that linkage indirectly.

Subtle I know.  I suspect the test as it currently stands is over kill
though.

	Andrew

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Snyder]

Elena Zannoni wrote:
> 
> Kevin Buettner writes:
>  > On Feb 14, 12:51pm, Michael Snyder wrote:
>  >
>  > > Fernando Nasser wrote:
>  > > >
>  > > > Sounds reasonable.  Check it in (assuming you have already added yourself to the write after approval list).
>  > >
>  > > Hold on -- aren't you defeating the purpose of this test?
>  > > The test was added by HP precisely because these calls
>  > > fail when malloc isn't included in the target program.
>  > > The test is a duplicate of callfuncs.exp, except that it
>  > > doesn't link malloc.
>  >
>  > I sort of agree with Michael.  (I almost posted a similar remark.)
>  >
> 
> Yes, in callfwmall.c there is this comment:
> /* Support program for testing gdb's ability to call functions
>    in an inferior which doesn't itself call malloc, pass appropriate
>    arguments to those functions, and get the returned result. */
> 
>  > OTOH, given that GDB's mechanism for performing these tests is to
>  > use malloc(), I'm not sure how these are supposed to succeed.  (As
>  > someone else pointed out, they do succeed on some platforms because
>  > malloc() sneaks into the picture through the dynamic loader.)
>  >
>  > Does anyone know of any host/target combinations which manage to pass
>  > these tests without using malloc()?
> 
> HPUX should pass. That's why those tests were added in the first
> place, I think.
> 
>  >
>  > If there are some, or if this is a feature that we expect to work (in
>  > the fullness of time), then perhaps the FAILing tests ought to be
>  > XFAIL'd.  Otherwise, I think Keith's patch is reasonable.
>  >
> 
> Maybe this file should be moved to the gdb.hp directory. But I think
> there must have been a reason for which it wasn't put there in the
> first place. So I would think it used to pass at some point.
> I don't see anything interesting in the ChangeLog.

There was no gdb.hp directory at the time.

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Elena Zannoni]

Michael Snyder writes:
 > Elena Zannoni wrote:
 > > 
 > > Kevin Buettner writes:
 > >  > On Feb 14, 12:51pm, Michael Snyder wrote:
 > >  >
 > >  > > Fernando Nasser wrote:
 > >  > > >
 > >  > > > Sounds reasonable.  Check it in (assuming you have already added yourself to the write after approval list).
 > >  > >
 > >  > > Hold on -- aren't you defeating the purpose of this test?
 > >  > > The test was added by HP precisely because these calls
 > >  > > fail when malloc isn't included in the target program.
 > >  > > The test is a duplicate of callfuncs.exp, except that it
 > >  > > doesn't link malloc.
 > >  >
 > >  > I sort of agree with Michael.  (I almost posted a similar remark.)
 > >  >
 > > 
 > > Yes, in callfwmall.c there is this comment:
 > > /* Support program for testing gdb's ability to call functions
 > >    in an inferior which doesn't itself call malloc, pass appropriate
 > >    arguments to those functions, and get the returned result. */
 > > 
 > >  > OTOH, given that GDB's mechanism for performing these tests is to
 > >  > use malloc(), I'm not sure how these are supposed to succeed.  (As
 > >  > someone else pointed out, they do succeed on some platforms because
 > >  > malloc() sneaks into the picture through the dynamic loader.)
 > >  >
 > >  > Does anyone know of any host/target combinations which manage to pass
 > >  > these tests without using malloc()?
 > > 
 > > HPUX should pass. That's why those tests were added in the first
 > > place, I think.
 > > 
 > >  >
 > >  > If there are some, or if this is a feature that we expect to work (in
 > >  > the fullness of time), then perhaps the FAILing tests ought to be
 > >  > XFAIL'd.  Otherwise, I think Keith's patch is reasonable.
 > >  >
 > > 
 > > Maybe this file should be moved to the gdb.hp directory. But I think
 > > there must have been a reason for which it wasn't put there in the
 > > first place. So I would think it used to pass at some point.
 > > I don't see anything interesting in the ChangeLog.
 > 
 > There was no gdb.hp directory at the time.
 > 

True, but I remember Stan going through and getting files moved around.
Was this file just forgotten?
Stan, do you recall anything about this?


Elena

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Snyder]

Kevin Buettner wrote:
> 
> On Feb 14, 12:51pm, Michael Snyder wrote:
> 
> > Fernando Nasser wrote:
> > >
> > > Sounds reasonable.  Check it in (assuming you have already added yourself to the write after approval list).
> >
> > Hold on -- aren't you defeating the purpose of this test?
> > The test was added by HP precisely because these calls
> > fail when malloc isn't included in the target program.
> > The test is a duplicate of callfuncs.exp, except that it
> > doesn't link malloc.
> 
> I sort of agree with Michael.  (I almost posted a similar remark.)
> 
> OTOH, given that GDB's mechanism for performing these tests is to
> use malloc(), I'm not sure how these are supposed to succeed.  (As
> someone else pointed out, they do succeed on some platforms because
> malloc() sneaks into the picture through the dynamic loader.)
> 
> Does anyone know of any host/target combinations which manage to pass
> these tests without using malloc()?

I would assume that the tests pass on HPUX, else HP would not
have added them.  But I don't know if they bothered to ascertain
whether the tests could be made to pass on any other platform.

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Keith Seitz]

> Fernando Nasser wrote:
> > 
> > Sounds reasonable.  Check it in (assuming you have already added yourself to the write after approval list).
> 
> Hold on -- aren't you defeating the purpose of this test?
> The test was added by HP precisely because these calls
> fail when malloc isn't included in the target program.
> The test is a duplicate of callfuncs.exp, except that it
> doesn't link malloc.

So the purpose of the test is to FAIL? What's the passing criteria?

Keith

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Fernando Nasser]

Michael Snyder wrote:
> 
> Fernando Nasser wrote:
> >
> > Sounds reasonable.  Check it in (assuming you have already added yourself to the write after approval list).
> 
> Hold on -- aren't you defeating the purpose of this test?
> The test was added by HP precisely because these calls
> fail when malloc isn't included in the target program.
> The test is a duplicate of callfuncs.exp, except that it
> doesn't link malloc.
> 

This is true.

# SAME tests as in callfuncs.exp but here the inferior program does not
# call malloc.

But the idea was:

/* Support program for testing gdb's ability to call functions
   in an inferior which doesn't itself call malloc, pass appropriate
   arguments to those functions, and get the returned result. */

It is the ability of GDB calling a function that does not itself call malloc() that is being tested.  Why this is important?  I don't know.

Keith detected that GDB needs malloc() itself to call functions in the inferior. This may not be true for all targets I guess.

But how is it possible that GDB needs malloc() when the target does not have it?

Something is really fishy here.


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Stan Shebs]

Fernando Nasser wrote:
> 
> But how is it possible that GDB needs malloc() when the target does not have it?

(gdb) p strlen("foobar")

The string itself needs to be in the target's memory, so you can give
the function a pointer to it.  malloc() is a convenient default way
to acquire the space, then GDB copies in the string's contents.

Stan

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Fernando Nasser]

Stan Shebs wrote:
> 
> Fernando Nasser wrote:
> >
> > But how is it possible that GDB needs malloc() when the target does not have it?
> 
> (gdb) p strlen("foobar")
> 
> The string itself needs to be in the target's memory, so you can give
> the function a pointer to it.  malloc() is a convenient default way
> to acquire the space, then GDB copies in the string's contents.
> 

OK.  But it makes no sense trying it on a target that does not have malloc().

For such targets, the inferior call attempt should fail when strings are passed as arguments with some meaningful message (maybe that is what happens, I haven't seem the gdb.log).

Do you happen to know why was it important to test with a test program that does not call malloc() itself?


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] Assuming malloc exists in callfwmall.exp

[Michael Snyder]

Stan Shebs wrote:
> 
> Fernando Nasser wrote:
> >
> > But how is it possible that GDB needs malloc() when the target does not have it?
> 
> (gdb) p strlen("foobar")
> 
> The string itself needs to be in the target's memory, so you can give
> the function a pointer to it.  malloc() is a convenient default way
> to acquire the space, then GDB copies in the string's contents.

That's exactly why the source code for the test (callfuncs)
has a superfluous call to malloc, and exactly why this test
(callfwmall) removes the superfluous malloc call.

By the way, the name "callfwmall" stands for
"callfuncs without malloc".

Michael