A Fedora user reported a bug with the listed assertion. A reproducer is specified there by Jan. https://bugzilla.redhat.com/show_bug.cgi?id=1560010
The regression is: PASS: gdb-8.0 FAIL: gdb-8.1
See https://sourceware.org/ml/gdb-patches/2018-04/msg00234.html
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=58f0c71853f98afe623ab89c4362682885905ebb commit 58f0c71853f98afe623ab89c4362682885905ebb Author: Tom Tromey <tom@tromey.com> Date: Thu Apr 12 08:24:41 2018 -0600 Fix for dwz-related crash PR symtab/23010 reports a crash that occurs when using -readnow on a dwz-generated debuginfo file. The crash occurs because the DWARF has a partial CU with no language set, and then a full CU that references this partial CU using DW_AT_abstract_origin. In this case, the partial CU is read by dw2_expand_all_symtabs using language_minimal; but then this conflicts with the creation of the block's symbol table in the C++ CU. This patch fixes the problem by arranging for partial CUs not to be read by -readnow. I tend to think that it doesn't make sense to read a partial CU in isolation -- they should only be read when imported into some other CU. In conjunction with some other patches I am going to post, this also fixes the Rust -readnow crash that Jan reported. There are two problems with this patch: 1. It is difficult to reason about. There are many cases where I've patched the code to call init_cutu_and_read_dies with the flag set to "please do read partial units" -- but I find it difficult to be sure that this is always correct. 2. It is still missing a standalone test case. This seemed hard. 2018-05-17 Tom Tromey <tom@tromey.com> PR symtab/23010: * dwarf2read.c (load_cu, dw2_do_instantiate_symtab) (dw2_instantiate_symtab): Add skip_partial parameter. (dw2_find_last_source_symtab, dw2_map_expand_apply) (dw2_lookup_symbol, dw2_expand_symtabs_for_function) (dw2_expand_all_symtabs, dw2_expand_symtabs_with_fullname) (dw2_expand_symtabs_matching_one) (dw2_find_pc_sect_compunit_symtab) (dw2_debug_names_lookup_symbol) (dw2_debug_names_expand_symtabs_for_function): Update. (init_cutu_and_read_dies): Add skip_partial parameter. (process_psymtab_comp_unit, build_type_psymtabs_1) (process_skeletonless_type_unit, load_partial_comp_unit) (psymtab_to_symtab_1): Update. (load_full_comp_unit): Add skip_partial parameter. (process_imported_unit_die, dwarf2_read_addr_index) (follow_die_offset, dwarf2_fetch_die_loc_sect_off) (dwarf2_fetch_constant_bytes, dwarf2_fetch_die_type_sect_off) (read_signatured_type): Update.
Fixed on trunk; there's still discussion about whether to backport to 8.1.1.
Created attachment 11069 [details] program that causes the issue With the fix applied, I still get the error, so this does not seem solved. Can not manage to narrow it down, seems to involve gcc 8 + LTO atleast. The file does run on debian, needs lttng-ust library. Running the line below causes the trouble: gdb -ex 'p sizeof (void*)' netfilter
The master branch has been updated by Keith Seitz <kseitz@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=380618d68a2b4ee60cebf3941d11a5af4e0aeee0 commit 380618d68a2b4ee60cebf3941d11a5af4e0aeee0 Author: Keith Seitz <keiths@redhat.com> Date: Tue Jul 24 12:48:58 2018 -0700 Set CU language before processing any DIEs (symtab/23010 et al) This patch is another attempt at really fixing the multitude of assertions being seen where symbols of one language are being added to symbol lists of another language. In this specific case, the backtrace command (thread apply all bt full) that is looking for the compunit containing the PC of the thread. That calls get_prev_frame several times. This function calls (eventually) dwarf2_frame_prev_register. That eventually ends up calling find_pc_compunit_symtab. In this function (find_pc_sect_compunit_symtab actually), we loop over all compunits, calling the "quick" function dw2_find_pc_sect_compunit_symtab. That function calls dw2_instantiate_symtab to read in all the CU's symbols. Now the fun begins. dw2_do_instantiate_symtab queues the per_cu for reading, using a default "pretend" language of language_minimal with the expectation that this will be set later. The DIEs of this (only queued) CU are then processed. The first DIE is DW_TAG_compile_unit. That's handled by read_file_scope. (Nearly) The first thing read_file_scope does is: get_scope_pc_bounds (die, &lowpc, &highpc, cu); This function loops over the children of the current DIE (a compile_unit), looking for bounds. The first such child is a subprogram, and we attempt to get its bounds. We use dwarf2_attr to get at DW_AT_high_pc. This subprogram has DW_AT_specification set, so dwarf_attr (via follow_die_ref/follow_die_offset) will follow that, but follow_die_offset *also* attempts to load the containing CU for the spec DIE. That spec DIE lives inside a CU that is a partial_unit and has no language attribute. So it simply inherits the language from the CU that elicited the read. [That all happens in follow_die_offset.] The original CU's language is still language_minimal -- we haven't gotten to the line in read_file_scope that actually sets the language yet! And that is the cause of these problems. The call to prepare_one_comp_unit needs to be the *first* thing that is done when reading a CU so that the CU's language can be recorded (and inherited by any referenced partial_units). Since a test reproducer for this has been so elusive, this patch also adds a wrapper function around add_symbol_to_list which asserts when adding a symbol of one language to a list containing symbols of a different language. gdb/ChangeLog: 2017-07-24 Keith Seitz <keiths@redhat.com> PR symtab/23010 * dwarf2read.c (dw2_add_symbol_to_list): New function. (fixup_go_packaging, new_symbol): Use dw2_add_symbol_to_list instead of add_symbol_to_list. (read_file_scope): Call prepare_one_comp_unit before reading any other DIEs.
The gdb-8.2-branch branch has been updated by Keith Seitz <kseitz@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9eb8d8e3e025323c9c5566b36c1fdc331aa33132 commit 9eb8d8e3e025323c9c5566b36c1fdc331aa33132 Author: Keith Seitz <keiths@redhat.com> Date: Tue Jul 24 12:45:51 2018 -0700 Set CU language before processing any DIEs (symtab/23010 et al) This patch is another attempt at really fixing the multitude of assertions being seen where symbols of one language are being added to symbol lists of another language. In this specific case, the backtrace command (thread apply all bt full) that is looking for the compunit containing the PC of the thread. That calls get_prev_frame several times. This function calls (eventually) dwarf2_frame_prev_register. That eventually ends up calling find_pc_compunit_symtab. In this function (find_pc_sect_compunit_symtab actually), we loop over all compunits, calling the "quick" function dw2_find_pc_sect_compunit_symtab. That function calls dw2_instantiate_symtab to read in all the CU's symbols. Now the fun begins. dw2_do_instantiate_symtab queues the per_cu for reading, using a default "pretend" language of language_minimal with the expectation that this will be set later. The DIEs of this (only queued) CU are then processed. The first DIE is DW_TAG_compile_unit. That's handled by read_file_scope. (Nearly) The first thing read_file_scope does is: get_scope_pc_bounds (die, &lowpc, &highpc, cu); This function loops over the children of the current DIE (a compile_unit), looking for bounds. The first such child is a subprogram, and we attempt to get its bounds. We use dwarf2_attr to get at DW_AT_high_pc. This subprogram has DW_AT_specification set, so dwarf_attr (via follow_die_ref/follow_die_offset) will follow that, but follow_die_offset *also* attempts to load the containing CU for the spec DIE. That spec DIE lives inside a CU that is a partial_unit and has no language attribute. So it simply inherits the language from the CU that elicited the read. [That all happens in follow_die_offset.] The original CU's language is still language_minimal -- we haven't gotten to the line in read_file_scope that actually sets the language yet! And that is the cause of these problems. The call to prepare_one_comp_unit needs to be the *first* thing that is done when reading a CU so that the CU's language can be recorded (and inherited by any referenced partial_units). Since a test reproducer for this has been so elusive, this patch also adds a wrapper function around add_symbol_to_list which asserts when adding a symbol of one language to a list containing symbols of a different language. gdb/ChangeLog: 2017-07-24 Keith Seitz <keiths@redhat.com> PR symtab/23010 * dwarf2read.c (dw2_add_symbol_to_list): New function. (fixup_go_packaging, new_symbol): Use dw2_add_symbol_to_list instead of add_symbol_to_list. (read_file_scope): Call prepare_one_comp_unit before reading any other DIEs.
I have the same problem on AIX 6, PowerPC, 64-bit, with gdb-8.1.1
(In reply to Lorinczy Zsigmond from comment #8) > I have the same problem on AIX 6, PowerPC, 64-bit, with gdb-8.1.1 "Target Milestone: 8.2" The patch is not in 8.1[.x] as far as I know. Please try master or the 8.2 branch. If the problem persists, I would be very anxious to get my hands on some way to reproduce this.
T(In reply to Keith Seitz from comment #9) > The patch is not in 8.1[.x] as far as I know. Please try master or the 8.2 > branch. Hi, thank you for your quick answer. So far, I was not successful dowloading version 8.2, maybe it is only for developers? $ git clone --branch gdb-8.2-branch ssh://sourceware.org/git/binutils-gdb.git Cloning into 'binutils-gdb'... zsiga@sourceware.org: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
(In reply to Lorinczy Zsigmond from comment #10) > T(In reply to Keith Seitz from comment #9) > > > The patch is not in 8.1[.x] as far as I know. Please try master or the 8.2 > > branch. > > Hi, thank you for your quick answer. So far, I was not successful dowloading > version 8.2, maybe it is only for developers? > > $ git clone --branch gdb-8.2-branch > ssh://sourceware.org/git/binutils-gdb.git > Cloning into 'binutils-gdb'... > zsiga@sourceware.org: Permission denied (publickey). > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. Do you have an account on sourceware? If not, then using ssh:// to clone the repository will not work. You should use git://.
(In reply to Sergio Durigan Junior from comment #11) > Do you have an account on sourceware? If not, then using ssh:// to clone > the repository will not work. You should use git://. Thank you, now I was able compile it. Well, the problem persists, I'll try to debug it, so far here is some bits I collected: OS: Aix-6.1; CPU: PowerPC (64-bit, big endian); C-compiler: gcc 4.8.3; how to provoke the failure: the program-to-be-debugged have to depend on an external shared object compiled with gcc: $ gdb ./helloworld GNU gdb (GDB) 8.1.90.20180803-git Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-ibm-aix6.1.9.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./helloworld...done. dictionary.c:690: internal-error: void insert_symbol_hashed(dictionary*, symbol*): Assertion `SYMBOL_LANGUAGE (sym) == DICT_LANGUAGE (dict)->la_language' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n This is a bug, please report it. For instructions, see: <http://www.gnu.org/software/gdb/bugs/>. dictionary.c:690: internal-error: void insert_symbol_hashed(dictionary*, symbol*): Assertion `SYMBOL_LANGUAGE (sym) == DICT_LANGUAGE (dict)->la_language' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n Command aborted. (gdb) quit
Reopening, since it's reported as not fixed.
Hi, I am still trying to collect information, here is what I have so far: https://www.linuxquestions.org/questions/aix-43/gdb-8-1-1-versus-aix-4175636082/
Well, it's just a wild guess, but my problem might be related with the fact, that every call of 'start_symtab' in 'xcoffread.c' passes parameter 'language' as 'language_unknown'
(In reply to Lorinczy Zsigmond from comment #15) > Well, it's just a wild guess, but my problem might be related with the fact, > that every call of 'start_symtab' in 'xcoffread.c' passes parameter > 'language' as 'language_unknown' That's what the DWARF reader does, too. The problem is that symbols are being added to the dictionary *before* the real language is read from the debug info. [For a detailed explanation of what was happening in the DWARF reader, see comment #7. Something similar *must* be happening here.] If you can provide me with a reproducer, the GCC compile farm has an s390 box (or two) that I can use to debug this.
I recently hit this issue with the following open-source project of mine: https://github.com/rdiez/JtagDue That project has a Toolchain/ subdir with the script I use to build a GCC-based toolchain. I have used it for years, upgrading GCC etc. every now and then. With GCC 7.3 and GDB 8.1 I had no problem, but when I tried to upgrade to GCC 8.2, I got the assertion straight away. I had never seen this assertion in the past. Unfortunately, it is a cross-compiler for a Cortex-M3 embedded target, so it does not run on a normal PC. If you are having trouble reproducing this issue, I could try again with the HEAD sources. Just tell me what flags I should build GDB with, and how to extract the information you need to debug the assertion.
(In reply to rdiezmail-binutils from comment #17) > If you are having trouble reproducing this issue, I could try again with the > HEAD sources. Just tell me what flags I should build GDB with, and how to > extract the information you need to debug the assertion. Does gdb crash with just the executable? Like, do you need to actually run the program? Or does it crash with -readnow? If so then just getting the executable would help.
My scripts run the executable on the target straight away. I did not check how far GDB got when it asserted. I'll build a new toolchain and try again tomorrow.
Created attachment 11184 [details] ELF file that makes GDB assert
OK, I can still reproduce the problem: -----8<-----8<-----8<----- GNU gdb (GDB) 8.1.90.20180815-git [... blah blah ...] Reading symbols from /home/rdiez/rdiez/arduino/JtagDue/BuildOutput/JtagDue-obj-release/firmware.elf...done. (gdb) p SysTick_Handler dwarf2read.c:9715: internal-error: void dw2_add_symbol_to_list(symbol*, pending**): Assertion `(*listhead) == NULL || (SYMBOL_LANGUAGE ((*listhead)->symbol[0]) == SYMBOL_LANGUAGE (symbol))' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) -----8<-----8<-----8<----- There is no need to run the firmware, just loading the ELF in GDB and trying to print the function above breaks it. This only happens with the release build of my firmware, which is built with LTO. The debug build works fine. I built GDB like this: cd "$HOME/rdiez/temp/gdb-8.2-branch" && ./configure CFLAGS="-O0 -g" CXXFLAGS="-O0 -g" --prefix="$HOME/rdiez/temp/gdb-8.2-branch-bin" --target=arm-none-eabi I have attached file firmware.elf to this bug. What else do you need?
(In reply to rdiezmail-binutils from comment #21) > This only happens with the release build of my firmware, which is built with > LTO. The debug build works fine. > > I built GDB like this: > > cd "$HOME/rdiez/temp/gdb-8.2-branch" && ./configure CFLAGS="-O0 -g" > CXXFLAGS="-O0 -g" --prefix="$HOME/rdiez/temp/gdb-8.2-branch-bin" > --target=arm-none-eabi > > I have attached file firmware.elf to this bug. > > What else do you need? I can confirm that this is reproduced on my "normal" --enable-targets=all builds on Fedora. I will investigate.
Can we verify whether the problem reproduces with 8.0 or not? Knowing whether this is indeed a regression would help prioritize a bit, which we need to do, as 8.2 is getting farther and farther behind the tentative schedule. Thank you!
(In reply to Joel Brobecker from comment #23) > Can we verify whether the problem reproduces with 8.0 or not? Knowing > whether this is indeed a regression would help prioritize a bit, which we > need to do, as 8.2 is getting farther and farther behind the tentative > schedule. The patch series that introduced this problem is cxx-breakpoint-improvements. That series was committed in November 2017 -- after 8.0 was released. For what little it is worth, the problems that rdiezmail-binutils is reporting is specifically a result of using LTO. GCC outputs an artificial compile_unit DIE (language_c) and then inlines functions from C++ compilation units, triggering the assertion. I'm still playing with ideas to solve this. The AIX problem reported by Lorinczy Zsigmond, however, hints at hiding problems in other debuginfo readers.
There is a patch that has been approved for AIX. It is a slightly different problem than what is causing grief on DWARF-using systems, but it triggers the same DICT_LANGUAGE == SYMBOL_LANGUAGE assertion failure: https://sourceware.org/ml/gdb-patches/2018-10/msg00324.html
The master branch has been updated by Keith Seitz <kseitz@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c7748ee9ceb5a394658cd07aeb0445924599e442 commit c7748ee9ceb5a394658cd07aeb0445924599e442 Author: Keith Seitz <keiths@redhat.com> Date: Thu Jan 10 13:57:08 2019 -0800 gdb/23712: Introduce multidictionary's gdb/23712 is a new manifestation of the now-infamous (at least to me) symtab/23010 assertion failure (DICT_LANGUAGE == SYMBOL_LANGAUGE). An example of the problem (using test case from symtab/23010): Reading symbols from /home/rdiez/rdiez/arduino/JtagDue/BuildOutput/JtagDue-obj-release/firmware.elf...done. (gdb) p SysTick_Handler dwarf2read.c:9715: internal-error: void dw2_add_symbol_to_list(symbol*, pending**): Assertion `(*listhead) == NULL || (SYMBOL_LANGUAGE ((*listhead)->symbol[0]) == SYMBOL_LANGUAGE (symbol))' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) This assertion was added specifically to catch this condition (of adding symbols of different languages to a single pending list). The problems we're now seeing on systems utilizing DWARF debugging seem to be caused by the use of LTO, which adds a CU with an artificial DIE of language C99 which references DIEs in other CUs of language C++. Thus, we create a dictionary containing symbols of C99 but end up stuffing C++ symbols into it, and the dw2_add_symbol_to_list triggers. The approach taken here to fix this is to introduce multi-language dictionaries to "replace" the standard, single-language dictionaries used today. Note to reviewers: This patch introduces some temporary functions to aide with review. This and other artifacts (such as "See dictionary.h" which appear incorrect) will all be valid at the end of the series. This first patch introduces the new multidictionary and its API (which is, by design, identical to the old dictionary interface). It also mutates dict_create_hashed and dict_create_linear so that they take a std::vector instead of the usual struct pending linked list. This will be needed later on. This patch does /not/ actually enable multidictionary's. That is left for a subsequent patch in the series. I've done exhaustive performance testing with this approach, and I've attempted to minimize the overhead for the (overwhelmingly) most common one-language scenario. On average, a -g3 -O0 GDB (the one we developers use) will see approximately a 4% slowdown when initially reading symbols. [I've tested only GDB and firefox with -readnow.] When using -O2, this difference shrinks to ~0.5%. Since a number of runs with these patches actually run /faster/ than unpatched GDB, I conclude that these tests have at least a 0.5% error margin. On our own gdb.perf test suite, again, results appear to be pretty negligible. Differences to unpatched GDB range from -7.8% (yes, patched version is again faster than unpatched) to 27%. All tests lying outside "negligible," such as the 27% slowdown, involve a total run time of 0.0007 (or less) with smaller numbers of CUs/DSOs (usually 10 or 100). In all cases, the follow-up tests with more CUs/DSOs is never more than 3% difference to the baseline, unpatched GDB. In my opinion, these results are satisfactory. gdb/ChangeLog: PR gdb/23712 PR symtab/23010 * dictionary.c: Include unordered_map. (pending_to_vector): New function. (dict_create_hashed_1, dict_create_linear_1, dict_add_pending_1): Rewrite the non-"_1" functions to take vector instead of linked list. (dict_create_hashed, dict_create_linear, dict_add_pending): Use the "new" _1 versions of the same name. (multidictionary): Define. (std::hash<enum language): New definition. (collate_pending_symbols_by_language, mdict_create_hashed) (mdict_create_hashed_expandable, mdict_create_linear) (mdict_create_linear_expandable, mdict_free) (find_language_dictionary, create_new_language_dictionary) (mdict_add_symbol, mdict_add_pending, mdict_iterator_first) (mdict_iterator_next, mdict_iter_match_first, mdict_iter_match_next) (mdict_size, mdict_empty): New functions. * dictionary.h (mdict_iterator): Define.
The master branch has been updated by Keith Seitz <kseitz@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b026f59345a336cabf74719fce9f96cab7c7ab4d commit b026f59345a336cabf74719fce9f96cab7c7ab4d Author: Keith Seitz <keiths@redhat.com> Date: Thu Jan 10 13:57:08 2019 -0800 gdb/23712: Use new multidictionary API This patch builds on the previous by enabling the `new' multidictionary API. A lot of the hunks are simply textual replacements of "dict_" with "mdict_" and similar transformations. A word of warning, even with the use of multidictionaries, the code still does not satisfactorily fix the reported problems with gdb/23712 (or gdb/23010). We still have additional changes to make before that happens. gdb/ChangeLog: PR gdb/23712 PR symtab/23010 * dictionary.h (struct dictionary): Replace declaration with multidictionary. (dict_create_hashed, dict_create_hashed_expandable) (dict_create_linear, dict_create_linear_expandable) (dict_free, dict_add_symbol, dict_add_pending, dict_empty) (dict_iterator_first, dict_iterator_next, dict_iter_match_first) (dict_iter_match_next, dict_size): Rename to "mdict_" versions taking multidictionary argument. [ALL_DICT_SYMBOLS]: Update for multidictionary. * block.h (struct block) <dict>: Change to multidictionary and rename `multidict'. * block.c, buildsym.c, jit.c, mdebugread.c, objfiles.c, symmisc.c: Update all dictionary references to multidictionary.
The master branch has been updated by Keith Seitz <kseitz@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=63a20375b401e24c30987367a10b47b289612e1c commit 63a20375b401e24c30987367a10b47b289612e1c Author: Keith Seitz <keiths@redhat.com> Date: Thu Jan 10 13:57:08 2019 -0800 gdb/23712: Cleanup/Remove temporary dictionary functions Now that multidictionary's are being used, there is no longer any need to retain the four temporary functions introduced in the beginning of this series. This patch removes them. As an additional cleanup, since the single-language dictionaries are no longer used outside dictionary.c, make all of those functions static. gdb/ChangeLog: PR gdb/23712 PR symtab/23010 * dictionary.c (pending_to_vector): Remove. (dict_create_hashed_1, dict_create_linear_1, dict_add_pending_1): Remove _1 suffix, replacing functions of the same name. Update all callers. (dict_create_hashed, dict_create_hashed_expandable) (dict_create_linear, dict_create_linear_expandable, dict_free) (dict_add_symbol, dict_add_pending, dict_size, dict_empty): Make functions static.
The master branch has been updated by Keith Seitz <kseitz@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d3cb68081112a4976979df3f8eae7ca926e76519 commit d3cb68081112a4976979df3f8eae7ca926e76519 Author: Keith Seitz <keiths@redhat.com> Date: Thu Jan 10 13:57:08 2019 -0800 gdb/23712: Remove dw2_add_symbol_to_list Finally, we can remove dw2_add_symbol_to_list since the wrapper function originally introduced to catch this multi-language scenario is no longer needed. With multi-language dictionaries, we can now support adding symbols of multiple languages, negating the need for the assertion entirely. This patch should now fix gdb/23712 (and symtab/23010). At least it will if the NULL buildsym_compunit problem doesn't strike first (see gdb/23773). gdb/ChangeLog: PR gdb/23712 PR symtab/23010 * dwarf2read.c (dw2_add_symbol_to_list): Remove. (fixup_go_packaging, new_symbol): Use add_symbol_to_list.
The master branch has been updated by Keith Seitz <kseitz@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b56f80d8b27dffd0f8c02b8b11068b71b9fec375 commit b56f80d8b27dffd0f8c02b8b11068b71b9fec375 Author: Keith Seitz <keiths@redhat.com> Date: Thu Jan 10 13:57:09 2019 -0800 gdb/23712: Test case for multidictionary This is a test derived from one of the reproducers in symtab/23010. The DIE tree used here is typical of compilations with LTO, where an artificial parent DIE of language C99 imports DIEs of other languages. gdb/testsuite/ChangeLog: PR gdb/23712 PR symtab/23010 * gdb.dwarf2/multidictionary.exp: New file.
This has been fixed since the cited commit in January.