This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Assuming malloc exists in callfwmall.exp
- To: chastain at cygnus dot com, ezannoni at cygnus dot com, kevinb at cygnus dot com
- Subject: Re: [RFA] Assuming malloc exists in callfwmall.exp
- From: Michael Elizabeth Chastain <chastain at cygnus dot com>
- Date: Wed, 14 Feb 2001 15:12:48 -0800
- Cc: fnasser at cygnus dot com, gdb-patches at sources dot redhat dot com, keiths at cygnus dot com, msnyder at cygnus dot com
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