[PATCH,v2] Make language setting tests more robust
Luis Machado
lgustavo@codesourcery.com
Mon Feb 6 19:56:00 GMT 2017
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.
More information about the Gdb-patches
mailing list