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

[Luis Machado <lgustavo@codesourcery.com>]

On 02/06/2017 12:24 PM, Pedro Alves wrote:
> On 02/06/2017 06:22 PM, Luis Machado wrote:
>> On 02/06/2017 12:08 PM, Pedro Alves wrote:
>>> On 02/06/2017 06:04 PM, Luis Machado wrote:
>>>
>>>> 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.
>>>
>>> No, I don't think that is why.  What sticks is "current_language", not
>>> the frame's language.
>>
>> True. gdb is still seeing asm for the frame with main though. But that
>> sounds like an expected outcome.
>
> Why?  Where is GDB retrieving that from?  Did you step through
> get_frame_language?

Ok, here's what i'm seeing so far. The current language is stuck in 
language_asm, even though the frame (frame of main) is supposed to be 
language_c (points to a C file, start_c.c).

The funny thing is that right after connecting to the remote target, if 
you "show language", it doesn't emit any warnings and it keeps seeing a 
previous .S file (from the entry point), therefore the frame's language 
is language_asm, matching current_language.

Attempting a backtrace shows the language mismatch warning, since the 
frame's language is then resolved to language_c (frame of main).

Maybe current_language is not being updated when it should (from 
language_asm to language_c)?

And there also seems to be a hiccup in the case where i can still see a 
frame pointing to the .S file, even though the current frame is the 
frame of main.

It may be a bug after all.