public inbox for gdb-testers@sourceware.org help / color / mirror / Atom feed
From: gdb-buildbot@sergiodj.net To: gdb-testers@sourceware.org Subject: [binutils-gdb] [gdb] Don't set initial language using previous language Date: Wed, 11 Mar 2020 13:21:35 -0400 [thread overview] Message-ID: <658dadf0b02b618fe81e7b09ad930479941f2236@gdb-build> (raw) *** TEST RESULTS FOR COMMIT 658dadf0b02b618fe81e7b09ad930479941f2236 *** commit 658dadf0b02b618fe81e7b09ad930479941f2236 Author: Tom de Vries <tdevries@suse.de> AuthorDate: Fri Feb 28 16:14:53 2020 +0100 Commit: Tom de Vries <tdevries@suse.de> CommitDate: Fri Feb 28 16:14:53 2020 +0100 [gdb] Don't set initial language using previous language 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. gdb/ChangeLog: 2020-02-28 Tom de Vries <tdevries@suse.de> * symfile.c (set_initial_language): Use default language for lookup. diff --git a/gdb/ChangeLog b/gdb/ChangeLog index fce2a03a5d..5f49542fb8 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,7 @@ +2020-02-28 Tom de Vries <tdevries@suse.de> + + * symfile.c (set_initial_language): Use default language for lookup. + 2020-02-28 Simon Marchi <simon.marchi@efficios.com> * dwarf2/read.c (cutu_reader::init_tu_and_read_dwo_dies): Remove diff --git a/gdb/symfile.c b/gdb/symfile.c index f1edf2dca5..01c3f5af12 100644 --- a/gdb/symfile.c +++ b/gdb/symfile.c @@ -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);
next reply other threads:[~2020-03-11 17:21 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-11 17:21 gdb-buildbot [this message] 2020-03-11 17:21 ` Failures on Fedora-i686, branch master gdb-buildbot 2020-03-11 17:34 ` Failures on Fedora-x86_64-cc-with-index, " gdb-buildbot 2020-03-11 17:51 ` Failures on Fedora-x86_64-m32, " gdb-buildbot 2020-03-11 18:18 ` Failures on Fedora-x86_64-m64, " gdb-buildbot 2020-03-11 18:30 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " gdb-buildbot 2020-03-11 19:19 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " gdb-buildbot 2020-03-13 1:29 ` Failures on Ubuntu-Aarch64-native-extended-gdbserver-m64, " gdb-buildbot 2020-03-13 10:21 ` Failures on Fedora-x86_64-native-gdbserver-m64, " gdb-buildbot 2020-03-14 10:44 ` Failures on Fedora-x86_64-native-gdbserver-m32, " gdb-buildbot
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=658dadf0b02b618fe81e7b09ad930479941f2236@gdb-build \ --to=gdb-buildbot@sergiodj.net \ --cc=gdb-testers@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).