Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Elizabeth Chastain <chastain@cygnus.com>
To: chastain@cygnus.com, ezannoni@cygnus.com, kevinb@cygnus.com
Cc: fnasser@cygnus.com, gdb-patches@sources.redhat.com,
	keiths@cygnus.com, msnyder@cygnus.com
Subject: Re: [RFA] Assuming malloc exists in callfwmall.exp
Date: Wed, 14 Feb 2001 15:12:00 -0000	[thread overview]
Message-ID: <200102142312.PAA30027@bosch.cygnus.com> (raw)

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


             reply	other threads:[~2001-02-14 15:12 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-14 15:12 Michael Elizabeth Chastain [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-02-16  9:48 Michael Elizabeth Chastain
2001-02-16  8:55 Michael Elizabeth Chastain
2001-02-16  8:41 Michael Elizabeth Chastain
2001-02-15 19:05 Michael Elizabeth Chastain
2001-02-16  8:36 ` Jim Blandy
2001-02-15 12:58 Michael Elizabeth Chastain
2001-02-15 12:56 Michael Elizabeth Chastain
2001-02-16  8:51 ` Jim Blandy
2001-02-15 12:30 Michael Elizabeth Chastain
2001-02-15 12:48 ` Fernando Nasser
2001-02-15 12:16 Michael Elizabeth Chastain
2001-02-15 23:36 ` Eli Zaretskii
2001-02-15 12:08 Michael Elizabeth Chastain
2001-02-15 12:41 ` Fernando Nasser
2001-02-15  9:00 Michael Elizabeth Chastain
2001-02-15 11:53 ` Fernando Nasser
2001-02-15 11:56 ` Jim Blandy
2001-02-15  8:30 Michael Elizabeth Chastain
2001-02-15  8:45 ` Fernando Nasser
2001-02-15  7:54 Michael Elizabeth Chastain
2001-02-15  8:09 ` Fernando Nasser
2001-02-15  7:09 Michael Elizabeth Chastain
2001-02-15  7:06 Michael Elizabeth Chastain
2001-02-15  7:32 ` Fernando Nasser
2001-02-14 19:27 Michael Elizabeth Chastain
2001-02-15  1:06 ` Fernando Nasser
2001-02-15  1:22   ` Fernando Nasser
2001-02-15  6:54     ` Kevin Buettner
2001-02-14 18:35 Michael Elizabeth Chastain
2001-02-14 16:29 Michael Elizabeth Chastain
2001-02-14 18:17 ` Andrew Cagney
2001-02-14 14:17 Michael Elizabeth Chastain
2001-02-14 14:37 ` Kevin Buettner
2001-02-14 13:41 Michael Elizabeth Chastain
2001-02-14  9:06 Michael Elizabeth Chastain
2001-02-14  9:07 ` Keith Seitz
2001-02-14  9:11 ` Fernando Nasser
     [not found] <Pine.SOL.3.91.1010214082014.13194C-100000@ryobi.cygnus.com>
2001-02-14  9:02 ` Fernando Nasser
2001-02-14 12:52   ` Michael Snyder
2001-02-14 13:10     ` Kevin Buettner
2001-02-14 13:28       ` Elena Zannoni
2001-02-14 13:41         ` Kevin Buettner
2001-02-14 14:00           ` Elena Zannoni
2001-02-14 20:13           ` Andrew Cagney
2001-02-15  1:14             ` Fernando Nasser
2001-02-15 10:34               ` Andrew Cagney
2001-02-14 14:33         ` Michael Snyder
2001-02-14 14:49           ` Elena Zannoni
2001-02-14 14:34       ` Michael Snyder
2001-02-14 13:12     ` Keith Seitz
2001-02-14 13:20     ` Fernando Nasser
2001-02-14 13:37       ` Stan Shebs
2001-02-14 13:46         ` Fernando Nasser
2001-02-14 14:35         ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200102142312.PAA30027@bosch.cygnus.com \
    --to=chastain@cygnus.com \
    --cc=ezannoni@cygnus.com \
    --cc=fnasser@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=keiths@cygnus.com \
    --cc=kevinb@cygnus.com \
    --cc=msnyder@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox