[RFA] detect inferior exit in call_function_by_hand

Doug Evans dje@google.com
Fri Nov 14 13:51:00 GMT 2008


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.



More information about the Gdb-patches mailing list