gdb 13.1 crashes while running the rust compiler's debugger tests.
The crash has a number of causes.
First, the rust compiler still uses the C++-like _Z mangling, but with
its own twist -- some hex digits added to the end of a symbol. So,
while gdb finds the correct name of "main":
(top-gdb) p name
$13 = 0x292e0c0 "rustc_gdb_1031745::main"
It isn't found in the minsyms, because C++ demangling yields:
[99] t 0x90c0 _ZN17rustc_gdb_10317454main17h5b5be7fe16a97225E section .text rustc_gdb_1031745::main::h5b5be7fe16a97225 zko06yobckx336v
This could perhaps be fixed. I also filed a new PR to suggest
preferring the linkage name of the main program.
Next, the rust compiler emits both a DW_TAG_subprogram and a
DW_TAG_namespace for "main". This happens because the file is named
"main.rs" -- i.e., the bug is specific to the source file name. The
crash also seems to require the nested function inside of 'main', at
least for me. The namespace always is generated, but perhaps this
changes the ordering in the DWARF.
When inside_main_func looks up the main symbol, it finds the namespace
symbol rather than the function. (I filed a bug about fixing gdb's
symbol tables -- long overdue.)
Meanwhile, as I think it's important to fix this crash sooner rather
than later, this patch changes inside_main_func to check that the
symbol that is found is LOC_BLOCK. This perhaps should have been done
in the first place, anyway.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30158
(cherry picked from commit 5f056fcb3d)
Some systems may install binutils headers into a system location
(e.g. /usr/local/include on FreeBSD) which may also include headers
for other external packages used by GDB such as zlib or zstd. If a
system include path such as /usr/local/include is added before local
include paths to directories within a clone or release tarball, then
headers from the external binutils package are used which can result
in build failures if the external binutils package is out of sync with
the version of GDB being built.
To fix, sort the include paths in INTERNAL_CFLAGS_BASE to add CFLAGS
for "local" componenets before external components.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30214
Reviewed-By: Tom Tromey <tom@tromey.com>
(cherry picked from commit a2fbb69038)
This commit changes gdb/version.in to 13.1.90.DATE-git.
This commit also makes the following changes in gdb/testsuite:
* gdb.base/default.exp: Change $_gdb_minor to 2.
The new DWARF indexer broke "start" for some languages.
For D, it is broken because, while the code in cooked_index_shard::add
specifically excludes Ada, it fails to exclude D. This means that the
C "main" will be detected as "main" here -- whereas what is intended
is for the code in find_main_name to use d_main_name to find the name.
The Rust compiler, on the other hand, uses DW_AT_main_subprogram.
However, the code in dwarf2_build_psymtabs_hard fails to create a
fully-qualified name, so the name always ends up as plain "main".
For D and Ada, a very simple approach suffices: remove the check
against "main" from cooked_index_shard::add. This also has the
benefit of slightly speeding up DWARF indexing. I assume this
approach will work for Pascal and Modula-2 as well, but I don't have a
way to test those at present.
For Rust, though, this is not sufficient. And, computing the
fully-qualified name in dwarf2_build_psymtabs_hard will crash, because
cooked_index_entry::full_name uses the canonical name -- and that is
not computed until after canonicalization.
However, we don't want to wait for canonicalization to be done before
computing the main name. That would remove any benefit from doing
canonicalization is the background.
This patch solves this dilemma by noticing that languages using
DW_AT_main_subprogram are, currently, disjoint from languages
requiring canonicalization. Because of this, we can add a parameter
to full_name to let us avoid crashes, slowdowns, and races here.
This is kind of tricky and ugly, so I've tried to comment it
sufficiently.
While doing this, I had to change gdb.dwarf2/main-subprogram.exp. A
different possibility here would be to ignore the canonicalization
needs of C in this situation, because those only affect certain types.
However, I chose this approach because the test case is artificial
anyhow.
A long time ago, in an earlier threading attempt, I changed the global
current_language to be a function (hidden behind a macro) to let us
attempt lazily computing the current language. Perhaps this approach
could still be made to work. However, that also seemed rather tricky,
more so than this patch.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30116
(cherry picked from commit 47fe57c928)
PR build/30108 concerns building gdb documentation with
--with-sytem-readline. If the in-tree readline directory is
missing, though, the docs will fail to build:
make[4]: Entering directory '/home/keiths/work/readline-doc-issue/linux/gdb/doc'
make[4]: *** No rule to make target '../../../src/gdb/doc/../../readline/readline/doc/rluser.texi', needed by 'gdb.info'. Stop.
The listed file (and hsuser.texi) are conditionally included by gdb.texinfo.
When system readline is used, gdb/configure.ac will leave
READLINE_TEXI_INCFLAGS empty, causing doc/Makefile.in to output a line to
$BUILD/doc/GDBvn.texi with "@set SYSTEM_READLINE". This surpresses the
inclusion of the missing files. They are not needed or used in this
scenario.
However, GDB_DOC_SOURCE_INCLUDES always lists these two files as dependencies,
thus provoking the build error whenever readline/ is missing.
This patch fixes this by creating (essentially) a conditional setting of the
dependencies to be included from readline.
* Makefile.am (CLEANFILES): Import patch from upstream to prevent
allocafail.sh from being removed when running 'make clean'.
(cherry picked from commit edf64cd235)
