Re: [PATCH,v2] Make language setting tests more robust

Luis Machado
2017-02-06T18:04:19Z

On 02/06/2017 10:50 AM, Pedro Alves wrote:
> On 02/06/2017 02:54 PM, Luis Machado wrote:
>>
>> The story here is that i noticed 3 tests with such a problem:
>>
>> FAIL: gdb.compile/compile-ifunc.exp: nodebug: set language c
>> FAIL: gdb.dwarf2/data-loc.exp: set language ada
>> FAIL: gdb.dwarf2/dynarr-ptr.exp: set language ada
>>
>> And my build had a glibc with debugging symbols and sources, therefore
>> GDB had set the initial language to asm before main.
>
> There's a comment about that in gdb.compile/compile-ifunc.exp:
>
> # This binary has no debug information, so force the language to C in case
> # GDB happened to see real asm code when it stopped at the entry point
> # when talking to a remote target, like gdbserver. This guarantees the
> # feature check below will work.
> gdb_test_no_output "set language c" ""
>
> So the question is, why did the gdb_test_no_output work back then,
> and doesn't now?
>

I can't confirm it worked before since i haven't looked at this
particular setup then.

> In top.c:check_frame_language_change()
> [...]
> if (has_stack_frames ())
> {
> enum language flang;
>
> flang = get_frame_language (frame);
> if (!warned
> && flang != language_unknown
> && flang != current_language->la_language)
> {
> printf_filtered ("%s\n", lang_frame_mismatch_warn);
> warned = 1;
> }
>
> what does get_frame_language return? Isn't it returning
> language_unknown for you? Why not?
>

That returns language_asm for me. Supposedly because gdb has seen asm
from glibc and then sticked with it when it reached the test program's
main. And the program has no debug info.

>> FAIL: gdb.dwarf2/data-loc.exp: set language ada
>> FAIL: gdb.dwarf2/dynarr-ptr.exp: set language ada

Same as above, language_asm.

Maybe gdb should've switched to language_unknown when it reached main
for this/these particular cases?

The logic to complain about a mismatch of language between the frame and
the user selection seems sane.