The patch f2aec7f6d1 changed the return type of relocate_gdb_directory to
std::string, but the change is not reflected in find_charset_names function.
(Probably missed because the broken code is behind an #ifdef).
gdb/ChangeLog
* charset.c (find_charset_names): Reflect API change.
In the previous commit, I accidentally changed the wrong line;
this reverts it to what it should be.
gdb/ChangeLog:
2019-10-25 Christian Biesinger <cbiesinger@google.com>
* symtab.c (symbol_set_names): Revert unintentional change in the
Ada case.
Change-Id: I9abf174927687e74c7435bd4607aab7f248c6e79
We can just keep around the malloc()-ed name we got from bfd and free
it later.
gdb/ChangeLog:
2019-10-25 Christian Biesinger <cbiesinger@google.com>
* symtab.c (struct demangled_name_entry): Change demangled name
to a unique_xmalloc_ptr<char>, now that we don't allocate it as
part of the struct anymore.
(symbol_set_names): No longer obstack allocate + copy the demangled
name, just store the allocated name from bfd.
Change-Id: Ie6ad50e1e1e73509f55d756f0a437897bb93e3b0
Currently gdb has an assertion that requires CIEs to be read in the
order in which they appear in the debug info:
gdb_assert (n < 1
|| cie_table->entries[n - 1]->cie_pointer < cie->cie_pointer);
This assertion ensures that the table will be sorted, which is
important because it is later searched using bsearch.
However, a customer provided an executable that causes this assertion
to trigger. This executable causes decode_frame_entry_1 to call
decode_frame_entry to find the CIE, resulting in an out-of-order read.
I don't know a good way to construct a reproducer, but this can happen
if the FDE appears before its CIE. See
https://sourceware.org/bugzilla/show_bug.cgi?id=16563
This patch fixes the problem by storing CIEs in an unordered map. The
CIE table is discarded after the frame section is parsed, so this
seemed both simple and straightforward.
gdb/ChangeLog
2019-10-25 Tom Tromey <tromey@adacore.com>
* dwarf2-frame.c (dwarf2_cie_table): Now a typedef.
(bsearch_cie_cmp, add_cie): Remove.
(find_cie): Reimplement.
(decode_frame_entry_1, decode_frame_entry): Change type. Update.
(dwarf2_build_frame_info): Update.
Change-Id: I4a99597fa4b1398a9d105b683a36d992d506485c
gdbserver has its own implementation of xstrdup. However, because
gdbserver links against libiberty now, I think this is not needed.
This patch removes it.
gdb/gdbserver/ChangeLog
2019-10-25 Tom Tromey <tromey@adacore.com>
* utils.c (xstrdup): Remove.
Change-Id: I2aa56d18d0f9af8e70a00dff431d2fda5705a5d5
Make gdb_test_multiple calls shorter by using new gdb_test_multiple variable
$gdb_test_name and new gdb_test_multiple pattern flag -wrap.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-25 Tom de Vries <tdevries@suse.de>
* gdb.reverse/sigall-precsave.exp: Use -wrap and $gdb_test_name in
gdb_test_multiple calls.
* gdb.reverse/sigall-reverse.exp: Same.
* gdb.reverse/solib-precsave.exp: Same.
* gdb.reverse/solib-reverse.exp: Same.
* gdb.reverse/until-precsave.exp: Same.
* gdb.reverse/until-reverse.exp: Same.
Change-Id: I67bb327d069dbc439410996bcfe6c7f905b2ca52
Clear the stale source cache when re-reading symbols.
PR gdb/25126
* symfile.c (reread_symbols): Call forget_cached_source_info to
clear the stale source cache.
The only use of python_has_threads has been removed in
commit 404f29021a
gdb/ChangeLog:
2019-10-24 Christian Biesinger <cbiesinger@google.com>
* configure: Rebuild.
* configure.ac: Remove code that sets python_has_threads.
Change-Id: I75f1b873562bc2abc6f2db17699a3e82fcfd2de3
The version checking code is not necessary. It is only used to define
HAVE_LIBPYTHON2_6 or HAVE_LIBPYTHON2_7, which is not used anywhere.
If a version check is desired, the PY_{MAJOR,MINOR}_VERSION macro from
the Python headers can be (and is) used, which does not require updating
configure.ac whenever a new Python version is released.
gdb/ChangeLog:
2019-10-24 Christian Biesinger <cbiesinger@google.com>
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Remove the code that uses sed to get the python
version and defines HAVE_LIBPYTHON2_6 / HAVE_LIBPYTHON2_7.
Change-Id: I07073870d9040c2bc8519882c8b3c1368edd4513
Currently, in order to rewrite:
...
gdb_test <command> <pattern> <message>
...
using gdb_test_multiple, we get:
...
gdb_test_multiple <command> <message> {
-re "\[\r\n\]*(?:<pattern>)\[\r\n\]+$gdb_prompt $" {
pass $gdb_test_name
}
}
...
Add a '-wrap pattern flag to gdb_test_multiple, that wraps the regexp
pattern as gdb_test wraps its message argument.
This allows us to rewrite into the more compact:
...
gdb_test_multiple <command> <message> {
-re -wrap <pattern> {
pass $gdb_test_name
}
}
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-24 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_test_multiple): Add -wrap pattern flag.
* gdb.reverse/step-precsave.exp: Rewrite gdb_test_multiple containing
kfail using -wrap pattern flag and convenience variable
gdb_test_name.
Change-Id: Ie42c97d5ab7acf6db351299ccd23a83540fe6e1a
The documentation for Progspace.block_for_pc says:
Return the innermost gdb.Block containing the given pc value. If the
block cannot be found for the pc value specified, the function will
return None.
However, the implementation actually throws an error for invalid
addresses, like this:
(gdb) python print gdb.current_progspace ().block_for_pc (1)
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Cannot locate object file for block.
Error while executing Python code.
(gdb)
This has been the behaviour since the command was first added (when
the documentation was still as above) in this commit:
commit f3e9a8177c
Date: Wed Feb 24 21:18:28 2010 +0000
Since that commit the code in question has moved around, but the
important parts are largely unchanged. The function in question is
now in py-progspace.c:pspy_block_for_pc.
Examining the code shows that the real state is more complex than just
the function throws an error instead of returning None, instead the
real situation is:
1. If we can't find a compilation unit for the $pc value then we
throw an error, but
2. If we can find a compilation unit, but can't find a block within
the compilation unit for the $pc then return None.
I suspect for most users of the Python API this distinction is
irrelevant, and I propose that we standardise on one single failure
mechanism.
Given the function can currently return None in some cases, and is
documented to return None on error, I propose we make that the case
for all error paths, which is what this patch does.
As the Progspace.block_for_pc method is currently untested, I've added
some basic tests including for a call with an invalid $pc.
This is potentially an API breaking change, though an undocumented
part of the API. Also, users should have been checking and handling a
None return value anyway, so my hope is that this shouldn't be too
disruptive.
gdb/ChangeLog:
* python/py-progspace.c (pspy_block_for_pc): Return None for all
error paths.
gdb/testsuite/ChangeLog:
* gdb.python/py-progspace.exp: Add tests for the
Progspace.block_for_pc method.
Change-Id: I9cea8d2132902bcad0013d1fd39080dd5423cc57
Now that gdb can unconditionally use a -I pointing at the top of the
source tree, we can remove the ugly "../opcodes/" formulation that was
needed earlier. This patch adds the -I and cleans up these includes.
gdb/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* arc-tdep.c: Remove ".." from include.
* frv-tdep.c: Remove ".." from include.
* lm32-tdep.c: Remove ".." from include.
* microblaze-tdep.c: Remove ".." from include.
* or1k-tdep.h: Remove ".." from include.
* s12z-tdep.c: Remove ".." from include.
* Makefile.in (OPCODES_CFLAGS): Add comment.
(TOP_CFLAGS): New variable.
(INTERNAL_CFLAGS_BASE): Add TOP_CFLAGS.
Change-Id: I21428726d55f9fab0c9da90b56f6664f258cf91a
readline turns out to be a bit of a stumbling block for the project to
move gdbsupport (and then gdbserver) to the top-level.
The issue is that readline headers are intended to be included with
names like "readline/readline.h". To support this, gdb effectively
adds a -I option pointing to the top-level source directory -- but,
importantly, this option is not used when the system readline is used.
For gdbsupport, a -I option like this would always be needed, but that
in turn would break the system readline case. This was PR build/17077,
fixed in commit a8a5dbcab8.
Previously, we had discussed this on the gdb-patches list in terms of
removing readline from the tree
https://sourceware.org/ml/gdb-patches/2019-09/msg00317.html
However, Eli expressed some concerns, and Joel did as well (off-list).
Given those concerns, and the fact that a patch-free local readline is
relatively new in gdb (it was locally patched for years), I changed my
mind and decided to handle this situation by moving the readline
sources down a level.
That is, upstream readline is now in readline/readline, and the
top-level readline directory just contains the minimal configury
needed to build that.
This fixes the problem because, when gdb unconditionally adds a
-I$(top_srcdir), this will not find readline headers. A separate -I
will be needed instead, which is exactly what's needed for
--with-system-readline.
gdb/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* Makefile.in (READLINE_DIR): Update.
gdb/doc/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* Makefile.in (READLINE_DIR): Update.
readline/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
Move old contents to readline/ subdirectory.
* aclocal.m4, configure, configure.ac, .gitignore, Makefile.am,
Makefile.in, README: New files.
Change-Id: Ice156a2ee09ea68722b48f64d97146d7428ea9e4
Extract out the code region that reserves stack space to a separate
function.
Fix the comment of 'call_function_by_hand_dummy' to remove reference
to the NARGS argument that was removed in commit (e71585ffe2 "Use
gdb:array_view in call_function_by_hand & friends").
gdb/ChangeLog:
2019-10-23 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infcall.c (call_function_by_hand_dummy): Fix the function
comment. And extract out a code section into...
(reserve_stack_space): ...this new function.
Change-Id: I8938ef4134aff68a0a21724aaa2406bfe453438a
Remove the unused SP parameter from the auxiliary function
'value_arg_coerce'.
gdb/ChangeLog:
2019-10-23 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infcall.c (value_arg_coerce): Remove an unused parameter.
(call_function_by_hand_dummy): Update the call to
'value_arg_coerce'.
Change-Id: If324a1dda3fa5d4c145790b92bd3f656c00296f4
This is a refactoring that performs type assertions on the callee
function at the beginning of 'call_function_by_hand_dummy' rather than
at a later point so that
- the checks are grouped together at the beginning of the function for
improved readability, and
- we don't have to align and push things on the stack only to find out
later that the function call is illegal.
gdb/ChangeLog:
2019-10-23 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infcall.c (call_function_by_hand_dummy): Refactor.
Change-Id: I411ac083ac6a9ee6eb93c4b82393a81a4fc927be
It's not immediately obvious how to get the list of threads,
so add a note about that in the "Threads in Python" section.
gdb/doc/ChangeLog:
2019-10-23 Christian Biesinger <cbiesinger@google.com>
* python.texi (Threads In Python): Add a note for how to get the
list of threads.
Change-Id: I0fef8a7aff161fc347c09052319048c907a6e8c3
I noticed that gdbsupport uses HAVE_SIGPROCMASK, but common.m4 does
not check for it. This means that gdbserver may not compile some
gdbsupport code properly. This patch fixes this error.
gdb/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* configure.ac: Don't check for sigprocmask.
* gdbsupport/common.m4 (GDB_AC_COMMON): Check for sigprocmask.
gdb/gdbserver/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* configure, config.in: Rebuild.
Change-Id: I2c0a4dd2c376507b9483b38707a242382faa8163
Pedro pointed out that sinclude does not error if a file is missing.
This patch changes gdb to only use m4_include, which seems more
correct.
gdb/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* acinclude.m4: Use m4_include, not sinclude.
gdb/gdbserver/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* acinclude.m4: Use m4_include, not sinclude.
gdb/testsuite/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* aclocal.m4: Use m4_include, not sinclude.
Change-Id: I970362e0af7875f9f72796401126acf0ff6dba11
I run into this error with gdb.base/fullname.exp:
...
(gdb) file /data/gdb_versions/devel/build/gdb/testsuite/outputs/\
gdb.base/fullname/fullname
Reading symbols from /data/gdb_versions/devel/build/gdb/testsuite/outputs/\
gdb.base/fullname/fullname...
(gdb) break /data/gdb_versions/devel/build/gdb/testsuite/\
outputs/gdb.base/fullname/tmp-fullname.c:21
No source file named /data/gdb_versions/devel/build/gdb/testsuite/outputs/\
gdb.base/fullname/tmp-fullname.c.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) FAIL: gdb.base/fullname.exp: set breakpoint by full path before loading symbols - built relative
...
The FAIL is due to this comparison in iterate_over_some_symtabs failing:
...
481 if (FILENAME_CMP (real_path, fullname) == 0)
(gdb) p real_path
$2 = 0x1a201f0 "/data/gdb_versions/devel/build/gdb/testsuite/outputs/\
gdb.base/fullname/tmp-fullname.c"
(gdb) p fullname
$3 = 0x1a1de80 "/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/\
gdb.base/fullname/tmp-fullname.c"
...
The difference in pathnames is due to having a symlink dir:
...
$ ls -la /home/vries/gdb_versions
lrwxrwxrwx 1 vries users 18 26 jun 2018 /home/vries/gdb_versions -> /data/gdb_versions
...
and the test passses when eliminating it:
...
$ ( cd $(pwd -P); make check RUNTESTFLAGS=gdb.base/fullname.exp )
...
The FAIL is a regression from commit a0c1ffedcf "Only compute realpath when
basenames_may_differ is set". Before, find_and_open_source was returning a
real-path, resulting in variable 'fullname' being the same as varible
'real_path' in the comparison listed above. But after, that's no longer the
case.
Fix the FAIL by applying gdb_realpath on the fullname variable before the
comparison.
Tested on x86_64-linux.
I wasn't able to write a test-case. The FAIL starts at:
...
$ cd build/gdb
$ mv testsuite testsuite.bla
$ ln -s testsuite.bla testsuite
...
but already this doesn't trigger it anymore:
...
$ cd build/gdb/outputs
$ mv outputs outputs.bla
$ ln -s outputs.bla outputs
...
gdb/ChangeLog:
2019-10-23 Tom de Vries <tdevries@suse.de>
PR breakpoints/24687
* symtab.c (iterate_over_some_symtabs): Apply gdb_realpath on fullname.
Change-Id: I1ace62a234458781e958980f3b425edf1490df27
Having it as a bitfield causes extra work, and this is not memory-sensitive.
Furthermore, once https://sourceware.org/ml/gdb-patches/2019-10/msg00812.html
lands, the bitfield won't even save any memory at all.
gdb/ChangeLog:
2019-10-22 Christian Biesinger <cbiesinger@google.com>
* symtab.c (struct demangled_name_entry) <language>: Change from
bitfield to regular variable.
Change-Id: I4ea31d1cfcbe0f09a09bd058cd304862308dc388
I accidentally pushed the wrong version of the patch for commit
7bb4305982 (where the review
comments were not fixed), and I did a bad conflict resolution
for ccb1ba6229 leading to a
compile error when libxxhash is available. This fixes both
issues.
gdb/ChangeLog:
2019-10-22 Christian Biesinger <cbiesinger@google.com>
* symtab.c (struct demangled_name_entry): Add a constructor.
(free_demangled_name_entry): New function to call the destructor
for demangled_name_entry.
(create_demangled_names_hash): Pass free_demangled_name_entry to
htab_create_alloc.
(symbol_set_names): Call placement new for demangled_name_entry.
* utils.c: No longer include xxhash.h here, now that fast_hash
is inlined in the header.
* utils.h: Instead, include it here.
Change-Id: If776099d39a65a12733d42efcb859feca1b07a39
XXHash is faster than htab_hash_string:
------------------------------------------------------------
Benchmark Time CPU Iterations
------------------------------------------------------------
BM_xxh3 11 ns 11 ns 65887249
BM_xxh32 19 ns 19 ns 36511877
BM_xxh64 16 ns 16 ns 42964585
BM_hash_string 182 ns 182 ns 3853125
BM_iterative_hash 77 ns 77 ns 9087638
Unfortunately, XXH3 is still experimental (see
https://github.com/Cyan4973/xxHash#user-content-new-experimental-hash-algorithm)
However, regular XXH64 is still a lot faster than
htab_hash_string per my benchmark above. I used the
following string for the benchmark:
static constexpr char str[] = "_ZZZL13make_gdb_typeP7gdbarchP10tdesc_typeEN16gdb_type_creator19make_gdb_type_flagsEPK22tdesc_type_with_fieldsE19__PRETTY_FUNCTION__";
htab_hash_string is currently 4.35% + 7.98% (rehashing) of gdb
startup when attaching to Chrome's content_shell.
An additional 5.21% is spent in msymbol_hash, which does not use
this hash function. Unfortunately, since it has to lowercase the
string, it can't use this hash function.
BM_msymbol_hash 52 ns 52 ns 13281495
It may be worth investigating if strlen+XXHash is still faster than
htab_hash_string, which would make it easier to use in more places.
Debian ships xxhash as libxxhash{0,-dev}. Fedora ships it as xxhash-devel.
gdb/ChangeLog:
2019-10-22 Christian Biesinger <cbiesinger@google.com>
* Makefile.in: Link with libxxhash.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Search for libxxhash.
* utils.c (fast_hash): Use xxhash if present.
Change-Id: Icab218388b9f829522ed3977f04301ae6d4fc4ca
Also updates a caller in symtab.c. For now this just calls htab_hash_string
but the next patch will change it to xxhash, if available.
gdb/ChangeLog:
2019-10-22 Christian Biesinger <cbiesinger@google.com>
* utils.h (fast_hash): New function.
* symtab.c (hash_demangled_name_entry): Call new function
fast_hash.
Change-Id: I77cac0d9aa78fc65316a2af449f52edcae72dc9b
This should be a bit faster (because we can compare the size first),
but it is also a dependency for the next patch.
(3.47% of gdb startup time is spent in eq_demangled_name_entry when
attaching to Chrome's content_shell binary)
gdb/ChangeLog:
2019-10-22 Christian Biesinger <cbiesinger@google.com>
* symtab.c (struct demangled_name_entry): Change type of mangled
to gdb::string_view. Also adds a constructor that takes the
mangled name.
(hash_demangled_name_entry): Update.
(eq_demangled_name_entry): Update.
(free_demangled_name_entry): New function to call the destructor
now that this is not a POD anymore.
(create_demangled_names_hash): Pass free_demangled_name_entry to
htab_create_alloc.
(symbol_set_names): Update.
Change-Id: I24711ae2bcaa9e79ca89a6f8fda385d400419175
* Fix handling of file and directory indexes in line tables; in DWARF 5 the
indexes are zero-based. Make file_names field private to abstract this detail
from the clients. Introduce file_names, is_valid_file_index and
file_names_size methods. Reflect these changes in clients.
* Handle DW_FORM_data16 in read_formatted_entries; it is used to record MD5
of the file entries in DWARF 5.
* Fix a bug in line header parsing that calculates the length of the header
incorrectly. (Seemingly this manifests itself only in DWARF 5).
Tested with CC=/usr/bin/gcc (version 8.3.0) against master branch (also with
-gsplit-dwarf and -gdwarf-4 flags) and there was no increase in the set of
tests that fails. (gdb still cannot debug a 'hello world' program with DWARF 5,
so for the time being, this is all we care about).
This is part of an effort to support DWARF 5 in gdb.
gdb/ChangeLog:
* dwarf2read.c (dir_index): Change type.
(file_name_index): Likewise.
(line_header::include_dir_at): Change comment and implementation on
whether it is DWARF 5.
(line_header::is_valid_file_index): New function.
(line_header::file_name_at): Change comment and implementation on
whether it is DWARF 5.
(line_header::file_names): Change to private field renamed as
m_file_names and introduce a new accessor method.
(line_header::file_names_size): New method.
(line_header::include_dirs): Change to private field and rename as
m_include_dirs.
(dw2_get_file_names_reader): Define local var at a smaller scope and
reflect API change.
(dwarf2_cu::setup_type_unit_groups): Reflect API change.
(process_structure_scope): Likewise.
(line_header::add_include_dir): Change message and reflect renaming.
(line_header::add_file_name): Likewise.
(read_formatted_entries): Handle DW_FORM_data16.
(dwarf_decode_line_header): Fix line header length calculation.
(psymtab_include_file_name): Change comment and API.
(lnp_state_machine::m_file): Update comment and reflect type change.
(lnp_state_machine::record_line): Reflect type change.
(dwarf_decode_lines): Reflect API change.
(file_file_name): Likewise.
(file_full_name): Likewise.
After the switch to use std::sort, if GDB is compiled with the
-D_GLIBCXX_DEBUG=1 flag then we see an error when using sort_cmp (in
objfiles.c) to sort obj_section objects.
The problem is that std::sort checks that the condition !(a < a)
holds, and currently this is not true. GDB's sort_cmp is really
designed to sort lists in which no obj_section repeats, however, there
is some code in place to try and ensure we get a stable sort order if
there is a bug in GDB, unfortunately this code fails the above check.
By reordering some of the checks inside sort_cmp, it is pretty easy to
ensure that the !(a < a) condition holds.
I've not bothered to make this condition check optimal, like I said
this code is only in place to ensure that we get stable results if GDB
goes wrong, so I've made the smallest change needed to get the correct
behaviour.
After this commit I see no regressions when running GDB compiled with
-D_GLIBCXX_DEBUG=1.
gdb/ChangeLog:
* objfiles.c (sort_cmp): Ensure that !(a < a) holds true.
Change-Id: I4b1e3e1640865104c0896cbb6c3fdbbc04d9645b
I happened to notice that the tui_exec_info_content typedef is unused.
This patch removes it. Tested by rebuilding.
gdb/ChangeLog
2019-10-21 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.h (tui_exec_info_content): Remove typedef.
Change-Id: I768edc482366e830eb4528c799686bb27518cdcb
My earlier patch -- commit c5adaa192 ("Fix creation of stamp-h by
gdb's configure script") -- broke the creation of nm.h. In
particular, configure removes nm.h, so if you touch configure and
rebuild, nothing will re-create the link, breaking the build.
This patch fixes the bug, and also updates configure.ac to use
AC_CONFIG_LINKS, rather than the obsolete AC_LINK_FILES.
Finally, I noticed that gcore is in generated_files in the
Makefile.in. I think this is incorrect, as generated_files is only
needed for files that can be the target of a #include. So, this patch
removes it.
gdb/ChangeLog
2019-10-21 Tom Tromey <tom@tromey.com>
* configure.ac (nm.h): Conditionally create nm.h link. Subst
NM_H. Use AC_CONFIG_LINKS.
* configure: Rebuild.
* Makefile.in (NM_H): New variable.
(generated_files): Add NM_H. Remove gcore.
(nm.h, stamp-nmh): New targets.
Change-Id: I8dd539785d52455e85389425e4bb996c8a127a0e
As mentioned in commit 745ff14e6e "[gdb/tdep] Fix 'Unexpected register class'
assert in amd64_push_arguments", of the 12 KFAILs added there, 3 are KPASSing
with g++ 4.8.5.
The KPASSes are due to:
- gdb incorrectly expecting the second half of the result of function
rtn_str_struct_02_01 in register %rdx.
- rtn_str_struct_02_01 using %rdx as a temporary, thereby accidentally setting
it to the expected value.
Reduce the chance of hiding errors due accidental register settings by
compiling the test-case with -O2.
This fixes the KPASSes when applied on top of commit 745ff14e6e.
Tested on x86_64-linux.
Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1.
gdb/testsuite/ChangeLog:
2019-10-21 Tom de Vries <tdevries@suse.de>
* gdb.base/infcall-nested-structs.c: Add
__attribute__((noinline,noclone)) to all functions.
(call_all): Add missing variable initialization. Simplify return value.
(breakpt): Increment volatile variable, to prevent call from being
optimized out.
* gdb.base/infcall-nested-structs.exp: Compile with -O2.
Change-Id: Ic027e1c957fecd6686345639db99f5eaee3cdf05
I noticed an obsolete comment just before unlink_objfile, and then I
noticed that both unlink_objfile and put_objfile_before could be
static. This patch makes these changes, and also moves unlink_objfile
earlier, so that a forward declaration is not needed.
Tested by rebuilding.
gdb/ChangeLog
2019-10-20 Tom Tromey <tom@tromey.com>
* objfiles.h (unlink_objfile, put_objfile_before): Don't declare.
* objfiles.c (unlink_objfile): Move earlier. Now static. Remove
obsolete comment.
(put_objfile_before): Now static.
Change-Id: I1b5927a60fd1cc59bfc9c6761f61652a01ef13e0
This commit fixes two simple typos, one in gdb/symfile.c and the other
in gdb/i386-darwin-tdep.c. s/wether/whether/.
2019-10-19 Sergio Durigan Junior <sergiodj@redhat.com>
* symfile.c (init_entry_point_info): Fix typo.
* i386-darwin-tdep.c (darwin_dwarf_signal_frame_p): Fix typo.
Change-Id: I1fbb39c32009c61c862b6bd56ce12f24a9edb2c4
I happened to notice that "make" would always print:
CONFIG_HEADERS=config.h:config.in \
CONFIG_COMMANDS="default depdir" \
CONFIG_FILES= \
CONFIG_LINKS= \
/bin/sh config.status
config.status: creating config.h
config.status: config.h is unchanged
on every rebuild. This seems to have changed due to an autoconf
upgrade at some point in the past. In the autoconf gdb uses now, it
works to use AC_CONFIG_HEADERS and then create the stamp file via the
"commands" argument.
This patch also fixes up Makefile.in to use the new-style
config.status invocation. It's no longer necessary to pass the output
file names via environment variables.
gdb/ChangeLog
2019-10-17 Tom Tromey <tromey@adacore.com>
* configure: Rebuild.
* configure.ac: Use AC_CONFIG_HEADERS. Create stamp-h there, not
in AC_CONFIG_FILES invocation.
* Makefile.in (Makefile, data-directory/Makefile, stamp-h): Use
new-style config.status invocation.
gdb/gdbserver/ChangeLog
2019-10-17 Tom Tromey <tromey@adacore.com>
* configure: Rebuild.
* configure.ac: Use AC_CONFIG_HEADERS. Create stamp-h there, not
in AC_CONFIG_FILES invocation.
* Makefile.in (stamp-h, Makefile): Use new-style config.status
invocation.
Change-Id: Ia0530d1c5b9756812d29ddb8dc1062326155e61e
On openSUSE Leap 15.1, I get:
...
FAIL: gdb.fortran/module.exp: info variables -n
...
because the info variables command prints info also for init.c:
...
File init.c:^M
24: const int _IO_stdin_used;^M
...
while the regexps in the test-case only expect info for module.f90.
Fix this by extending the regexps.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-17 Tom de Vries <tdevries@suse.de>
* gdb.fortran/module.exp: Allow info variables to print info for files
other than module.f90.
Change-Id: I401d8018b121fc7343f6bc8b671900349462457f
I noticed that objfile::original_name could be a "const char *" rather
than a plain "char *". This patch implements this change. Tested by
rebuilding.
gdb/ChangeLog
2019-10-16 Tom Tromey <tom@tromey.com>
* objfiles.h (struct objfile) <original_name>: Now const.
Recent work from Tom Tromey to better handle variables with associated
copy relocations has fixed a Fortran issue where module variables
wouldn't show up in the output of 'info variables'.
This commit adds a test for this functionality to ensure it doesn't
get broken in the future.
gdb/testsuite/ChangeLog:
* gdb.fortran/module.exp: Extend with 'info variables' test.
Change-Id: I7306b1d0a9a72947fd48ad7a03f49df774d6573b
The board file cc-with-tweaks is used as the core for lots of other
board files, for example cc-with-gdb-index and cc-with-debug-names.
This commit extends cc-with-tweaks so that it will wrap the Fortran
compiler, allowing for more test coverage.
I tested all of the board files that make use of cc-with-tweaks
running the gdb.fortran/*.exp test set, and in some cases I did see
extra failures. The "standard" results are:
=== gdb Summary ===
# of expected passes 953
# of known failures 2
With board file 'cc-with-dwz-m':
=== gdb Summary ===
# of expected passes 903
# of unexpected failures 1
# of known failures 2
# of untested testcases 4
With board file 'dwarf4-gdb-index':
=== gdb Summary ===
# of expected passes 950
# of unexpected failures 3
# of known failures 2
With board file 'fission-dwp':
=== gdb Summary ===
# of expected passes 949
# of unexpected failures 4
# of known failures 2
Despite these extra failure I don't think this should prevent this
change going in as these failures presumably already exist in GDB.
gdb/testsuite/ChangeLog:
* boards/cc-with-tweaks.exp: Setup F90_FOR_TARGET and
F77_FOR_TARGET.
Change-Id: I06d412f94d0e119ad652dd6c20829f6705a54622
Saving the signal state is very slow (this patch is a 14% speedup). The
reason we need this code is because signal handler will leave the
signal blocked when we longjmp out of it. But in this case we can
just manually unblock the signal instead of taking the unconditional
perf hit.
gdb/ChangeLog:
2019-10-16 Christian Biesinger <cbiesinger@google.com>
* gdbsupport/gdb_setjmp.h (SIGSETJMP): Allow passing in the value to
pass on to sigsetjmp's second argument.
* cp-support.c (gdb_demangle): Unblock SIGSEGV if we caught a crash.
Change-Id: Ib3010966050c64b4cc8b47d8cb45871652b0b3ea
This is another fuzzer bug, gdb/23567. This time, the fuzzer has
specifically altered the size of .debug_str:
$ eu-readelf -S objdump
Section Headers:
[Nr] Name Type Addr Off Size ES Flags Lk Inf Al
[31] .debug_str PROGBITS 0000000000000000 0057116d ffffffffffffffff 1 MS 0 0 1
When this file is loaded into GDB, the DWARF reader crashes attempting
to access the string table (or it may just store a bunch of nonsense):
[gdb-8.3-6-fc30]
$ gdb -nx -q objdump
BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
Reading symbols from /path/to/objdump...
Segmentation fault (core dumped)
Nick has already committed a BFD patch to issue the warning seen above.
[gdb master 6acc1a0b]
$ gdb -BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
Reading symbols from /path/to/objdump...
(gdb) inf func
All defined functions:
File ./../include/dwarf2.def:
186: const
8 *>(.:
;'@�B);
747: const
8 *�(.:
;'@�B);
701: const
8 *�D �
(.:
;'@�B);
71: const
8 *(.:
;'@�B);
/* and more gibberish */
Consider read_indirect_string_at_offset_from:
static const char *
read_indirect_string_at_offset_from (struct objfile *objfile,
bfd *abfd, LONGEST str_offset,
struct dwarf2_section_info *sect,
const char *form_name,
const char *sect_name)
{
dwarf2_read_section (objfile, sect);
if (sect->buffer == NULL)
error (_("%s used without %s section [in module %s]"),
form_name, sect_name, bfd_get_filename (abfd));
if (str_offset >= sect->size)
error (_("%s pointing outside of %s section [in module %s]"),
form_name, sect_name, bfd_get_filename (abfd));
gdb_assert (HOST_CHAR_BIT == 8);
if (sect->buffer[str_offset] == '\0')
return NULL;
return (const char *) (sect->buffer + str_offset);
}
With sect_size being ginormous, the code attempts to access
sect->buffer[GINORMOUS], and depending on the layout of memory,
GDB either stores a bunch of gibberish strings or crashes.
This is an attempt to mitigate this by implementing a similar approach
used by BFD. In our case, we simply reject the section with the invalid
length:
$ ./gdb -nx -q objdump
BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
Reading symbols from /path/to/objdump...
warning: Discarding section .debug_str which has a section size (ffffffffffffffff) larger than the file size [in module /path/to/objdump]
DW_FORM_strp used without .debug_str section [in module /path/to/objdump]
(No debugging symbols found in /path/to/objdump)
(gdb)
Unfortunately, I have not found a way to regression test this, since it
requires poking ELF section headers.
gdb/ChangeLog:
2019-10-16 Keith Seitz <keiths@redhat.com>
PR gdb/23567
* dwarf2read.c (dwarf2_per_objfile::locate_sections): Discard
sections whose size is greater than the file size.
Change-Id: I896ac3b4eb2207c54e8e05c16beab3051d9b4b2f
This adds initial compile command support to the RISC-V port. This fixes
about 228 testsuite failures on a riscv64-linux machine. We need to get
the triplet right which is normally riscv64 or riscv32 instead of the
default riscv. Also, we need to get the compiler options right, since we
don't accept the default -m64 and -mcmodel=large options, so we need to
construct -march and -mabi options which are correct for the target. We
currently don't have info about all extensions used by the target, so this
may need to be adjusted later. For now, I'm assuming that we have all
extensions required by the linux platform spec.
gdb/
* riscv-tdep.c (riscv_gcc_target_options): New.
(riscv_gnu_triplet_regexp): New.
(riscv_gdbarch_init): Call set_gdbarch_gcc_triplet_options and
set_gdbarch_gnu_triplet_regexp.
Change-Id: I315ce8de7789ddf7bdd3b532f917519464941294
xml-builtin.c only has character arrays and no dependencies, so this
creates a simple header file for that purpose so that gdbserver
can include that instead of re-declaring xml_builtin.
Despite the name, feature_to_c.sh is already specific to xml_builtins
(it hardcodes the variable name), so making it always output the
include for xml-builtin.h seems fine.
gdb/ChangeLog:
2019-10-16 Christian Biesinger <cbiesinger@google.com>
* Makefile.in: Add xml-builtin.h.
* features/feature_to_c.sh: Add an include for xml-builtin.h
to ensure that the compiler checks that the types match.
* xml-builtin.h: New file.
* xml-support.c (fetch_xml_builtin): Add missing const.
* xml-support.h: Remove declaration of xml_builtins.
gdb/gdbserver/ChangeLog:
2019-10-16 Christian Biesinger <cbiesinger@google.com>
* server.c: Include xml-builtin.h.
(get_xml_features): Don't declare xml_builtins here.
Change-Id: I806ef0851c43ead90b545a11794e41f5e5178436
We currently have 12 KFAILS in gdb.base/infcall-nested-structs.exp for
PR tdep/25096.
A minimal version of the failure looks like this. Consider test.c:
...
struct s { int c; struct { int a; float b; } s1; };
struct s ref = { 0, { 'a', 'b' } };
int __attribute__((noinline,noclone)) check (struct s arg)
{ return arg.s1.a == 'a' && arg.s1.b == 'b' && arg.c == 0; }
int main (void)
{ return check (ref); }
...
When calling 'check (ref)' from main, we have '1' as expected:
...
$ g++ test.c -g ; ./a.out ; echo $?
1
...
But when calling 'check (ref)' from the gdb prompt, we get '0':
...
$ gdb a.out -batch -ex start -ex "p check (ref)"
Temporary breakpoint 1 at 0x400518: file test.c, line 8.
Temporary breakpoint 1, main () at test.c:8
8 { return check (ref); }
$1 = 0
...
The layout of struct s is this:
- the field c occupies 4 bytes at offset 0,
- the s1.a field occupies 4 bytes at offset 4, and
- the s1.b field occupies 4 bytes at offset 8.
When compiling at -O2, we can see from the disassembly of main:
...
4003f0: 48 8b 3d 31 0c 20 00 mov 0x200c31(%rip),%rdi \
# 601028 <ref>
4003f7: f3 0f 10 05 31 0c 20 movss 0x200c31(%rip),%xmm0 \
# 601030 <ref+0x8>
4003fe: 00
4003ff: e9 ec 00 00 00 jmpq 4004f0 <_Z5check1s>
...
that check is called with fields c and s1.a passed in %rdi, and s1.b passed
in %xmm0.
However, the classification in theclass (a variable representing the first and
second eightbytes, to put it in SYSV X86_64 psABI terms) in
amd64_push_arguments is incorrect:
...
(gdb) p theclass
$1 = {AMD64_INTEGER, AMD64_INTEGER}
...
and therefore the struct is passed using %rdi and %rsi instead of using %rdi
and %xmm0, which explains the failure.
The reason that we're misclassifying the argument in amd64_classify_aggregate
has to do with how nested struct are handled.
Rather than using fields c and s1.a for the first eightbyte, and using field
s1.b for the second eightbyte, instead field c is used for the first
eightbyte, and fields s1.a and s1.b are classified together in an intermediate
eightbyte, which is then used to merge with both the first and second
eightbyte.
Fix this by factoring out a new function amd64_classify_aggregate_field, and
letting it recursively handle fields of nested structs.
Tested on x86_64-linux.
Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1.
Tested with clang++ 5.0.2 (which requires removing additional_flags=-Wno-psabi
and adding additional_flags=-Wno-deprecated).
gdb/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR tdep/25096
* amd64-tdep.c (amd64_classify_aggregate_field): Factor out of ...
(amd64_classify_aggregate): ... here.
(amd64_classify_aggregate_field): Handled fiels of nested structs
recursively.
gdb/testsuite/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR tdep/25096
* gdb.base/infcall-nested-structs.exp: Remove PR25096 KFAILs.
Change-Id: Id55c74755f0a431ce31223acc86865718ae0c123
Atm, when executing gdb.base/infcall-nested-structs.exp on x86_64-linux, we get:
...
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-tc-tf: \
p/d check_arg_struct_02_01 (ref_val_struct_02_01)
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-ts-tf: \
p/d check_arg_struct_02_01 (ref_val_struct_02_01)
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-ti-tf: \
p/d check_arg_struct_02_01 (ref_val_struct_02_01)
=== gdb Summary ===
nr of expected passes 9255
nr of unexpected failures 3
nr of expected failures 142
...
The 3 FAILs are reported as PR tdep/25096.
The 142 XFAILs are for a gdb assertion failure, reported in PR tdep/24104,
which should have been KFAILs since there's a problem in gdb rather than in
the environment.
A minimal version of the assertion failure looks like this. Consider test.c:
...
struct s { struct { } es1; long f; };
struct s ref = { {}, 'f' };
int __attribute__((noinline,noclone)) check (struct s arg)
{ return arg.f == 'f'; }
int main (void)
{ return check (ref); }
...
When calling 'check (ref)' from main, we have '1' as expected:
...
$ g++ test3.c -g && ( ./a.out; echo $? )
1
...
But when calling 'check (ref)' from the gdb prompt, we get:
...
$ gdb a.out -batch -ex start -ex "p check (ref)"
Temporary breakpoint 1 at 0x4004f7: file test.c, line 8.
Temporary breakpoint 1, main () at test.c:8
8 { return check (ref); }
src/gdb/amd64-tdep.c:982: internal-error: \
CORE_ADDR amd64_push_arguments(regcache*, int, value**, CORE_ADDR, \
function_call_return_method): \
Assertion `!"Unexpected register class."' failed.
...
The assert happens in this loop in amd64_push_arguments:
...
for (j = 0; len > 0; j++, len -= 8)
{
int regnum = -1;
int offset = 0;
switch (theclass[j])
{
case AMD64_INTEGER:
regnum = integer_regnum[integer_reg++];
break;
case AMD64_SSE:
regnum = sse_regnum[sse_reg++];
break;
case AMD64_SSEUP:
gdb_assert (sse_reg > 0);
regnum = sse_regnum[sse_reg - 1];
offset = 8;
break;
default:
gdb_assert (!"Unexpected register class.");
}
...
}
...
when processing theclass[0], which is AMD64_NO_CLASS:
...
(gdb) p theclass
$1 = {AMD64_NO_CLASS, AMD64_INTEGER}
...
The layout of struct s is that the empty field es1 occupies one byte (due to
c++) at offset 0, and the long field f occupies 8 bytes at offset 8.
When compiling at -O2, we can see from the disassembly of main:
...
4003f0: 48 8b 3d 41 0c 20 00 mov 0x200c41(%rip),%rdi \
# 601038 <ref+0x8>
4003f7: e9 e4 00 00 00 jmpq 4004e0 <_Z5check1s>
4003fc: 0f 1f 40 00 nopl 0x0(%rax)
...
that check is called with field f passed in %rdi, meaning that the
classification in theclass is correct, it's just not supported in the loop in
amd64_push_arguments mentioned above.
Fix the assert by implementing support for 'AMD64_NO_CLASS' in that loop.
This exposes 9 more FAILs of the PR tdep/25096 type, so mark all 12 of them as
KFAIL.
Tested on x86_64-linux.
Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1. With 4.8.5, 3 of the 12 KFAILs
are KPASSing.
Tested with clang++ 5.0.2 (which requires removing additional_flags=-Wno-psabi
and adding additional_flags=-Wno-deprecated).
gdb/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR tdep/24104
* amd64-tdep.c (amd64_push_arguments): Handle AMD64_NO_CLASS in loop
that handles 'theclass'.
gdb/testsuite/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR tdep/24104
* gdb.base/infcall-nested-structs.exp: Remove XFAIL for PR tdep/24104.
Add KFAIL for PR tdep/25096.
Change-Id: I8b66345bbf5c00209ca75b1209fd4d60b36e9ede
With g++-4.8, I see:
...
(gdb) PASS: gdb.cp/local-static.exp: c++: print free_inline_func(void)
print 'S::method()'::S_M_s_var_int^M
No symbol "S_M_s_var_int" in specified context.^M
(gdb) FAIL: gdb.cp/local-static.exp: c++: print 'S::method()'::S_M_s_var_int
...
The variable is declared like this (showing pruned .ii):
...
void S::method ()
{
static int S_M_s_var_int = 4;
}
...
But the DWARF generated for the variable is encapsulated in an unnamed lexical
block:
...
<1><121>: Abbrev Number: 5 (DW_TAG_structure_type)
<122> DW_AT_name : S
...
<2><14f>: Abbrev Number: 6 (DW_TAG_subprogram)
...
<150> DW_AT_name : (indirect string, offset: 0x599): method
<156> DW_AT_linkage_name: (indirect string, offset: 0x517): \
_ZN1S6methodEv /* demangled: dS::method() */
...
<1><3f8>: Abbrev Number: 21 (DW_TAG_subprogram)
<3f9> DW_AT_specification: <0x14f>
...
<3fe> DW_AT_low_pc : 0x4004fc
<406> DW_AT_high_pc : 0x2c /* 0x400528 */
...
<2><418>: Abbrev Number: 17 (DW_TAG_formal_parameter)
<419> DW_AT_name : (indirect string, offset: 0x68a): this
...
<2><424>: Abbrev Number: 18 (DW_TAG_lexical_block)
<425> DW_AT_low_pc : 0x400508
<42d> DW_AT_high_pc : 0x1e /* 0x400526 */
<3><435>: Abbrev Number: 22 (DW_TAG_variable)
<436> DW_AT_name : (indirect string, offset: 0x29d): S_M_s_var_int
...
which has the effect that the variable is not addressable unless the program
counter is in the range of the lexical block.
This is caused by gcc PR debug/55541, which was fixed in gcc 5.
Mark in total 225 FAILs as XFAIL.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR testsuite/25059
* gdb.cp/local-static.exp (do_test): Add xfails for gcc PR debug/55541.
Change-Id: Ibe86707eecffc79f1bb474d7928ea7d0c39a00a2
Tom de Vries
Ali Tamur
Christian Biesinger
Tom Tromey
H.J. Lu
Andrew Burgess
Tom Tromey
Tankut Baris Aktemur
Simon Marchi
Sergio Durigan Junior
Keith Seitz
Jim Wilson