Re: [RFA] detect inferior exit in call_function_by_hand

[Doug Evans <dje at google dot 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.