summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* gdbserver: replace AC_TRY_COMPILE in acinclude.m4users/simark/autoconf-warningsSimon Marchi2020-10-252-25/+27
| | | | | | | | | | | | | | | ... with AC_COMPILE_IFELSE and AC_LANG_PROGRAM. All changes in the generated configure file are insignificant whitespace changes. gdbserver/ChangeLog: * acinclude.m4: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE + AC_LANG_PROGRAM. * configure: Re-generate. Change-Id: Idab8b5e1a984046b5283940c02e5a22da2291d58
* gdb: replace AC_TRY_LINK in sanitize.m4Simon Marchi2020-10-252-1/+6
| | | | | | | | | | | | | | | ... with AC_LINK_IFELSE + AC_LANG_PROGRAM. All changes in the generated configure file are insignificant whitespace changes. gdb/ChangeLog: * configure: Re-generate. * sanitize.m4: Replace AC_TRY_LINK with AC_LINK_IFELSE + AC_LANG_PROGRAM. Change-Id: I6fc4c39e10b28d2ade964e0d59a7f8ec0d3a272a
* gdbsupport: replace AC_TRY_COMPILE in common.m4Simon Marchi2020-10-254-17/+35
| | | | | | | | | | | | | | | | | | | | | ... with AC_COMPILE_IFELSE + AC_LANG_PROGRAM. All the changes in the generated configure files are insignificant whitespace changes. gdb/ChangeLog: * configure: Re-generate. gdbserver/ChangeLog: * configure: Re-generate. gdbsupport/ChangeLog: * common.m4: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE + AC_LANG_PROGRAM. * configure: Re-generate. Change-Id: Id58e6e887f6be817d52b189921845838031dbd2a
* gdbsupport: use AC_FUNC_FORK instead of AC_FUNC_VFORKSimon Marchi2020-10-251-1/+1
| | | | | | | | | | | | | | | | | | autoupdate does this change, it fixes this warning: configure.ac:50: warning: The macro `AC_FUNC_VFORK' is obsolete. configure.ac:50: You should run autoupdate. ../../lib/autoconf/functions.m4:1944: AC_FUNC_VFORK is expanded from... common.m4:20: GDB_AC_COMMON is expanded from... configure.ac:50: the top level There are not changes in the generated configure files. gdbsupport/ChangeLog: * common.m4: Replace AC_FUNC_VFORK with AC_FUNC_FORK. Change-Id: I9de9f718c57e6d51c9734161f36c36ce39170325
* gdbsupport: replace AC_TRY_COMPILE in warning.m4Simon Marchi2020-10-254-17/+28
| | | | | | | | | | | | | | | | | | | | | | | Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE + AC_LANG_PROGRAM. All changes in generated configure files are insignificant whitespace changes. gdb/ChangeLog: * configure: Re-generate. gdbserver/ChangeLog: * configure: Re-generate. gdbsupport/ChangeLog: * configure: Re-generate. * warning.m4: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE + AC_LANG_PROGRAM. Change-Id: I517bd20ec3af960ad999a586761df0ac8959a3fc
* gdbsupport: replace AC_TRY_COMPILE in ptrace.m4Simon Marchi2020-10-254-18/+43
| | | | | | | | | | | | | | | | | | | | | | | Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE + AC_LANG_PROGRAM. All the changes in the generated configure files are insignificant whitespace changes. gdb/ChangeLog: * configure: Re-generate. gdbserver/ChangeLog: * configure: Re-generate. gdbsupport/ChangeLog: * configure: Re-generate. * ptrace.m4: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE + AC_LANG_PROGRAM. Change-Id: Ia782b5477fe49dad04e68c0f41c6d8ab3fde5bf0
* gdbsupport: re-indent ptrace.m4Simon Marchi2020-10-254-119/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For some reason, autoupdate isn't able to grok ptrace.m4: $ autoupdate ptrace.m4 /usr/bin/m4:/tmp/auYjuodw/input.m4:171: ERROR: end of file in string autoupdate: /usr/bin/m4 failed with exit status: 1 Honestly, I'm unable to grok it either. This patch re-indents it in a way that I think is easier to read. With this patch applied, autoupdate becomes able to parse ptrace.m4, but I chose to keep this re-indent in a patch of its own. All the changes in generated configure files consist of insignificant whitespace changes. gdb/ChangeLog: * configure: Re-generate. gdbserver/ChangeLog: * configure: Re-generate. gdbsupport/ChangeLog: * configure: Re-generate. * ptrace.m4: Re-indent. Change-Id: Ie2afab09fecc8b6d0cccccb47ac9756f3843881e
* gdb: modernize acinclude.m4Simon Marchi2020-10-252-22/+42
| | | | | | | | | | | Run autoupdate, fix indentation for readability. gdb/ChangeLog: * acinclude.m4: Modernize. * configure: Re-generate. Change-Id: I8949f885326a3206f414776b63a1fdba197bb19a
* gdb/testsuite: modernize configure.acSimon Marchi2020-10-252-1/+3
| | | | | | | | | | | | Run autoupdate, the only change is to split AC_INIT into AC_INIT and AC_CONFIG_SRCDIR. gdb/testsuite/ChangeLog: * configure.ac: Split AC_INIT into AC_INIT and AC_CONFIG_SRCDIR. * configure: Re-generate. Change-Id: I6e40c0261bda4fe9144b896799ef460d23e22e09
* gdb: modernize configure.acSimon Marchi2020-10-252-173/+311
| | | | | | | | | | | | | | | | | | | | | | | | | | Run autoupdate on configure.ac and adjust the indentation of the result for better readability. This removes a bunch of warnings when running `autoreconf -vf -Wall`. The changes are: * Replace AC_INIT with AC_INIT and no arguments plus AC_CONFIG_SRCDIR. * Replace AC_ERROR with AC_MSG_ERROR. * Replace AC_TRY_LINK with AC_LINK_IFELSE. * Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE. * Replace AC_HELP_STRING with AS_HELP_STRING. autoupdate erroneously tries to replace AC_C_LONG_DOUBLE in a comment, which I reverted manually. All the changes in the generated configure file are insignificant whitespaces changes. gdb/ChangeLog: * configure.ac: Modernize. * configure: Re-generate. Change-Id: Ie3a1409c8032a36a6383da964286a46ece9b546e
* gdbserver: modernize configure.acSimon Marchi2020-10-252-43/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Run autoupdate on gdbserver/configure.ac and then tweak it to use easier to read indentation. This removes a few warnings when running `autoreconf -vf -Wall`. * Replace AC_INIT with AC_INIT and no arguments plus AC_CONFIG_SRCDIR. * Replace AC_GNU_SOURCE with AC_USE_SYSTEM_EXTENSIONS. * Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE. * Replace AC_TRY_LINK with AC_LINK_IFELSE. autoupdate gets it right, except this one here: --- a/gdbserver/configure.ac +++ b/gdbserver/configure.ac @@ -304,7 +304,7 @@ if test "$srv_linux_thread_db" = "yes"; then AC_LINK_IFELSE([AC_LANG_PROGRAM([[]], [[]])],[found="-Wl,--dynamic-list" RDYNAMIC='-Wl,--dynamic-list=$(srcdir)/proc-service.list'],[RDYNAMIC="-rdynamic" LDFLAGS="$old_LDFLAGS $RDYNAMIC" - AC_TRY_LINK([], [], + _au_m4_changequote([,])AC_TRY_LINK([], [], [found="-rdynamic"], [found="no" RDYNAMIC=""])]) ... which I had to convert manually. The changes in the generated configure file only contain insignificant whitespace changes, so that gives confidence that the conversion is correct. gdbserver/ChangeLog: * configure.ac: Modernize. * configure: Re-generate. Change-Id: Ia769aaec2aafac595504f477da955e91dffa4d8f
* gdb: use AC_PROG_CC_STDC instead of AM_PROG_CC_STDCSimon Marchi2020-10-256-953/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `autoconf -Wall` notes that AM_PROG_CC_STDC is obsolete: Fixes this autoconf warning: configure.ac:40: warning: 'AM_PROG_CC_STDC': this macro is obsolete. configure.ac:40: You should simply use the 'AC_PROG_CC' macro instead. configure.ac:40: Also, your code should no longer depend upon 'am_cv_prog_cc_stdc', configure.ac:40: but upon 'ac_cv_prog_cc_stdc'. aclocal.m4:770: AM_PROG_CC_STDC is expanded from... configure.ac:40: the top level Since we build with a C++ compiler now, I don't think this is relevant. If you look at the messages removed from gdbsupport/aclocal.m4, it says that this functionality is now integrated in AC_PROG_CC, which we already call. So it might not even make a difference. We had a local version of AM_PROG_CC_STDC, in gdb/acinclude.m4 (only used by gdb/configure.ac), remove it. gdb/ChangeLog: * acinclude.m4 (AM_PROG_CC_STDC): Remove. * configure: Re-generate. * configure.ac: Remove AM_PROG_CC_STDC. gdbsupport/ChangeLog: * aclocal.m4: Re-generate. * configure: Re-generate. * configure.ac: Remove AM_PROG_CC_STDC. Change-Id: Ic824393598805d4f78cda9d119f8af46096e9c73
* gdb, gdbserver, gdbsupport: use AC_CANONICAL_{BUILD,HOST,TARGET} instead of ↵Simon Marchi2020-10-256-4/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AC_CANONICAL_SYSTEM `autoreconf -Wall` notes that AC_CANONICAL_SYSTEM is obsolete: configure.ac:36: warning: The macro `AC_CANONICAL_SYSTEM' is obsolete. Replace it by AC_CANONICAL_BUILD, AC_CANONICAL_HOST and AC_CANONICAL_TARGET in configure.ac files in gdb, gdbserver and gdbsupport. All three macros may not be needed everywhere, but it is hard to completely audit the configure files to see which are required, so I think it's better (and that there's no downside) to just call all three. gdb/ChangeLog: * configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of AC_CANONICAL_SYSTEM. * configure: Re-generate. gdbserver/ChangeLog: * configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of AC_CANONICAL_SYSTEM. * configure: Re-generate. gdbsupport/ChangeLog: * configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of AC_CANONICAL_SYSTEM. * configure: Re-generate. Change-Id: Ifd0e21f1e478634e768b5de1b8ee06a7f690d863
* gdb: move ptrace.m4 to gdbsupportSimon Marchi2020-10-258-4/+19
| | | | | | | | | | | | | | | | | | | | | | | ptrace.m4, providing the GDB_AC_PTRACE autoconf macro, is used by gdb, gdbserver and gdbsupport. I think it would make sense to move it to gdbsupport. gdb/ChangeLog: * acinclude.m4: Update ptrace.m4 path. * ptrace.m4: Moved to gdbsupport. gdbserver/ChangeLog: * acinclude.m4: Update ptrace.m4 path. gdbsupport/ChangeLog: * Makefile.in: Re-generate. * acinclude.m4: Update ptrace.m4 path. * ptrace.m4: Move here. Change-Id: I849c149fd5dd8c3b2b0af38654fb353e3727871b
* Automatic date update in version.inGDB Administrator2020-10-261-1/+1
|
* gdb: use inferior parameter in add_vsyscall_pageSimon Marchi2020-10-252-1/+7
| | | | | | | | | | | | | Use the new inferior parameter instead of target_gdbarch. There are still hidden references to the current context behind core_bfd and exec_bfd, but this seemed better than nothing. gdb/ChangeLog: * symfile-mem.c (add_vsyscall_page): Use inferior parameter instead of target_gdbarch. Change-Id: Iaf5ace555ee8e46cbef5190aca1f6fe639f06677
* gdb: make jit.c use the inferior_created inferior parameterSimon Marchi2020-10-254-19/+25
| | | | | | | | | | | | | | | | | | | | Use the inferior parameter now available in jit_inferior_created_hook. It is passed down to jit_inferior_init, which uses it as much as possible instead of the current inferior or current program space. gdb/ChangeLog: * jit.c (jit_reader_load_command): Pass current inferior. (jit_inferior_init): Change parameter type to inferior, use it. (jit_inferior_created): Remove. (jit_inferior_created_hook): Pass inferior parameter down. (_initialize_jit): Use jit_inferior_created_hook instead of jit_inferior_created. * jit.h (jit_inferior_created_hook): Add inferior parameter. * infrun.c (follow_exec): Pass inferior to jit_inferior_created_hook. Change-Id: If3a2114a933370dd313d5abd623136d273cdb8fa
* gdb: pass inferior to check_pid_namespace_matchSimon Marchi2020-10-252-3/+9
| | | | | | | | | | | | | | | | Pass the inferior argument available in thread_db_inferior_created, and use it to do most things requiring the inferior. check_pid_namespace_match is not completely decoupled from the current inferior yet, there are hidden references behind target_can_run, for example. But I think this is still a good step forward. gdb/ChangeLog: * linux-thread-db.c (check_pid_namespace_match): Add inferior parameter and use it. (thread_db_inferior_created): Pass inferior argument. Change-Id: Ib768b14fc61dcf115fe13f776691f2c2f36e0679
* gdb: add inferior parameter to inferior_created observableSimon Marchi2020-10-2511-10/+24
| | | | | | | | | | | | | | | | | | | | | | | | | I think it would make sense for the inferior_created observable to say which inferior is being dealt with, rather than relying on it being the current inferior. This patch adds an inferior parameter to inferior_created, but does not change the callbacks to use it. gdb/ChangeLog: * aix-thread.c (aix_thread_inferior_created): Add inferior parameter. * bsd-uthread.c (bsd_uthread_inferior_created): Likewise. * dummy-frame.c (cleanup_dummy_frames): Likewise. * jit.c (jit_inferior_created): Likewise. * linux-thread-db.c (thread_db_inferior_created): Likewise. * m68k-linux-tdep.c (m68k_linux_inferior_created): Likewise. * observable.h (inferior_created): Likewise. * ravenscar-thread.c (ravenscar_inferior_created): Likewise. * symfile-mem.c (add_vsyscall_page): Likewise. * infcmd.c (post_create_inferior): Pass inferior argument. Change-Id: I2543d19ff055a9df6b269929faea10b27d2adc5e
* asan: alpha-vms: buffer overflowAlan Modra2020-10-252-2/+10
| | | | | * vms-misc.c (_bfd_vms_save_counted_string): Count length byte towards maxlen.
* Automatic date update in version.inGDB Administrator2020-10-251-1/+1
|
* gdbserver: re-generate configureSimon Marchi2020-10-243-2/+21
| | | | | | | | | | | | | I get this diff when I re-generate the configure script in gdbserver, probably leftovers from e911c6663bb8 ("Require kinfo_get_file and kinfo_get_vmmap for FreeBSD hosts"). gdbserver/ChangeLog: * config.in: Re-generate. * configure: Re-generate. Change-Id: Id19a72ea9f3e7c7b4fdb0f319c9c0bbad0e39aeb
* Document the GDB 10.1 release in gdb/ChangeLogJoel Brobecker2020-10-241-0/+4
| | | | | | gdb/ChangeLog: GDB 10.1 released.
* Automatic date update in version.inGDB Administrator2020-10-241-1/+1
|
* ld: Set plug_opt only if compiler is availableH.J. Lu2020-10-232-12/+19
| | | | | * testsuite/config/default.exp (plug_opt): Set only if compiler is available.
* [gdb/testsuite] Don't use default form in Dwarf::_guess_formTom de Vries2020-10-232-9/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only possible form for a DW_AT_low_pc attribute is DW_FORM_addr. When specifying in dwarf assembly a low_pc attribute without explicit form: ... {low_pc {main_label - 4}} ... the resulting attribute uses DW_FORM_string, which is misinterpreted by gdb when reading it as: ... cu->base_address = attr->as_address (); ... Stop using DW_FORM_string as default form. Instead, use a default form based on the attribute name, if possible and unambiguous. Otherwise, error out. F.i.: - for DW_AT_low_pc we use DW_FORM_addr. - For DW_AT_high_pc, we don't specify a default form because it could be either address or constant class. - For DW_AT_name, we use DW_FORM_string. While we could encode with DW_FORM_strp instead, DW_FORM_string is always ok. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-10-23 Tom de Vries <tdevries@suse.de> * lib/dwarf.exp (Dwarf::_guess_form): Return "" by default instead of DW_FORM_string. (Dwarf::_default_form): New proc. (Dwarf::_handle_DW_TAG): Use _default_form. Error out if no form was guessed.
* [gdb/testsuite] Use $srcfile in DW_AT_name for CUTom de Vries2020-10-2321-24/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In dwarf assembly test-case ada-linkage-name.exp, we have: ... standard_testfile .c -debug.S ... cu {} { DW_TAG_compile_unit { {DW_AT_name ada-linkage-name.c} ... Use $srcfile instead of ada-linkage-name.c. In dwarf assembly test-case atomic-type.exp, we have: ... standard_testfile .c -dw.S ... cu {} { DW_TAG_compile_unit { {DW_AT_name atomic-type-dw.c} ... The dwarf generated into atomic-type-dw.S is meant to represent the code in atomic-type.c, not atomic-type-dw.c, so use $srcfile instead of atomic-type-dw.c. Fix these and similar. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-10-23 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/ada-linkage-name.exp: Use $srcfile for DW_AT_name of CU. * gdb.dwarf2/atomic-type.exp: Same. * gdb.dwarf2/bad-regnum.exp: Same. * gdb.dwarf2/cpp-linkage-name.exp: Same. * gdb.dwarf2/dw2-align.exp: Same. * gdb.dwarf2/dw2-bad-elf.exp: Same. * gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Same. * gdb.dwarf2/dw2-bad-unresolved.exp: Same. * gdb.dwarf2/dw2-namespaceless-anonymous.exp: Same. * gdb.dwarf2/dw2-opt-structptr.exp: Same. * gdb.dwarf2/dw2-unusual-field-names.exp: Same. * gdb.dwarf2/enum-type.exp: Same. * gdb.dwarf2/frame-inlined-in-outer-frame.exp: Same. * gdb.dwarf2/info-locals-optimized-out.exp: Same. * gdb.dwarf2/main-subprogram.exp: Same. * gdb.dwarf2/missing-type-name.exp: Same. * gdb.dwarf2/nonvar-access.exp: Same. * gdb.dwarf2/typedef-void-finish.exp: Same. * gdb.dwarf2/var-access.exp: Same. * gdb.dwarf2/void-type.exp: Same.
* ada-typeprint.c::ada_print_type: Remove redundant call to ada_check_typedefJoel Brobecker2020-10-232-3/+5
| | | | | | | | | | | This commit removes a call to ada_check_typedef which has already been done a few lines earlier in the same function, so the second one is superfluous. gdb/ChangeLog: * ada-typeprint.c (ada_print_type): Remove superfluous second call to ada_check_typedef.
* gdb: move f_language class into a header fileAndrew Burgess2020-10-237-329/+387
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Moves the f_language class from f-lang.c into f-lang.h. The benefit of this is that functions declared in other f-*.c files can become member functions without having to go through a level of indirection. Some additional support functions have now become private member functions of the f_language class, these are mostly functions that then called some other function that was itself a member of the language_defn class hierarchy. There should be no user visible changes after this commit. gdb/ChangeLog: * f-exp.y (f_parse): Rename to... (f_language::parser): ...this. * f-lang.c (f_get_encoding): Rename to... (f_language::get_encoding): ...this. (f_op_print_tab): Rename to... (f_language::op_print_tab): ...this. (exp_descriptor_f): Rename to... (f_language::exp_descriptor_tab): ...this. (class f_language): Moved to f-lang.h. (f_language::language_arch_info): New function, moved out of class declaration. (f_language::search_name_hash): Likewise. (f_language::lookup_symbol_nonlocal): Likewise. (f_language::get_symbol_name_matcher_inner): Likewise. * f-lang.h: Add 'valprint.h' include. (class f_language): Moved here from f-lang.c. * f-typeprint.c (f_type_print_args): Delete commented out declaration. (f_print_typedef): Rename to... (f_language::print_typedef): ...this. (f_print_type): Rename to... (f_language::print_type): ...this. (f_type_print_varspec_prefix): Delete declaration and rename to... (f_language::f_type_print_varspec_prefix): ...this. (f_type_print_varspec_suffix): Delete declaration and rename to... (f_language::f_type_print_varspec_suffix): ...this. (f_type_print_base): Delete declaration and rename to... (f_language::f_type_print_base): ...this. * f-valprint.c (f_value_print_inner): Rename to... (f_language::value_print_inner): ...this. * parse.c: Delete 'f-lang.h' include.
* gdb: Improve documentation comment on language_defn::print_typeAndrew Burgess2020-10-232-4/+13
| | | | | | | | | | | Improves the comment at the declaration of language_defn::print_type. There should be no user visible changes after this commit. gdb/ChangeLog: * language.h (language_defn::print_type): Add variable names in declaration, and update header comment.
* gdb: Rename language_defn::demangleAndrew Burgess2020-10-2310-10/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GDB already has a global symbol `demangle` (a boolean), having a language method called `demangle` is not a good idea as we often want to reference `demangle` the control variable inside `demangle` the member function. This commit renames `demangle` the member function to `demangle_symbol`. There should be no user visible changes after this commit. gdb/ChangeLog: * ada-lang.c (ada_language::demangle): Rename to... (ada_language::demangle_symbol): ...this. * c-lang.c (cplus_language::demangle): Rename to... (cplus_language::demangle_symbol): ...this. * d-lang.c (d_language::demangle): Rename to... (d_language::demangle_symbol): ...this. * f-lang.c (f_language::demangle): Rename to... (f_language::demangle_symbol): ...this. * go-lang.c (go_language::demangle): Rename to... (go_language::demangle_symbol): ...this. * language.c (language_demangle): Update call to demangle_symbol. (auto_or_unknown_language::demangle): Rename to... (auto_or_unknown_language::demangle_symbol): ...this. * language.h (language_defn::demangle): Rename to... (language_defn::demangle_symbol): ...this. * objc-lang.c (objc_language::demangle): Rename to... (objc_language::demangle_symbol): ...this. * rust-lang.c (rust_language::demangle): Rename to... (rust_language::demangle_symbol): ...this.
* gdb: remove LA_ITERATE_OVER_SYMBOLS macroAndrew Burgess2020-10-233-4/+7
| | | | | | | | | | | | | Replace the single use of the LA_ITERATE_OVER_SYMBOLS macro with the macro's definition, and delete the macro. There should be no user visible changes after this commit. gdb/ChangeLog: * language.h (LA_ITERATE_OVER_SYMBOLS): Delete. (iterate_over_file_blocks): Replace use of macro with the macros definition.
* gdb: remove LA_PRINT_ARRAY_INDEX macroAndrew Burgess2020-10-233-6/+8
| | | | | | | | | | | | | Replace the single use of the LA_PRINT_ARRAY_INDEX macro with the macro's definition, and delete the macro. There should be no user visible changes after this commit. gdb/ChangeLog: * language.h (LA_PRINT_ARRAY_INDEX): Delete. * valprint.c (maybe_print_array_index): Replace use of macro with the macros definition.
* gdb: remove LA_VALUE_PRINT macroAndrew Burgess2020-10-235-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the LA_VALUE_PRINT macro, and replace its uses with direct calls to the value_print member function on an appropriate language. In the global 'value_print' function, we call the value_print method on the current_language, this is a direct inline replacement of the old LA_VALUE_PRINT macro. However, in ada-lang.c, and language.c the macro was being used within the print_array_index member function of a language class. In these cases we now call the value_print member function of the current language class. In theory, when we are inside (for example) the ada_language::print_array_index function the current_language should always be set to Ada, so this change should have no effect. However, if we ever could get into ada_language::print_array_index with the current language set to something else (which I think would have been a bug) then we would now see a change in behaviour. I couldn't find any cases where this happened though. There should be no user visible changes after this commit, but it is not impossible in some edge cases. gdb/ChangeLog: * ada-lang.c (ada_language::print_array_index): Call value_print directly. * language.c (language_defn::print_array_index): Likewise. * language.h (LA_VALUE_PRINT): Delete. * valprint.c (value_print): Call value_print on the current_language directly.
* gdb: remove LA_PRINT_TYPEDEF macroAndrew Burgess2020-10-233-4/+7
| | | | | | | | | | | | | Remove the LA_PRINT_TYPEDEF macro, replace the single use with the macros definition. There should be no user visible changes after this commit. gdb/ChangeLog: * language.h (LA_PRINT_TYPEDEF): Delete. * typeprint.c (typedef_print): Call print_typedef directly on the current_language object.
* gdb: move Modula2 language class into a header fileAndrew Burgess2020-10-236-270/+308
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the m2_language class from m2-lang.c into m2-lang.h. The benefit of this move is that we can remove trampoline functions. Currently the language implementation is split of different m2-* files with m2-lang.h including declaration for all the language implementation functions. Currently the m2_language class in m2-lang.c has member functions that then call the global functions declared in m2-lang.h. After this change the m2_language class is declared in m2-lang.h, and the member functions are the implementations defined in all the m2-* files. There should be no user visible changes after this commit. gdb/ChangeLog: * m2-exp.y (m2_parse): Rename to... (m2_language::parser): ...this. Update function signature. * m2-lang.c (m2_printchar): Renamed to m2_language::printchar. (m2_op_print): Rename to... (m2_language::op_print_tab): ...this, and make const. (exp_descriptor_modula2): Rename to... (m2_language::exp_descriptor_modula2): ...this. (class m2_language): Move to m2-lang.h. (m2_language::language_arch_info): New function, moved out of class declaration. (m2_language::printchar): New function, body from m2_printchar. (m2_language::printstr): New function, moved out of class declaration. (m2_language::emitchar): Likewise. * m2-lang.h (m2_parse): Delete declaration. (m2_print_typedef): Delete declaration. (m2_value_print_inner): Delete declaration. (class m2_language): Class declaration moved from m2-lang.c, larger functions are left in m2-lang.c. * m2-typeprint.c (m2_print_typedef): Rename to... (m2_language::print_typedef): ...this, and update function signature. * m2-valprint.c (m2_value_print_inner): Rename to... (m2_language::value_print_inner): ...this, replace use of LA_PRINT_STRING with a direct call to printstr member function, and update recursive call.
* gdb: Merge auto and unknown language implementationsAndrew Burgess2020-10-232-155/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The auto_language and unknown_language classes are basically the same except for the language names and store_sym_names_in_linkage_form_p which the unknown_language overrides to return true, while auto_language returns the default false. This commit creates a new parent class from which both of these languages can inherit. The two base classes are now greatly reduced. Some of the static helper functions which previously were called from both of these languages are now only called from one place, and so I've inlined them into the new class. There should be no user visible changes after this commit. gdb/ChangeLog: * language.c (default_is_string_type_p): Delete, implementation moved into auto_or_unknown_language::is_string_type_p. (unk_op_print_tab): Moved into auto_or_unknown_language::opcode_print_table. (unknown_language_arch_info): Delete, implementation moved into auto_or_unknown_language::language_arch_info. (class auto_or_unknown_language): New class, member functions copied from unknown_language class, with some updates. (class unknown_language): Most member functions moved into auto_or_unknown_language class. Inherit from auto_or_unknown_language class. (class auto_language): Inherit from auto_or_unknown_language. Delete most member functions.
* Automatic date update in version.inGDB Administrator2020-10-231-1/+1
|
* Remove gdb_assert for TYPE_CODE_METHOD in stabs readerHannes Domani2020-10-222-3/+4
| | | | | | | | | | | | It's possible to come across TYPE_CODE_UNDEF at this point in read_member_functions, which according to a comment in read_type is used for forward references. gdb/ChangeLog: 2020-10-22 Hannes Domani <ssbssa@yahoo.de> * stabsread.c (read_member_functions): Remove gdb_assert.
* Don't create _Complex type name if there is no target type nameHannes Domani2020-10-222-1/+5
| | | | | | | | | | | | | This causes gdb to crash in strlen. Happens if init_complex_type is called for a type created by dbx_init_float_type in stabsread.c. gdb/ChangeLog: 2020-10-22 Hannes Domani <ssbssa@yahoo.de> * gdbtypes.c (init_complex_type): Check target type name.
* gdb: remove unused macros from target-debug.hSimon Marchi2020-10-222-16/+12
| | | | | | | | | | | | | | | | | | | | | I noticed some clearly stale entries in target-debug.h (which contained references to VEC). I commented everything in target-debug.h and then uncommented things until it built again, it pointed out a few unused macros. Remove them. gdb/ChangeLog: * target-debug.h (target_debug_print_struct_target_ops_p): Remove. (target_debug_print_async_callback_ftype_p): Remove. (target_debug_print_struct_trace_state_variable_p): Remove. (target_debug_print_struct_traceframe_info_p): Remove. (target_debug_print_VEC__btrace_block_s__pp): Remove. (target_debug_print_enum_btrace_format): Remove. (target_debug_print_enum_info_proc_what): Remove. (target_debug_print_thread_info_pp): Remove. Change-Id: I7943d21ac6e78751fd7c65a45b345018623ac2f2
* gdb: make target_ops::make_corefile_notes return a unique ptrSimon Marchi2020-10-228-57/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we converted gdbarch_make_corefile_notes to returning a gdb::unique_xmalloc_ptr, I figured it would make sense to converted target_ops::make_corefile_notes as well. The only implementation of that is in procfs.c, and it should ideally be re-written as a gdbarch method (see comment in write_gcore_file_1), but in the mean time I guess it doesn't hurt to throw some unique pointer at it. I tested that it builds on Solaris 11 (gcc compile farm machine gcc211), but I am not able to test it, because I can't get GDB to start a process (I'll look at that separately). gdb/ChangeLog: * target.h (struct target_ops) <make_corefile_notes>: Change return type to unique pointer. * target.c (dummy_make_corefile_notes): Likewise. * exec.c (struct exec_target) <make_corefile_notes>: Likewise. (exec_target::make_corefile_notes): Likewise. * procfs.c (class procfs_target) <make_corefile_notes>: Likewise. (procfs_do_thread_registers): Adjust to unique pointer. (struct procfs_corefile_thread_data): Add constructor. <note_data>: Change type to unique pointer. (procfs_corefile_thread_callback): Adjust to unique pointer. (procfs_target::make_corefile_notes): Change return type to unique pointer. * target-delegates.c: Re-generate. * gcore.c (write_gcore_file_1): Adjust. * target-debug.h (target_debug_print_gdb_unique_xmalloc_ptr_char): New. Change-Id: I768fb17ac0f7adc67d2fe95e952c784fe0ac37ab
* [gdb/symtab] Make find_block_in_blockvector more robustTom de Vries2020-10-222-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While working on PR25858 I noticed that the following trigger patch: ... @@ -2918,6 +2918,7 @@ find_pc_sect_compunit_symtab const struct blockvector *bv; bv = COMPUNIT_BLOCKVECTOR (cust); + (volatile int)blockvector_contains_pc (bv, pc); b = BLOCKVECTOR_BLOCK (bv, GLOBAL_BLOCK); if (BLOCK_START (b) <= pc ... triggers this assert, which checks that the returned block indeed contains pc: ... @@ -170,7 +170,10 @@ find_block_in_blockvector { b = BLOCKVECTOR_BLOCK (bl, bot); if (BLOCK_END (b) > pc) - return b; + { + gdb_assert (BLOCK_START (b) <= pc); + return b; + } bot--; } ... when running test-case gdb.ada/bp_c_mixed_case.exp. It's possible that the trigger patch breaks an undocumented invariant: I've tried a build and test run without the trigger patch and did not manage to trigger the assert. For robustness-sake, fix the assert by bailing out if 'BLOCK_START (b) <= pc' doesn't hold. Tested on x86_64-linux. gdb/ChangeLog: 2020-10-22 Tom de Vries <tdevries@suse.de> * block.c (find_block_in_blockvector): Make sure the returned block contains pc.
* gdb/dwarf: fix reading subprogram with DW_AT_specification (PR gdb/26693)Simon Marchi2020-10-224-6/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a regression introduced by commit 7188ed02d2a7 ("Replace dwarf2_per_cu_data::cu backlink with per-objfile map"). This patch targets both master and gdb-10-branch, since this is a regression from GDB 9. Analysis -------- The DWARF generated by the included test case looks like: 0x0000000b: DW_TAG_compile_unit DW_AT_language [DW_FORM_sdata] (4) 0x0000000d: DW_TAG_base_type DW_AT_name [DW_FORM_string] ("int") DW_AT_byte_size [DW_FORM_data1] (0x04) DW_AT_encoding [DW_FORM_sdata] (5) 0x00000014: DW_TAG_subprogram DW_AT_name [DW_FORM_string] ("apply") 0x0000001b: DW_TAG_subprogram DW_AT_specification [DW_FORM_ref4] (0x00000014 "apply") DW_AT_low_pc [DW_FORM_addr] (0x0000000000001234) DW_AT_high_pc [DW_FORM_data8] (0x0000000000000020) 0x00000030: DW_TAG_template_type_parameter DW_AT_name [DW_FORM_string] ("T") DW_AT_type [DW_FORM_ref4] (0x0000000d "int") 0x00000037: NULL 0x00000038: NULL Simply loading the file in GDB makes it crash: $ ./gdb -nx --data-directory=data-directory testsuite/outputs/gdb.dwarf2/pr26693/pr26693 [1] 15188 abort (core dumped) ./gdb -nx --data-directory=data-directory The crash happens here, where htab (a dwarf2_cu::die_hash field) is unexpectedly NULL while generating partial symbols: #0 0x000055555fa28188 in htab_find_with_hash (htab=0x0, element=0x7fffffffbfa0, hash=27) at /home/simark/src/binutils-gdb/libiberty/hashtab.c:591 #1 0x000055555cb4eb2e in follow_die_offset (sect_off=(unknown: 27), offset_in_dwz=0, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22951 #2 0x000055555cb4edfb in follow_die_ref (src_die=0x0, attr=0x7fffffffc130, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22968 #3 0x000055555caa48c5 in partial_die_full_name (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8441 #4 0x000055555caa4d79 in add_partial_symbol (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8469 #5 0x000055555caa7d8c in add_partial_subprogram (pdi=0x621000157e70, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8737 #6 0x000055555caa265c in scan_partial_symbols (first_die=0x621000157e00, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8230 #7 0x000055555ca98e3f in process_psymtab_comp_unit_reader (reader=0x7fffffffc6b0, info_ptr=0x60600009650d "\003int", comp_unit_die=0x621000157d10, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7614 #8 0x000055555ca9aa2c in process_psymtab_comp_unit (this_cu=0x621000155510, per_objfile=0x613000009f80, want_partial_unit=false, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7712 #9 0x000055555caa051a in dwarf2_build_psymtabs_hard (per_objfile=0x613000009f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8073 The special thing about this DWARF is that the subprogram at 0x1b is a template specialization described with DW_AT_specification, and has no DW_AT_name in itself. To compute the name of this subprogram, partial_die_full_name needs to load the full DIE for this partial DIE. The name is generated from the templated function name and the actual tempalate parameter values of the specialization. To load the full DIE, partial_die_full_name creates a dummy DWARF attribute of form DW_FORM_ref_addr that points to our subprogram's DIE, and calls follow_die_ref on it. This eventually causes load_full_comp_unit to be called for the exact same CU we are currently making partial symbols for: #0 load_full_comp_unit (this_cu=0x621000155510, per_objfile=0x613000009f80, skip_partial=false, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9238 #1 0x000055555cb4e943 in follow_die_offset (sect_off=(unknown: 27), offset_in_dwz=0, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22942 #2 0x000055555cb4edfb in follow_die_ref (src_die=0x0, attr=0x7fffffffc130, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22968 #3 0x000055555caa48c5 in partial_die_full_name (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8441 #4 0x000055555caa4d79 in add_partial_symbol (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8469 #5 0x000055555caa7d8c in add_partial_subprogram (pdi=0x621000157e70, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8737 #6 0x000055555caa265c in scan_partial_symbols (first_die=0x621000157e00, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8230 #7 0x000055555ca98e3f in process_psymtab_comp_unit_reader (reader=0x7fffffffc6b0, info_ptr=0x60600009650d "\003int", comp_unit_die=0x621000157d10, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7614 #8 0x000055555ca9aa2c in process_psymtab_comp_unit (this_cu=0x621000155510, per_objfile=0x613000009f80, want_partial_unit=false, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7712 #9 0x000055555caa051a in dwarf2_build_psymtabs_hard (per_objfile=0x613000009f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8073 load_full_comp_unit creates a cutu_reader for the CU. Since a dwarf2_cu object already exists for the CU, load_full_comp_unit is expected to find it and pass it to cutu_reader, so that cutu_reader doesn't create a new dwarf2_cu for the CU. And this is the difference between before and after the regression. Before commit 7188ed02d2a7, the dwarf2_per_cu_data -> dwarf2_cu link was a simple pointer in dwarf2_per_cu_data. This pointer was set up when starting the read the partial symbols. So it was already available at that point where load_full_comp_unit gets called. Post-7188ed02d2a7, this link is per-objfile, kept in the dwarf2_per_objfile::m_dwarf2_cus hash map. The entry is only put in the hash map once the partial symbols have been successfully read, when cutu_reader::keep is called. Therefore, it is _not_ set at the point load_full_comp_unit is called. As a consequence, a new dwarf2_cu object gets created and initialized by load_full_comp_unit (including initializing that dwarf2_cu::die_hash field). Meanwhile, the dwarf2_cu object created and used by the callers up the stack does not get initialized for full symbol reading, and the dwarf2_cu::die_hash field stays unexpectedly NULL. Solution -------- Since the caller of load_full_comp_unit knows about the existing dwarf2_cu object for the CU we are reading (the one load_full_comp_unit is expected to find), we can simply make it pass it down, instead of having load_full_comp_unit look up the per-objfile map. load_full_comp_unit therefore gets a new `existing_cu` parameter. All other callers get updated to pass `per_objfile->get_cu (per_cu)`, so the behavior shouldn't change for them, compared to the current HEAD. A test is added, which is the bare minimum to reproduce the issue. Notes ----- The original problem was reproduced by downloading https://github.com/oneapi-src/oneTBB/releases/download/v2020.3/tbb-2020.3-lin.tgz and loading libtbb.so in GDB. This code was compiled with the Intel C/C++ compiler. I was not able to reproduce the issue using GCC, I think because GCC puts a DW_AT_name in the specialized subprogram, so there's no need for partial_die_full_name to load the full DIE of the subprogram, and the faulty code doesn't execute. gdb/ChangeLog: PR gdb/26693 * dwarf2/read.c (load_full_comp_unit): Add existing_cu parameter. (load_cu): Pass existing CU. (process_imported_unit_die): Likewise. (follow_die_offset): Likewise. gdb/testsuite/ChangeLog: PR gdb/26693 * gdb.dwarf2/template-specification-full-name.exp: New test. Change-Id: I57c8042f96c45f15797a3848e4d384181c56bb44
* Fix gdb.base/msym*.exp failuresLuis Machado2020-10-223-5/+11
| | | | | | | | | | | | | | AArch64 generates functions without a prologue for these two testcases, therefore we shouldn't expect the function location to be displayed with an offset. gdb/testsuite/ChangeLog: 2020-10-22 Luis Machado <luis.machado@linaro.org> * gdb.base/msym-bp-shl.exp (test_break): Adjust pattern to not expected an offset from the function. * gdb.base/msym-bp.exp (test): Likewise.
* [PATCH][GAS][AArch64] Define BRBE system registersPrzemyslaw Wirkus2020-10-227-2/+531
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces BRBE (Branch Record Buffer Extension) system registers. Note: as this is register only extension we do not want to hide these registers behind -march flag going forward (they should be enabled by default). gas/ChangeLog: 2020-10-08 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> * NEWS: Docs update. * testsuite/gas/aarch64/brbe-invalid.d: New test. * testsuite/gas/aarch64/brbe-invalid.l: New test. * testsuite/gas/aarch64/brbe-invalid.s: New test. * testsuite/gas/aarch64/brbe.d: New test. * testsuite/gas/aarch64/brbe.s: New test. opcodes/ChangeLog: 2020-10-08 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> * aarch64-opc.c: Add BRBE system registers.
* aarch64: Define CSRE system registersPrzemyslaw Wirkus2020-10-227-1/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces CSRE (Call Stack Recorder Extension) system registers. Note: as this is register only extension we do not want to hide these registers behind -march flag going forward (they should be enabled by default). CSRE feature adds CSR PDEC (Decrements Call stack pointer by the size of a Call stack record) instruction. This instruction will be added in a following, separate patch. This change only adds CSRE system registers. gas/ChangeLog: 2020-10-08 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> * NEWS: Docs update. * testsuite/gas/aarch64/csre-invalid.d: New test. * testsuite/gas/aarch64/csre-invalid.l: New test. * testsuite/gas/aarch64/csre-invalid.s: New test. * testsuite/gas/aarch64/csre.d: New test. * testsuite/gas/aarch64/csre.s: New test. opcodes/ChangeLog: 2020-10-08 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> * aarch64-opc.c: New CSRE system registers defined.
* gold: Skip bootstrap-test/bootstrap-test-r for LTO buildH.J. Lu2020-10-223-4/+32
| | | | | | | | Skip bootstrap-test and bootstrap-test-r for LTO build due to different build IDs. * Makefile.am (bootstrap-test): Skip for LTO build. (bootstrap-test-r): Likewise.
* ld: Skip bootstrap tests for -fprofile-generate=H.J. Lu2020-10-224-17/+31
| | | | | | | | | | Make plug_opt available to all linker tests. Skip bootstrap tests when linker is compiled with -fprofile-generate=. * testsuite/ld-plugin/lto.exp (plug_opt): Moved to ... * testsuite/config/default.exp (plug_opt): Here. New. * testsuite/ld-bootstrap/bootstrap.exp: Skip when linker is compiled with -fprofile-generate=.
* Fix gdb.base/corefile2.exp regression when running Docker/AUFSLuis Machado2020-10-222-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following failures started showing up after commit bb2a67773c - "Use a std::vector in target_section_table": FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[0]@4 FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[pagesize-4]@4 FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[-3]@6 FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_rw[pagesize-3]@6 FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[pagesize-3]@6 I tracked it down to a problem in core_target::xfer_partial, at this point: if (!m_core_file_mappings.empty ()) xfer_status = xfer_memory_via_mappings (readbuf, writebuf, offset, len, xfered_len); else xfer_status = this->beneath ()->xfer_partial (object, annex, readbuf, writebuf, offset, len, xfered_len); It seems commit bb2a67773c uncovered a latent bug when handling a particular case where things are running within a Docker container using the AUFS storage driver. When building the file mappings for a core file, we call gdbarch_read_core_file_mappings, which in turn passes a couple lambda callbacks. One pre-loop and one in-loop. The catch is that commit bb2a67773c reworked the pre-loop lambda and made it do nothing. Before that commit, we always allocated m_core_file_mappings in that lambda. Now, when calling the in-loop lambda, we don't touch m_core_file_mappings because the bfd is nullptr (given Docker leaks the host system path, and that file doesn't exist within the container itself). So, instead, we add an entry to the m_core_unavailable_mappings vector. When we reach core_target::xfer_partial, we're only checking for an empty m_core_file_mappings. Given it is now empty, we take the path of reading the contents from the file, not the core file. This reads back unexpected results. The following patch fixes this by also checking for m_core_unavailable_mappings, given core_target::xfer_memory_via_mappings already handles the Docker/AUFS situation. gdb/ChangeLog: 2020-10-22 Luis Machado <luis.machado@linaro.org> * corelow.c (core_target::xfer_partial): Also check for an empty m_core_unavailable_mappings vector.
View Lorry Controller Status