If we happen to get the fixed and variable parts of the advance_loc
in different frags, bad things happen when subtracting one from a
fr_fix of zero.
PR 25125
* dw2gencfi.c (output_cfi_insn): Don't allow DW_CFA_advance_loc4
to be placed in a different frag to the rs_cfa.
Makes sure that the string is longer than prefix, so that strncmp will
do the right thing even if the string is not null-terminated.
For use in my string_view conversion patch:
https://sourceware.org/ml/gdb-patches/2019-10/msg00030.htmlhttps://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/125
gdb/ChangeLog:
2019-10-28 Christian Biesinger <cbiesinger@google.com>
* gdbsupport/common-utils.h (startswith): Add an overloaded version
that takes gdb::string_view arguments.
Change-Id: I5389855de2fd70e7065a789a79374b0693651b71
* tic30-dis.c (OPERAND_BUFFER_LEN): Define. Use as length of
operand buffer. Set value to 15 not 13.
(get_register_operand): Use OPERAND_BUFFER_LEN.
(get_indirect_operand): Likewise.
(print_two_operand): Likewise.
(print_three_operand): Likewise.
(print_oar_insn): Likewise.
* ns32k-dis.c (bit_extract): Add sanitiy check of parameters.
(bit_extract_simple): Likewise.
(bit_copy): Likewise.
(pirnt_insn_ns32k): Ensure that uninitialised elements in the
index_offset array are not accessed.
These can be generated when multiple cfi directives are emitted for an
instruction and the insn frag is closed off between directives, as
happens when listings are enabled. No doubt the advance_loc of zero
could be avoided by backtracking over frags in dw2gencfi.c before
calling cfi_add_advance_loc, but that seems like more work than
cleaning up afterwards as this patch does.
Noticed when looking at the testcase in PR25125.
PR 25125
* dw2gencfi.c (output_cfi_insn): Don't output DW_CFA_advance_loc+0.
* ehopt.c (eh_frame_estimate_size_before_relax): Return -1 for
an advance_loc of zero.
(eh_frame_relax_frag): Translate fr_subtype of 7 to size -1.
(eh_frame_convert_frag): Handle fr_subtype of 7. Abort on
unexpected fr_subtype.
Since BYTE_PUT is defined as
#define BYTE_PUT(field, val) byte_put (field, val, sizeof (field))
use byte_put, instead of BYTE_PUT, to put 4-byte bitmask at ptr with
"byte_put (ptr, bitmask, 4)", instead of "BYTE_PUT (ptr, bitmask)", to
work with "unsigned char *ptr".
* elfedit.c (update_gnu_property): Replace BYTE_PUT with byte_put.
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
* objcopy.c (struct merged_note_section): New structure. Used to
chain together details of mergeable note sections.
(is_merged_note_section): Rename to is_megreable_note_section and
return true for note sections that use GNU_BUILD_ATTRS_SECTION_NAME
as a prefix.
(num_bytes): Delete
(objcoopy_internal_note): Add padded_namesz field.
(DEBUG_MERGE): New macro. Set to non-zero to enable debugging of
the note merging code.
(gap_exists): Rename to overlaps_or_adjoins and return TRUE for
overlapping notes or adjoining notes.
(contained_by, is_deleted_note, is_version_note)
(compare_gnu_build_notes, sort_gnu_build_notes): New functions.
(merge_gnu_build_notes): Rework. Sort notes into a mergeable
order first. Merge them. Then sort them into an ascending
address order before writing them out.
(copy_object): Handle more than one mergeable note section.
* testsuite/binutils-all/note-2-32.d: Update for new merging
behaviour.
* testsuite/binutils-all/note-2-32.s: Likewise.
* testsuite/binutils-all/note-2-64.d: Likewise.
* testsuite/binutils-all/note-2-64.s: Likewise.
* testsuite/binutils-all/note-3-32.d: Likewise.
* testsuite/binutils-all/note-3-32.s: Likewise.
* testsuite/binutils-all/note-3-64.d: Likewise.
* testsuite/binutils-all/note-3-64.s: Likewise.
* testsuite/binutils-all/note-4-32.d: Likewise.
* testsuite/binutils-all/note-4-32.s: Likewise.
* testsuite/binutils-all/note-4-64.d: Likewise.
* testsuite/binutils-all/note-4-64.s: Likewise.
* testsuite/binutils-all/note-6-32.s: New test source file.
* testsuite/binutils-all/note-6-64.s: New test source file.
* testsuite/binutils-all/note-6-32.d: New test driver file.
* testsuite/binutils-all/note-6-64.d: New test driver file.
* testsuite/binutils-all/objcopy.exp: Run the new test.
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
The patch I made for PR12049 didn't test for a "negative" branch
properly. "if (target < address)" ought to have been
"if (target < address + fragP->fr_fix)". Rather than making that
change, this patch adds fragP->fr_fix into address earlier. The patch
also avoids running into a bad interaction with the m68k
md_prepare_relax_scan by returning zero growth immediately, since the
adjusted target expression would result in a zero "aim".
PR gas/25125
PR gas/12049
* write.c (relax_frag): Correct calculation of delta for
positive branches where "stretch" would make the branch
negative. Return zero immediately in that case. Correct
TC_PCREL_ADJUST comment.
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
This rewrites much of assign_file_positions_for_non_load_sections to
allow objcopy and strip to handle cases like that in PR4499 where
program headers were not in their usual position immediately after the
ELF file header, and PT_LOAD headers were not sorted by paddr.
PR 4499
include/
* elf/internal.h (struct elf_segment_map): Delete header_size.
Add no_sort_lma and idx.
bfd/
* elf-nacl.c (nacl_modify_segment_map): Set no_sort_lma for all
PT_LOAD segments.
* elf32-spu.c (spu_elf_modify_segment_map): Likewise on overlay
PT_LOAD segments.
* elf.c (elf_sort_segments): New function.
(assign_file_positions_except_relocs): Use shortcuts to elfheader
and elf_tdata. Seek to e_phoff not sizeof_ehdr to write program
headers. Move PT_PHDR check..
(assign_file_positions_for_non_load_sections): ..and code setting
PT_PHDR p_vaddr and p_paddr, and code setting __ehdr_start value..
(assign_file_positions_for_load_sections): ..to here. Sort
PT_LOAD headers. Delete header_pad code. Use actual number of
headers rather than allocated in calculating size for program
headers. Don't assume program headers follow ELF file header.
Simplify pt_load_count code. Only set "off" for PT_LOAD or
PT_NOTE in cores.
(rewrite_elf_program_header): Set p_vaddr_offset for segments
that include file and program headers.
(copy_elf_program_header): Likewise, replacing header_size code.
When PT_PHDR isn't covered by a PT_LOAD header, p_vaddr in PT_PHDR
isn't valid but the value might just pass a vaddr test. So test
p_offset as well.
* readelf.c (process_program_headers): Check PT_PHDR p_offset
as well as p_vaddr. Use p_filesz, not p_memsz, in vaddr test.
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
