Don't set initial language using previous language
Commit Message
Hi,
When language is set to auto, part of loading an executable is to update the
language accordingly. This is implemented by set_initial_language.
In case of a c++ executable without DW_AT_main_subprogram,
set_initial_language finds "main" in the minimal symbols, and does a lookup of
"main" in the symbol tables to determine the language of the symbol, and uses
that as initial language.
The symbol lookup is done using lookup_symbol which is a wrapper around
lookup_symbol_in_language, using the current language.
So, consider two c++ executables a.out and b.out, which we'll load one after
another. If we track the resulting lookup_symbol_in_language calls:
...
$ gdb -batch \
-ex "b lookup_symbol_in_language" \
-ex r -ex c -ex c \
--args gdb
...
we find that indeed lookup_symbol_in_language is called once using language_c, and
once using language_c_plus:
...
(gdb) file a.out
Reading symbols from a.out...
Breakpoint 1, lookup_symbol_in_language (name=0x5555568c2050 "main", \
block=0x0, domain=VAR_DOMAIN, lang=language_c, is_a_field_of_this=0x0) \
at ../../gdb/symtab.c:1905
1905 {
(gdb) file b.out
Load new symbol table from "b.out"? (y or n) y
Reading symbols from b.out...
Breakpoint 1, lookup_symbol_in_language (name=0x5555568c2030 "main", \
block=0x0, domain=VAR_DOMAIN, lang=language_cplus, is_a_field_of_this=0x0) \
at ../../gdb/symtab.c:1905
1905 {
(gdb)
...
It seems like a bad idea to have the previous language play a role
in determining the executable language.
Fix this by using lookup_symbol_in_language in set_initial_language with the
default language c as argument.
Tested on x86_64-linux.
OK for trunk?
Thanks,
- Tom
[gdb] Don't set initial language using previous language
gdb/ChangeLog:
2020-02-28 Tom de Vries <tdevries@suse.de>
* symfile.c (set_initial_language): Use default language for lookup.
---
gdb/symfile.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
Comments
>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
Tom> It seems like a bad idea to have the previous language play a role
Tom> in determining the executable language.
Does it make a difference in practice?
Tom> Fix this by using lookup_symbol_in_language in set_initial_language with the
Tom> default language c as argument.
Tom> Tested on x86_64-linux.
Tom> OK for trunk?
Yes, it seems fine to me. Thank you.
Tom
On 28-02-2020 16:04, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
>
> Tom> It seems like a bad idea to have the previous language play a role
> Tom> in determining the executable language.
>
> Does it make a difference in practice?
>
I don't know of a concrete case where it does.
> Tom> Fix this by using lookup_symbol_in_language in set_initial_language with the
> Tom> default language c as argument.
>
> Tom> Tested on x86_64-linux.
>
> Tom> OK for trunk?
>
> Yes, it seems fine to me. Thank you.
Ack, committed.
Thanks,
- Tom
@@ -1684,11 +1684,15 @@ set_initial_language (void)
if (language_mode == language_mode_manual)
return;
enum language lang = main_language ();
+ /* Make C the default language. */
+ enum language default_lang = language_c;
if (lang == language_unknown)
{
const char *name = main_name ();
- struct symbol *sym = lookup_symbol (name, NULL, VAR_DOMAIN, NULL).symbol;
+ struct symbol *sym
+ = lookup_symbol_in_language (name, NULL, VAR_DOMAIN, default_lang,
+ NULL).symbol;
if (sym != NULL)
lang = sym->language ();
@@ -1696,8 +1700,7 @@ set_initial_language (void)
if (lang == language_unknown)
{
- /* Make C the default language */
- lang = language_c;
+ lang = default_lang;
}
set_language (lang);