Convert dwarf2_per_objfile::die_type_hash, which maps debug info
offsets to `type *`, to gdb::unordered_map.
Change-Id: I5c174af64ee46d38a465008090e812acf03704ec
Convert one use of htab_t, mapping (unrelocated) pc to call_site
objects, to `gdb::unordered_map<unrelocated_addr, call_site *>`.
Change-Id: I40a0903253a8589dbdcb75d52ad4d233931f6641
Convert one use of htab_t, mapping offsets to die_info object, to
`gdb::unordered_map<sect_offset, die_info *>`.
Change-Id: Ic80df22bda551e2d4c2511d167e057f4d6cd2b3e
This converts the BFD cache in gdb_bfd.c to use the new hash table.
Change-Id: Ib6257fe9d4f7f8ef793a2c82d53935a8d2c245a3
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts more code in the DWARF reader to use the new hash table.
Change-Id: I86f8c0072f0a09642de3d6f033fefd0c8acbc4a3
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts gdb_bfd.c to use the new hash table for all_bfds.
This patch slightly changes the htab_t pretty-printer test, which was
relying on all_bfds. Note that with the new hash table, gdb-specific
printers aren't needed; the libstdc++ printers suffice -- in fact,
they are better, because the true types of the contents are available.
Change-Id: I48b7bd142085287b34bdef8b6db5587581f94280
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts the typedef hash to use the new hash table.
This patch found a latent bug in the typedef code. Previously, the
hash function looked at the type name, but the hash equality function
used types_equal -- but that strips typedefs, meaning that equality of
types did not imply equality of hashes. This patch fixes the problem
and updates the relevant test.
Change-Id: I0d10236b01e74bac79621244a1c0c56f90d65594
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts the DWARF abbrevs themselves to use the new hash table.
Change-Id: I0320a733ecefe2cffeb25c068f17322dd3ab23e2
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts the DWARF abbrev cache to use the new hash table.
Change-Id: I5e88cd4030715954db2c43f873b77b6b8e73f5aa
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts gnu-v3-abi.c to use the new hash table.
This change shows how a std::vector can easily be made directly from
the hash table, simplifying the earlier approach of constructing a
vector and a hash table at the same time.
Change-Id: Ia0c387a035a52300db6b6f5a3a2e5c69efa01155
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts the objfile static link table to the new hash map.
Change-Id: If978e895679899ca2af4ef01c12842b4184d88e6
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts the type copying code to use the new hash map.
Change-Id: I35f0a4946dcc5c5eb84820126cf716b600f3302f
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts compile/compile.c to use the new hash table.
Change-Id: I7df3b8d791ece731ae0d1d64cdc91a2e372f5d4f
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts py-framefilter.c to use the new hash table.
Change-Id: I38f4eaa8ebbcd4fd6e5e8ddc462502a92bf62f5e
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts dwarf2/macro.c to use the new hash table.
Change-Id: I6af0d1178e2db330fe3a89d57763974145ed17c4
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts target-descriptions.c to use the new hash table.
Change-Id: I03dfc6053c9856c5578548afcfdf58abf8b7ec2c
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts linespec.c to use the new hash table.
Note that more simplification could perhaps be done. Currently, the
collectors in this code insert an element into a set and then, if the
element has not been seen before, append it to a vector. If we know
the order does not matter, or if the results can be sorted later, we
could dispense with the vector. This would simplify the code some
more. (This technique is used in the vtable patch, later in this
series.)
Change-Id: Ie6828b1520d918d189ab5140dc8094a609152cf2
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts filename-seen-cache.h to use the new hash table.
filename-seen-cache.c is removed.
Change-Id: Iffac1d5e49d1610049b7deeef6e98d49e644366a
Co-Authored-By: Tom Tromey <tom@tromey.com>
This converts compile-c-symbols.c to use the new hash table.
I made it use a set of string_view instead of a set of `symbol *`, to
avoid calling `symbol::natural_name` over and over. This appears safe
to do, since I don't expect the storage behing the natural names to
change during the lifetime of the map.
Change-Id: Ie9f9334d4f03b9a8ae6886287f82cd435eee217c
Co-Authored-By: Tom Tromey <tom@tromey.com>
Add a copy of unordered_dense.h from [1]. This file implements an
efficient hash map and hash set with a nice C++ interface (a near
drop-in for std::unordered_map and std::unordered_set). This is
expected to be used to replace uses of `htab_t`, for improved code
readability and type safety. Performance-wise, it is preferred to the
std types (std::unordered_map and std::unordered_set) due to it using
open addressing vs closed addressing for the std types.
I chose this particular implementation because it is simple to use, it's
a standalone header and it typically performs well in benchmarks I have
seen (e.g. [2]). The license being MIT, my understanding is that it's
not a problem to use it and re-distribute it.
Add two additional files, gdbsupport/unordered_map.h and
gdbsupport/unordered_set.h, which make the map and set offered by
gdbsupport/unordered_dense.h available as gdb::unordered_map and
gdb::unordered_set.
[1] https://github.com/martinus/unordered_dense
[2] https://jacksonallan.github.io/c_cpp_hash_tables_benchmark/#conclusion-which-hash-table-to-choose
Change-Id: I0c7469ccf9a14540465479e58b2a5140a2440a7d
To determine whether SAE (with or without StaticRounding) is permitted
there's no need to iterate over all operands. Even less so starting at
the front (thus needlessly inspecting immediate operands as well).
Leverage the pattern across all relevant templates and check only the
last two operands, and also only for non-512 ones (besides the non-LIG
case that was already checked for).
riscv_handle_align() runs after all input was processed. Whether
relaxation is enabled for any particular piece of code is not recorded
anywhere. (This issue was even "worked around" in a gas testcase, which
is adjusted accordingly.) Furthermore, as demonstrated by an ld
testcase, tail padding in an object file's executable sections depended
on whether relaxation was enabled at the end of assembly: NOPs were
emitted only when relaxation was off; zeroes were emitted with
relaxation enabled. (It could probably be either way, but it should be
independent of relaxation state at the end of assembly. Except of course
write.c, in a comment ahead of #define-ing SUB_SEGMENT_ALIGN(),
explicitly says "proper nop-filling".)
While re-indenting, drop the "odd_padding" variable. It's used exactly
once, and having the actual expression right in the if() is imo helping
readers to understand what the intentions are.
While touching the ld testcase, also tighten the expectations for the
addresses of the two symbols: The last two digits have to have fixed
values.
Add a test for PR ld/32083 and xfail the test for GCC without the fix:
commit a98dd536b1017c2b814a3465206c6c01b2890998
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Wed Aug 21 07:25:25 2024 -0700
Update LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook
PR ld/32083
* testsuite/ld-plugin/common-2a.c: New file.
* testsuite/ld-plugin/common-2b.c: Likewise.
* testsuite/ld-plugin/lto.exp: Run PR ld/32083 test.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
With the test-case included in this patch, we run into:
...
$ gdb -q -batch $exec
Dwarf Error: Could not find abbrev number 3 in CU at offset 0xdb \
[in module $exec]
...
The debug info consists of two CUs:
...
Compilation Unit @ offset 0xb2:
Length: 0x25 (32-bit)
Version: 4
Abbrev Offset: 0x6c
Pointer Size: 8
<0><bd>: Abbrev Number: 1 (DW_TAG_compile_unit)
<be> DW_AT_language : 2 (non-ANSI C)
<1><bf>: Abbrev Number: 2 (DW_TAG_subprogram)
<c0> DW_AT_low_pc : 0x4004a7
<c8> DW_AT_high_pc : 0x4004b2
<d0> DW_AT_specification: <0xe8>
<1><d4>: Abbrev Number: 3 (DW_TAG_subprogram)
<d5> DW_AT_name : main
<1><da>: Abbrev Number: 0
Compilation Unit @ offset 0xdb:
Length: 0xf (32-bit)
Version: 4
Abbrev Offset: 0x86
Pointer Size: 8
<0><e6>: Abbrev Number: 1 (DW_TAG_compile_unit)
<e7> DW_AT_language : 2 (non-ANSI C)
<1><e8>: Abbrev Number: 2 (DW_TAG_subprogram)
<e9> DW_AT_specification: <0xd4>
<1><ed>: Abbrev Number: 0
...
where:
- DIE 0xbf in CU@0xb2 contains an inter-CU reference to
- DIE 0xe8 in CU@0xdb, which contains an inter-CU reference to
- DIE 0xd4 back in CU@0xb2.
The dwarf error is caused by this bit of code in
cooked_indexer::ensure_cu_exists:
...
if (per_cu == m_per_cu)
return reader;
...
The dwarf error happens as follows:
- a cutu_reader A is created for CU@0xb2
- using cutu_reader A, the cooked index reader starts indexing dies, with
m_per_cu set to CU@0xb2
- while indexing it scans the attributes of DIE 0xbf and encounters the
inter-CU reference to DIE 0xe8
- it calls cooked_indexer::ensure_cu_exists, which creates a cutu_reader B for
CU@0xdb and returns it
- using cutu_reader B, it continues scanning attributes of DIE 0xe8 and
encounters the inter-CU reference to DIE 0xd4
- it calls cooked_indexer::ensure_cu_exists, the problematic bit is triggered
and cutu_reader B is returned
- using cutu_reader B, it continues scanning attributes of DIE 0xd4
- this goes wrong because:
- the attributes of the DIE are encoded using the abbreviation table at
offset 0x6c, while
- the decoding is done using cutu_reader B which uses the abbreviation table
at offset 0x86.
Fix this by removing the problematic if clause.
Since cutu_reader A is not preserved in m_index_storage,
cooked_indexer::ensure_cu_exists cannot find it there and creates a duplicate
cutu_reader C for CU@0xb2. Fix this in process_psymtab_comp_unit by preserving
the cutu_reader A as well in m_index_storage.
Tested on x86_64-linux and aarch64-linux.
PR symtab/32081
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32081
Approved-By: Tom Tromey <tom@tromey.com>
Reported-By: Andreas Schwab <schwab@linux-m68k.org>
I did a review of lines containing "catch (gdb_exception" and found a few
where we can add const.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
In type_to_type_object we have:
...
try
{
if (type->is_stub ())
type = check_typedef (type);
}
catch (...)
{
/* Just ignore failures in check_typedef. */
}
...
The catch is supposed to ignore gdb_exception_error, but it ignores any
exception.
Fix that by only ignoring gdb_exception_error, and handling
gdb_exception_quit / gdb_exception_forced_quit using GDB_PY_HANDLE_EXCEPTION.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
In svr4_handle_solib_event I noticed:
...
catch (const gdb_exception_error)
...
This seems to be the only place were we do this, elsewhere we have:
...
catch (const gdb_exception_error &)
...
I suppose the intent of adding '&' is to avoid a copy. I'm not sure if it's
necessary given that it's an unnamed const parameter, but I suppose it can't
hurt either.
Add the '&' here as well.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
In get_test_insn in gdb/disasm-selftests.c, we find this code:
...
try
{
kind = gdbarch_breakpoint_kind_from_pc (gdbarch, &pc);
insn = gdbarch_sw_breakpoint_from_kind (gdbarch, kind, &bplen);
}
catch (...)
{
continue;
}
...
The catch is there to catch memory errors, but it swallows all exceptions, including
gdb_exception_quit and gdb_exception_forced_quit.
Fix this by limiting the catch to gdb_exception_error.
Tested on x86_64-linux, by rebuilding and running gdb.gdb/unittest.exp.
Approved-By: Tom Tromey <tom@tromey.com>
Some refactors around struct global_block, all in one patch because they
all tie in together and are relatively trivial.
- Make block::global_block() and blockvector::global_block() return
`global_block *`, instead of `block *`. There is no cost in doing
so, and it's a bit more precise. Callers of these methods that need
a `global_block *` won't need to cast themselves.
- Add some block::as_global_block methods, as a way to get a
`global_block *` from a `block *` when you know it's a global block.
This is basically a static cast with an assert.
- Move set_compunit_symtab to global_block, since it requires the
block to be a global block anyway. Rename to just `set_compunit` (I
think that compunit_symtab should just be renamed compunit...).
- Move the get_block_compunit_symtab free function to be a method of
global_block.
- Make global_block::compunit_symtab private and rename.
- Simplify initialize_block_iterator.
Change-Id: I1667a86b5c1a02d0d460cfad55b5d3d48867583d
Approved-By: Tom Tromey <tom@tromey.com>
dwarf2/read.c has this code:
else if (elf_section_data (sectp)->this_hdr.sh_size
> bfd_get_file_size (abfd))
This assumes that the BFD is an ELF, which is an invalid assumption.
A user noticed that this can sometimes cause a crash.
This patch fixes the problem by changing this code to use
bfd_section_size_insane.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32104
Reviewed-By: Tom de Vries <tdevries@suse.de>
Reviewed-by: Keith Seitz <keiths@redhat.com>
It was pointed out in this email:
https://inbox.sourceware.org/gdb-patches/97973506-79f4-4216-9c0b-57401b3933f5@arm.com
that this commit:
commit 0726729d34
Date: Mon Jun 3 13:56:54 2024 +0100
gdb/testsuite: track if a caching proc calls gdb_exit or not
had broken some AArch64 tests.
What is going on is that there are two caching procs:
allow_aarch64_sme_tests
aarch64_initialize_sme_information
the allow_aarch64_sme_tests proc makes a call to
aarch64_initialize_sme_information, but
aarch64_initialize_sme_information is also called from other
non-caching procs, like aarch64_supports_sme_svl.
Both of the caching procs mentioned above compile and run a helper
program, and both of them call gdb_exit.
After the above commit, the first call to any caching proc, the body
of which calls gdb_exit, will result in a gdb_exit call even if the
body is not executed and the result is fetched from the cache.
What was observed is that in the first test script
allow_aarch64_sme_tests is called, the body of this caching proc is
run which calls gdb_exit. Then allow_aarch64_sme_tests calls
aarch64_initialize_sme_information, the body of which is run and
gdb_exit is called again. The results from both procs are added to
the cache.
In the next test script allow_aarch64_sme_tests is called. This
results in a cache hit, but gdb_exit is also called as this is the
first call in this second test script.
Later in the test script aarch64_supports_sme_svl is called which
calls aarch64_initialize_sme_information. As this is the first call
to aarch64_initialize_sme_information in this second test
script (remember the body of allow_aarch64_sme_tests was never run)
then gdb_exit is called. This call to gdb_exit is new after the above
commit and is unexpected.
I think the idea behind the above commit is still sound. If the call
to allow_aarch64_sme_tests was removed from the second test script
then we would want the extra gdb_exit call as this would expose a real
bug in the test. The problem is that after the above commit the
nested nature of the caching proc calls becomes important: a call to
allow_aarch64_sme_tests should mean that we've also called
aarch64_initialize_sme_information, and that relationship isn't
currently captured.
So in this commit I'm adding another field to the global
gdb_data_cache (in lib/cache.exp). This new field is 'also_called'.
For every caching proc we populate this field with a list of names,
these are the names of any nested caching procs that are called when
the body of a caching proc is executed.
Now when we get a cache hit in gdb_data_cache we mark every proc in
the 'also_called' list as having been called. This means that further
calls to these procs will no longer trigger a gdb_exit call.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
commit cb9f919f ("gdb: add program_space parameter to
lookup_minimal_symbol_text") caused a crash on Windows. In this
function, section can be nullptr, but it is unconditionally
dereferenced by the change introduced by the patch.
I tested this using the AdaCore internal test suite.
v2: always use current_program_space, reverting to be behavior before
cb9f919f.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
While working on another bug, I noticed that the Ada code to find
exception symbols uses SEARCH_VFT. This will find variables and types
-- but only functions are needed here. This patch changes the code to
use SEARCH_FUNCTION_DOMAIN.
Tested on x86-64 Fedora 38, using a version of GNAT with the debuginfo
installed, to ensure the exception-related tests work.
Reviewed-by: Keith Seitz <keiths@redhat.com>
When running test-case gdb.python/py-mi-cmd.exp with python 3.13, I run into:
...
Expecting: ^(-pycmd exp[^M
]+)?(.*&"Traceback \(most recent call last\):.."^M
&"[^^M
]+py-mi-cmd.py[^^M
]+"^M
&"[^^M
]+raise gdb.GdbError\(\).."^M
&"gdb.GdbError.."^M
\^error,msg="Error occurred in Python\."[^M
]+[(]gdb[)] ^M
[ ]*)
-pycmd exp^M
&"Traceback (most recent call last):\n"^M
&" File \"py-mi-cmd.py\", line 76, in invoke\n raise gdb.GdbError()\n"^M
&"gdb.GdbError\n"^M
^error,msg="Error occurred in Python."^M
(gdb) ^M
FAIL: gdb.python/py-mi-cmd.exp: -pycmd exp (unexpected output)
...
In contrast, with python 3.12 I have:
...
Expecting: ^(-pycmd exp[^M
]+)?(.*&"Traceback \(most recent call last\):.."^M
&"[^^M
]+py-mi-cmd.py[^^M
]+"^M
&"[^^M
]+raise gdb.GdbError\(\).."^M
&"gdb.GdbError.."^M
\^error,msg="Error occurred in Python\."[^M
]+[(]gdb[)] ^M
[ ]*)
-pycmd exp^M
&"Traceback (most recent call last):\n"^M
&" File \"py-mi-cmd.py\", line 76, in invoke\n"^M
&" raise gdb.GdbError()\n"^M
&"gdb.GdbError\n"^M
^error,msg="Error occurred in Python."^M
(gdb) ^M
PASS: gdb.python/py-mi-cmd.exp: -pycmd exp
...
To make it easier to understand what we're looking at, let's take this out of
the mi interpreter context and use the cli interpreter:
...
$ gdb -q -batch -ex "set trace-commands on" -x gdb.in
+set python print-stack full
+source py-mi-cmd.py
+python pycmd1('-pycmd')
+python pycmd1.invoke (pycmd1, ["exp"])
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "py-mi-cmd.py", line 76, in invoke
raise gdb.GdbError()
gdb.GdbError
gdb.in:4: Error in sourced command file:
Error occurred in Python.
...
Interestingly, this is what we're seeing with both python 3.12 and 3.13.
The difference between the python versions is that:
- with python 3.12 each line is printed by itself, and
- with python 3.13 two particular lines are printed toghether.
With the cli interpreter, that makes no difference, because the '\n' is
interpreted.
But with the mi interpreter, that causes a difference in output because the
'\n' is not interpreted, but rather printed literally.
Fix this by accepting the new output in addition to the old one.
Tested on aarch64-linux.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
PR testsuite/31913
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31913
gprofng/ChangeLog
2024-08-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
* common/hwc_cpus.h: New constant for Appliedmicro processor.
* common/hwctable.c: Add the hwc table for Appliedmicro processor.
* src/hhwc_arm64_amcc.h: New file.
* src/collctrl.cc (read_int): Use strtol instead of atoi.
Fix PR binutils/32091
After commit d56083b504, some gcc versions
may warn about unintialized usage of ginsn_func. Albeit false positive,
adapt the code to escape the warning.
gas/config/
* tc-i386-ginsn.c (x86_ginsn_indirect_branch): Early exit if
unexpected args.
gdb.ada/multiarray.exp has a loop that looks like it should run the
test in both 'all' and 'minimal' encodings mode. However, the body of
the loop doesn't actually use the 'flags' variable. This was an
oversight in the original commit.
Following on from the previous commit, this commit fixes the two KFAIL
in gdb.base/sysroot-debug-lookup.exp when not using the
native-extended-gdbserver board.
The failures in this test, when using the 'unix' board, are logged as
bug PR gdb/31804. The problem appears to be caused by the use of the
child_path function in find_separate_debug_file.
What happens on the 'unix' board is that the file is specified to GDB
with a target: prefix, however GDB spots that the target filesystem is
local to GDB and so opens the file without a target: prefix. When we
call into find_separate_debug_file the DIR and CANON_DIR arguments,
which are computed from the objfile_name() no longer have a target:
prefix.
However, in this test if the file was opened with a target: prefix,
then the sysroot also has a target: prefix. When child_path is called
it looks for a common prefix between CANON_DIR (from the objfile_name)
and the sysroot. However, the sysroot still has the target: prefix,
which means the child_path() call fails and returns nullptr.
What I think we need to do is this: if the sysroot has a target:
prefix, and the target filesystem is local to GDB, then we should
strip the target: prefix from the sysroot, just as we do when opening
a file (see gdb_bfd_open in gdb_bfd.c).
Now, when we make the child_path() call neither the sysroot nor
CANON_DIR will have a target: prefix, the child_path() call will
succeed, and GDB will correctly find the debug information.
There is just one remaining issue, the last path we look in when
searching for debug information is built by starting with the sysroot,
then adding the debug directory, see this line:
debugfile = path_join (target_prefix_str, root.c_str (),
debugdir.get (), base_path, debuglink);
The target_prefix_str is set to target: if DIR has a target: prefix,
and DIR should have a target: prefix if the file we're looking for was
opened with a target: prefix. However, in our case the file was in a
local filesystem so GDB stripped the prefix off.
The sysroot however, does have the target: prefix, and the test is
expecting to see GDB look within a file with the target: prefix.
Given that the above line is about looking within a sub-directory of
the sysroot, I think we should not be stripping the target: prefix off
the sysroot path (as we do when building ROOT), instead, we should, in
this case, not use TARGET_PREFIX_STR, and instead just use GDB's
sysroot as it is (in this case with the target: prefix).
With these fixes in place I now see no failures when using the 'unix',
'native-gdbserver', or 'native-extended-gdbserver' boards with this
test, and the KFAILs can be removed.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804
I spotted that the gdb.base/sysroot-debug-lookup.exp test that I added
recently actually had a KPASS when run with the
native-extended-gdbserver board. This was an oversight when adding
the test.
The failures in this test, when using the 'unix' board, are logged as
bug PR gdb/31804. The problem appears to be caused by the use of the
child_path function in find_separate_debug_file.
What happens on the 'unix' board is that the file is specified to GDB
with a target: prefix, however GDB spots that the target filesystem is
local to GDB and so opens the file without a target: prefix. When we
call into find_separate_debug_file the DIR and CANON_DIR arguments,
which are computed from the objfile_name() no longer have a target:
prefix.
However, in this test if the file was opened with a target: prefix,
then the sysroot also has a target: prefix. When child_path is called
it looks for a common prefix between CANON_DIR (from the objfile_name)
and the sysroot. However, the sysroot still has the target: prefix,
which means the child_path() call fails and returns nullptr.
What happens in the native-extended-gdbserver case is that GDB doesn't
see the target filesystem as local. Now the filename retains the
target: prefix, which means that in the child_path() call both the
sysroot and the CANON_DIR have a target: prefix, and so the
child_path() call succeeds. This allows GDB to progress, try some
additional paths, and then find the debug information.
So, this commit changes gdb.base/sysroot-debug-lookup.exp to expect
the test to succeed when using the native-extended-gdbserver protocol.
This leaves one KFAIL when using the native-extended-gdbserver board,
we find the debug information but (apparently) find it in the wrong
file. What's happening is that when GDB builds the filename for the
debug information we end up with a '//' string as a directory
separator, the test regexp only expects a single separator.
Instead of just fixing the test regexp, I've updated the path_join
function in gdbsupport/pathstuff.{cc,h} to allow for absolute paths to
appear in the argument list after the first argument. This means it's
now possible to do this:
auto result = path_join ("/a/b/c", "/d/e/f");
gdb_assert (result == "/a/b/c/d/e/f");
Additionally I've changed path_join so that it avoids adding
unnecessary directory separators. In the above case when the two
paths were joined GDB only added a single separator between 'c' and
'd'. But additionally, if we did this:
auto result = path_join ("/a/b/c/", "/d/e/f");
gdb_assert (result == "/a/b/c/d/e/f");
We'd still only get a single separator.
With these changes to path_join I can now make use of this function in
find_separate_debug_file. With this done I now have no KFAIL when
using the native-extended-gdbserver board.
After this commit we still have 2 KFAIL when not using the
native-gdbserver and unix boards, these will be addressed in the next
commit.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804
Reviewed-By: Keith Seitz <keiths@redhat.com>
Commit bf2813aff8 introduced some logic to
not refresh the step frame id if it detects that the inferior is reverse
stepping out of a recursive call, so that we would still print frame
information once the inferior stops.
However, that logic was overly specific, and wouldn't be hit for
inferiors compiled with clang because clang adds line table entries that
aren't statements, making process_event_stop_test go through a different
branch on the relevant if statement.
Fix this by not making the code that detects "reversing out of a
recursion" an else clause to the previous if, but a standalone if block.
Approved-by: Kevin Buettner <kevinb@redhat.com>
