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

[Luis Machado <lgustavo at codesourcery dot 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.