From: Doug Evans <dje@google.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA] detect inferior exit in call_function_by_hand
Date: Fri, 14 Nov 2008 13:51:00 -0000 [thread overview]
Message-ID: <e394668d0811132303v63d82a6fv39bc0bc533087870@mail.gmail.com> (raw)
In-Reply-To: <20081114005333.GC12802@adacore.com>
On Thu, Nov 13, 2008 at 4:53 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> + send_gdb "set language c\n"
>> + gdb_expect {
>> + -re ".*$gdb_prompt $" {}
>> + timeout { fail "set language c (timeout)" ; return 0; }
>> + }
>> +
>> + send_gdb "show language\n"
>> + gdb_expect {
>> + -re ".* source language is \"c\".*$gdb_prompt $" {
>> + pass "set language to \"c\""
>> + return 1
>> + }
>> + -re ".*$gdb_prompt $" {
>> + fail "setting language to \"c\""
>> + return 0
>> + }
>> + timeout {
>> + fail "can't show language (timeout)"
>> + return 0
>> + }
>> + }
>
> Generally speaking, we try to avoid send_gdb/gdb_expect, and use
> gdb_test_multiple. I realize that you probably inherited this
> through copy/paste... In any case, I don't think it will necessary
> to rewrite the above, because, Like Pedro, I don't think you need
> the set lang c. The only time when I had to explicitly set the language
> is after attaching to a program - you never know where you might end up,
> and sometimes you find your way into asm frames, for instance. I propose
> you remove this part entirely. That should simplify your testcase and
> it's easy enough to put it back if we discover a case where it's
> really needed.
>
>> +if { ![set_lang_c] } {
>> + gdb_suppress_tests;
>> +} else {
>> + if { ![runto_main] } {
>> + gdb_suppress_tests;
>> + }
>
> We don't use gdb_suppress_tests anymore. As far as I know, the usual
> way of doing things is to log a FAIL and then return. For instance:
>
> if ![runto_main] then {
> fail "Can't run to main"
> return 0
> }
In past lives, I've often found it useful to never introduce fails
that don't also have passes - it makes regression reports cleaner:
otherwise tests that failed the previous time but now pass disappear
and the test count has gone down leading one to wonder if there's a
testsuite issue. In this case it doesn't matter as the gdb testsuite
is all over the map so I'm happy to just go with the flow.
prev parent reply other threads:[~2008-11-14 7:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-12 8:32 Doug Evans
2008-11-12 8:33 ` Pedro Alves
2008-11-14 11:43 ` Joel Brobecker
2008-11-14 13:51 ` Doug Evans [this message]
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=e394668d0811132303v63d82a6fv39bc0bc533087870@mail.gmail.com \
--to=dje@google.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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