Tom de Vries [Tue, 27 Aug 2024 07:08:41 +0000 (09:08 +0200)]
[gdb/symtab] Change DWARF_ERROR from Dwarf Error to DWARF Error
It was suggested here [1] that the canonical prefix for dwarf errors
should not be "Dwarf Error: ", given that the canonical spelling is DWARF
instead of Dwarf.
Fix this by using "DWARF Error: " instead.
Given the use of DWARF_ERROR_PREFIX, that needs to be changed only in a single
location.
Tested on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2024-August/211258.html
Tom de Vries [Tue, 27 Aug 2024 07:08:41 +0000 (09:08 +0200)]
[gdb/symtab] Use [in module %s] notation more consistently in dwarf errors
In gdb/dwarf2/read.c, I found a few strings "in module %s":
...
$ grep "in module %s" gdb/dwarf2/read.c | fgrep -v '['
"DIE at %s in module %s"),
error (_("Dwarf Error: Dummy CU at %s referenced in module %s"),
error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"),
error (_("Dwarf Error: DIE at %s referenced in module %s "
error (_("Dwarf Error: Dummy CU at %s referenced in module %s"),
error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"),
...
that are not using the commonly used "[in module %s]" notation. Fix these.
In one case, the string was also used in the middle rather than at the end of
the message, so fix that as well.
Jiawei [Tue, 20 Aug 2024 02:10:21 +0000 (10:10 +0800)]
RISC-V: PR32036, Support Zcmp cm.mva01s and cm.mvsa01 instructions.
This patch supports Zcmp instruction 'cm.mva01s' and 'cm.mvsa01'.
All disassemble instructions use the sreg format.
Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com>
Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
Co-Authored by: Simon Cook <simon.cook@embecosm.com>
Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>
gas/ChangeLog:
PR 32036
* NEWS: Updated.
* config/tc-riscv.c (validate_riscv_insn): New operators.
(riscv_ip): Ditto.
* testsuite/gas/riscv/zcmp-mv.d: New test.
* testsuite/gas/riscv/zcmp-mv.s: New test.
include/ChangeLog:
PR 32036
* opcode/riscv-opc.h (MATCH_CM_MVA01S): New opcode.
(MASK_CM_MVA01S): New mask.
(MATCH_CM_MVSA01): New opcode.
(MASK_CM_MVSA01): New mask.
(DECLARE_INSN): New declarations.
* opcode/riscv.h (OP_MASK_SREG1): New mask.
(OP_SH_SREG1): New operand code.
(OP_MASK_SREG2): New mask.
(OP_SH_SREG2): New operand code.
(X_A0): New reg number.
(X_A1): Ditto.
(X_S7): Ditto.
(RISCV_SREG_0_7): New macro function.
opcodes/ChangeLog:
PR 32036
* riscv-dis.c (riscv_zcmp_get_sregno): New function.
(print_insn_args): New operators.
* riscv-opc.c (match_sreg1_not_eq_sreg2): New match function.
Tom Tromey [Mon, 26 Aug 2024 19:29:04 +0000 (13:29 -0600)]
Simplify ada_identical_enum_types_p
This patch changes ada_identical_enum_types_p to reuse the field names
that are computed earlier in the loop. This is a simple cleanup, but
also is useful for a larger change that I'm working on.
Mark Harmstone [Mon, 26 Aug 2024 12:58:56 +0000 (13:58 +0100)]
ld/PDB: handle pointers to members
If the CV_PTR_MODE_PMEM or CV_PTR_MODE_PMFUNC flags were set in an
LF_POINTER entry's attributes, there's a few extra bytes on the end that
we weren't accounting for.
Change handle_type so that we remap the containing_class field if it's
present, and add a test for this.
William Ferreira [Thu, 18 Jul 2024 19:38:31 +0000 (16:38 -0300)]
gdb: imply --once if connecting via stdio
Currently, gdbserver hangs after stdin is closed while it tries to
write: "Remote side has terminated connection. GDBserver will reopen
the connection." This hang disappears if --once is also given. Since
the stdin connection won't ever reopen if it's closed, it's safe to
assume --once is desired.
The gdb.server/server-pipe.exp test was also updated to reflect this
change. There is now a second disconnect at the end of the proc,
with a tighter-than-normal timeout to catch if the command hangs as
it used to.
Guinevere Larsen [Mon, 26 Aug 2024 13:33:17 +0000 (10:33 -0300)]
Change message when reaching end of reverse history.
In a record session, when we move backward, GDB switches from normal
execution to simulation. Moving forward again, the emulation continues
until the end of the reverse history. When the end is reached, the
execution stops, and a warning message is shown. This message has been
modified to indicate that the forward emulation has reached the end, but
the execution can continue as normal, and the recording will also continue.
Before this patch, the warning message shown in that case was the same as
in the reverse case. This meant that when the end of history was reached in
either backward or forward emulation, the same message was displayed:
"No more reverse-execution history."
This message has changed for these two cases. Backward emulation:
"Reached end of recorded history; stopping.
Backward execution from here not possible."
Forward emulation:
"Reached end of recorded history; stopping.
Following forward execution will be added to history."
The reason for this change is that the initial message was deceiving, for
the forward case, making the user believe that forward debugging could not
continue.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31224 Reviewed-By: Markus T. Metzger <markus.t.metzger@intel.com> (btrace) Approved-By: Guinevere Larsen <blarsen@redhat.com>
Lulu Cai [Fri, 9 Aug 2024 09:40:59 +0000 (17:40 +0800)]
LoongArch: Fix wrong relocation handling of symbols defined by PROVIDE
If the symbol defined by PROVIDE in the link script is not in SECTION,
the symbol is placed in the ABS section. The linker considers that
symbols in the ABS section do not need to calculate PC relative offsets.
Symbols in ABS sections should calculate PC relative offsets normally
based on relocations.
Alan Modra [Sun, 25 Aug 2024 05:50:21 +0000 (15:20 +0930)]
PR32109, aborting at bfd/bfd.c:1236 in int _bfd_doprnt
Since bfd_section for .strtab isn't set, print the section index
instead. Also, don't return NULL on this error as that results in
multiple mmap/read of the string table. (We could return NULL if we
arranged to set sh_size zero first, but just what we do with fuzzed
object files is of no concern, and terminating the table might make a
faulty object file usable.)
PR 32109
* elf.c (bfd_elf_get_str_section): Remove outdated comment, and
tweak shstrtabsize test to suit. Don't use string tab bfd_section
in error message, use index instead. Don't return NULL on
unterminated string section, terminate it.
(_bfd_elf_get_dynamic_symbols): Similarly terminate string table
section.
Aaron Merey [Wed, 13 Mar 2024 20:18:27 +0000 (16:18 -0400)]
gdb/dwarf2: Check for null abbrev_info ptr
A corrupt debuginfo file can result in a null abbrev_info pointer
being passed to cooked_indexer::scan_attributes. This pointer
is set to nullptr by peek_die_abbrev when an abbrev of 0 is found.
There is no check for whether the abbrev pointer is null and
SIGSEGV occurs when attempting to dereference the pointer.
An abbrev of 0 normally indicates that the corresponding DIE is a
null entry, but scan_attributes expects a non-null DIE.
Fix this by throwing an error in cooked_indexer::scan_attributes
when peek_die_abbrev returns a nullptr in order to avoid
scan_attributes calling itself with a null abbrev.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31478 Co-authored-by: Tom de Vries <tdevries@suse.de> Approved-By: Tom Tromey <tom@tromey.com>
Jan Beulich [Fri, 23 Aug 2024 07:24:10 +0000 (09:24 +0200)]
x86: simplify SAE checking
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).
Jan Beulich [Fri, 23 Aug 2024 07:22:30 +0000 (09:22 +0200)]
RISC-V: process rs_align_code also when relaxing
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.
Tom de Vries [Thu, 22 Aug 2024 08:00:27 +0000 (10:00 +0200)]
[gdb/symtab] Return correct reader for top-level CU in cooked_indexer::ensure_cu_exists
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.
Tom de Vries [Thu, 22 Aug 2024 07:49:53 +0000 (09:49 +0200)]
[gdb/python] Eliminate catch(...) in type_to_type_object
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.
Tom de Vries [Thu, 22 Aug 2024 07:49:53 +0000 (09:49 +0200)]
[gdb] Add & in catch in svr4_handle_solib_event
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.
Simon Marchi [Tue, 30 Jul 2024 14:37:01 +0000 (10:37 -0400)]
gdb: some global_block improvements
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>
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>
Tom Tromey [Fri, 16 Aug 2024 17:43:33 +0000 (11:43 -0600)]
Fix Windows regression
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>
Tom Tromey [Wed, 14 Aug 2024 16:45:30 +0000 (10:45 -0600)]
Use SEARCH_FUNCTION_DOMAIN when looking for Ada exception symbols
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.
Tom de Vries [Tue, 20 Aug 2024 13:57:36 +0000 (15:57 +0200)]
[gdb/testsuite] Fix gdb.python/py-mi-cmd.exp with python 3.13
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.
gprofng: add hardware counters for Appliedmicro processor
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.
After commit d56083b5047b8e7cc9eda2f867bd2b75724920a1, 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.
Tom Tromey [Mon, 19 Aug 2024 16:48:18 +0000 (10:48 -0600)]
Ensure gdb.ada/multiarray.exp runs in both modes
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.
Andrew Burgess [Wed, 12 Jun 2024 14:26:50 +0000 (15:26 +0100)]
gdb: fix a target: prefix issue in find_separate_debug_file
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:
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.
Andrew Burgess [Wed, 12 Jun 2024 14:24:46 +0000 (15:24 +0100)]
gdb: avoid '//' in filenames when searching for debuginfo
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.
Guinevere Larsen [Wed, 14 Aug 2024 15:03:57 +0000 (12:03 -0300)]
gdb: Fix printing frame when reversing out of a recursive call with clang
Commit bf2813aff8f2988ad3d53e819a0415abf295c91f 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.
Tom de Vries [Sun, 18 Aug 2024 18:51:29 +0000 (20:51 +0200)]
[gdb] Prune inferior after switching inferior
Usually with test-case gdb.python/py-progspace-events.exp I get:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 4116] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 4116))]^M
28 { /* Nothing. */ }^M
(gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
step^M
FreeProgspaceEvent: <gdb.Progspace object at 0xabf4f850>^M
do_parent_stuff () at py-progspace-events.c:41^M
41 ++global_var;^M
(gdb) PASS: gdb.python/py-progspace-events.exp: step
...
But occasionally I run into the following FAIL:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 5199] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M
28 { /* Nothing. */ }^M
(gdb) FreeProgspaceEvent: <gdb.Progspace object at 0xabaf03a0>^M
FAIL: gdb.python/py-progspace-events.exp: inferior 1 (timeout)
...
This is caused by a race between the handling of an event, and the
"inferior 1" command.
In the passing case, the event is handled first. During which prune_inferiors
is called, but it can't remove inferior 2, because it's still the current one.
In the failing case, the "inferior 1" command is handled first. Then during
handling of the event, prune_inferiors is called, and it can remove inferior 2
because it's no longer the current one.
This looks like a test-case issue to me, but ISTM that we can do better: by
calling prune_inferiors asap, at the end of the "inferior 1" command, we
stabilize the moment when the inferior is removed:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 5199] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M
28 { /* Nothing. */ }^M
FreeProgspaceEvent: <gdb.Progspace object at 0xabaf03a0>^M
(gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
...
This also allows us to simplify the test-case by removing the step command,
which is no longer required to trigger the pruning of the inferior.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
PR gdb/31440
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31440
Tom Tromey [Thu, 15 Aug 2024 18:06:31 +0000 (12:06 -0600)]
Fix DAP failure when fetching global variables
The relatively new "globals" scope code in DAP has a fairly obvious
bug -- the fetch_one_child method should return a tuple with two
elements, but instead just returns the variable's value.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32029 Reviewed-By: Tom de Vries <tdevries@suse.de>
Tom de Vries [Fri, 16 Aug 2024 12:22:46 +0000 (14:22 +0200)]
[gdb/testsuite] Fix gdb.dwarf2/dw2-fixed-point.exp on arm-linux
With test-case gdb.dwarf2/dw2-fixed-point.exp on arm-linux I run into:
...
(gdb) PASS: gdb.dwarf2/dw2-fixed-point.exp: set lang ada
print pck.fp1_var^M
$1 = 0.3125^M
(gdb) FAIL: gdb.dwarf2/dw2-fixed-point.exp: print pck.fp1_var
...
The problem is that the thumb prologue analyzer overshoot, setting the
breakpoint for main after line 49:
...
46 int
47 main (void)
48 {
49 pck__fp1_var++;
...
and consequently we see the value of pck.fp1_var after line 49 instead of
before line 49. This is PR tdep/31981.
Work around this by removing line 49 and all similar subsequent lines, which
turn out to be dead code.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested on arm-linux.
On arm-linux I run into:
...
(gdb) p *kernel_user_helper_version^M
Cannot access memory at address 0xffff0ffc^M
(gdb) FAIL: gdb.arch/arm-single-step-kernel-helper.exp: check kernel helper version
...
What the test-case is trying to do, is to access a special address in the arm
linux kernel [1] using ptrace, which doesn't seem to work.
This is with kernel version 6.1.55. Perhaps this used to work, but the kernel
was modified to be more strict with respect to access to this special address.
Fix this by making the inferior access that special address instead.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR testsuite/32070
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32070
maint btrace clear
Discard the branch trace data. The data will be fetched anew and
the branch trace will be recomputed when needed.
This implicitly truncates the branch trace to a single branch trace
buffer. When updating branch trace incrementally, the branch trace
available to GDB may be bigger than a single branch trace buffer.
The test with BTS is updating the recorded trace incrementally. After the
clear, the buffer of raw trace data available is not enough to recompute the
whole trace as it was before the clear(), and the first 3 instructions are
missing.
As increasing the buffer size for BTS didn't help, I propose to fix the test
by moving the testing of clear to the end of the test.
Approved-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32086
Jan Beulich [Fri, 16 Aug 2024 06:34:50 +0000 (08:34 +0200)]
opcodes/cgen: drop trailing whitespace also for cris
While 919b75f7e289 ("Trailing space in opcodes/ generated files") took
care of permanently zapping trailing whitespace, 547112801156
("opcodes: cris: move desc & opc files from sim/") then didn't enhance
the newly added code accordingly.
Dimitar Dimitrov [Mon, 12 Aug 2024 19:25:57 +0000 (22:25 +0300)]
gas: pru: Fix trailing whitespace handling
With commit 6ae8a30d44f016cafb46a75843b5109316eb1996, arguments followed
by a C-style comment ended up with a trailing space. That extra space
character confused the PRU register name matching, leading to spurious
errors about unrecognized registers. This affected existing code like
newlib's setjmp.s for pru.
Fix by stripping the trailing whitespace for any argument.
H.J. Lu [Thu, 15 Aug 2024 03:50:02 +0000 (20:50 -0700)]
lto: Don't include unused LTO archive members in output
When plugin_object_p is called by elf_link_is_defined_archive_symbol to
check if a symbol in archive is a real definition, set archive member
plugin_format to bfd_plugin_yes_unused to avoid including the unused LTO
archive members in linker output. When plugin_object_p is called as
known used, call plugin claim_file if plugin_format is bfd_plugin_unknown
or bfd_plugin_yes_unused.
To get the proper support for archives with LTO common symbols with GCC,
the GCC fix for
PR ld/32083
* archures.c (bfd_arch_get_compatible): Treat bfd_plugin_yes_unused
the same as bfd_plugin_yes.
* elflink.c (elf_link_is_defined_archive_symbol): Likewise.
* bfd.c (bfd_plugin_format): Add bfd_plugin_yes_unused.
* plugin.c (try_claim): Try claim_file_v2 first.
* bfd-in2.h: Regenerated.
ld/
PR ld/32083
* plugin.c (plugin_call_claim_file): Add an argument to return
if LDPT_REGISTER_CLAIM_FILE_HOOK_V2 is used.
(plugin_object_p): When KNOWN_USED is false, we call plugin
claim_file if plugin_format is bfd_plugin_unknown and set
plugin_format to bfd_plugin_yes_unused on LTO object. When
KNOWN_USED is true, we call plugin claim_file if plugin_format
is bfd_plugin_unknown or bfd_plugin_yes_unused.
Tom Tromey [Fri, 26 Jul 2024 14:36:28 +0000 (08:36 -0600)]
Log gdb version and configuration in DAP
I think it would be useful for gdb's DAP logs to come with the version
and configuration information. This might make debugging some bug
reports a little simpler.
Tom Tromey [Mon, 8 Jul 2024 17:28:37 +0000 (11:28 -0600)]
Notify Python when breakpoint symbol changes
A DAP user noticed that breakpoints set by address were never updated
to show their location after the DAP launch request. It turns out
that gdb does not emit the breakpoint-modified event when this sort of
breakpoint is updated.
This patch changes gdb to notify the breakpoint-modified observer when
a breakpoint location's symbol changes. This in turn causes the DAP
event to be emitted.
Tom Tromey [Fri, 5 Jul 2024 16:53:43 +0000 (10:53 -0600)]
Fix failure with C++ exceptions in DAP
While working on earlier patches, I noticed that the DAP C++ exception
test had some strange results in the log. Digging into this, I found
that while the Ada catchpoints emit a "bkptno" field in the MI result,
the C++ ones do not -- but the DAP code was relying on this.
This patch fixes the problem by changing which field is examined, and
then updates the tests to verify this.
Tom Tromey [Fri, 5 Jul 2024 15:57:03 +0000 (09:57 -0600)]
Make DAP instruction breakpoints unverified
Currently, when a DAP client uses setInstructionBreakpoints, the
resulting breakpoints are created as "verified", even though there is
no symbol file and thus the breakpoint can't possibly have a source
location.
This patch changes the DAP code to assume that all breakpoints are
unverified before launch.
H.J. Lu [Wed, 14 Aug 2024 15:29:15 +0000 (08:29 -0700)]
ld: Add an LTO test for common symbol override
Linker checks if a symbol in an archive member is a real definition, not
common, before including the archive member in the link output so that
only a real definition in archive will override the common symbol in
object file. Add an LTO test to verify that a real definition in archive
overrides the common symbol in object file.
* testsuite/ld-plugin/common-1.c: New file.
* testsuite/ld-plugin/definition-1.c: Likewise.
* testsuite/ld-plugin/lto.exp: Run common tests.
Tom Tromey [Wed, 14 Aug 2024 12:52:19 +0000 (06:52 -0600)]
Remove unnecessary default argument from initialize_block_iterator
I noticed that initialize_block_iterator has a default value for one
of its arguments, but this is not needed as this function has a single
caller that always passes all arguments. This patch removes the
default. Tested by rebuilding.
Xi Ruoyao [Mon, 12 Aug 2024 10:23:47 +0000 (18:23 +0800)]
LoongArch: Fix DT_RELR and relaxation interaction
Due to the way BFD implements DT_RELR as a part of relaxation, if in a
relax trip size_relative_relocs has changed the layout, when
relax_section runs only the vma of the section being relaxed is
guaranteed to be updated. Then bad thing can happen. For example, when
linking an auxilary program _freeze_module in the Python 3.12.4 building
system (with PGO + LTO), before sizing the .relr.dyn section, the vma of
.text is 30560 and the vma of .rodata is 2350944; in the final
executable the vma of .text is 36704 and the vma of .rodata is 2357024.
The vma increase is expected because .relr.dyn is squashed somewhere
before .text. But size_relative_relocs may see the state in which .text
is at 36704 but .rodata "is" still at 2350944. Thus the distance
between .text and .rodata can be under-estimated and overflowing
R_LARCH_PCREL20_S2 reloc can be created.
To avoid this issue, if size_relative_relocs is updating the size of
.relr.dyn, just supress the normal relaxation in this relax trip. In
this situation size_relative_relocs should have been demending the next
relax trip, so the normal relaxation can happen in the next trip.
Xi Ruoyao [Mon, 12 Aug 2024 10:23:46 +0000 (18:23 +0800)]
LoongArch: Fix assertion failure with DT_RELR
In the DT_RELR implementation I missed a code path emiting relative
reloc entries. Then the already packed relative reloc entries will be
(unnecessarily) pushed into .rela.dyn but we've not allocated the space
for them, triggering an assertion failure.
Unfortunately I failed to notice the issue until profiled bootstrapping
GCC with LTO and -Wl,-z,pack-relative-relocs. The failure can be easily
triggered by linking a "hello world" program with -fprofile-generate and
LTO:
And the reduced test case is just incredibly simple (included in the
patch) so it seems I'm just stupid enough to fail to detect it before.
Let's fix it now anyway.
Jan Beulich [Wed, 14 Aug 2024 09:25:12 +0000 (11:25 +0200)]
x86: correct .insn with opcode extension and VEX/XOP/EVEX encoding
When VexVVVV handling was re-worked, .insn broke: When an opcode
extension is in use, VexVVVV_DST needs using now, as ModR/M.reg is
already occupied, matching what c8866e3ec5e2 ("x86: Drop using
extension_opcode to encode vvvv register") did.
While adding (bad) POP2 forms, also slightly adjust existing ones:
No need to use XMM registers, and no need to specify %r8 when really
%rax is meant twice (EVEX.vvvv not really being the culprit there, or
else EVEX.V' would also have needed mentioning).
Felix Willgerodt [Mon, 18 Feb 2019 14:50:49 +0000 (15:50 +0100)]
btrace: Extend ptwrite event decoding.
Call the ptwrite filter function whenever a ptwrite event is decoded.
The returned string is written to the aux_data string table and a
corresponding auxiliary instruction is appended to the function segment.
Approved-By: Markus Metzger <markus.t.metzger@intel.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
By default GDB will be printing the hex payload of the ptwrite package as
auxiliary information. To customize this, the user can register a ptwrite
filter function in python, that takes the payload and the PC as arguments and
returns a string which will be printed instead. Registering the filter
function is done using a factory pattern to make per-thread filtering easier.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Felix Willgerodt [Tue, 21 Jul 2020 09:12:08 +0000 (11:12 +0200)]
btrace, gdbserver: Add ptwrite to btrace_config_pt.
This enables gdb and gdbserver to communicate about ptwrite support. If
ptwrite support would be enabled unconditionally, GDBs with older libipt
versions would break.
Approved-By: Markus Metzger <markus.t.metzger@intel.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Felix Willgerodt [Mon, 25 Feb 2019 14:30:29 +0000 (15:30 +0100)]
python: Add clear() to gdb.Record.
This function allows to clear the trace data from python, forcing to
re-decode the trace for successive commands.
This will be used in future ptwrite patches, to trigger re-decoding when
the ptwrite filter changes.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Felix Willgerodt [Thu, 21 Feb 2019 09:48:35 +0000 (10:48 +0100)]
python: Introduce gdb.RecordAuxiliary class.
Auxiliary instructions are no real instructions and get their own object
class, similar to gaps. gdb.Record.instruction_history is now possibly a
list of gdb.RecordInstruction, gdb.RecordGap or gdb.RecordAuxiliary
objects.
This patch is in preparation for the new ptwrite feature, which is based on
auxiliary instructions.
Approved-By: Markus Metzger <markus.t.metzger@intel.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
btrace: Enable auxiliary instructions in record function-call-history.
Print the auxiliary data when a btrace_insn of type BTRACE_INSN_AUX
is encountered in the function-call-history. Printing is
active by default, it can be silenced with the /a modifier.
This patch is in preparation for the new ptwrite feature, which is based on
auxiliary instructions.
Approved-By: Markus Metzger <markus.t.metzger@intel.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
btrace: Enable auxiliary instructions in record instruction-history.
Print the auxiliary data when a btrace_insn of type BTRACE_INSN_AUX
is encountered in the instruction-history. Printing is active by default,
it can be silenced with the /a modifier.
This patch is in preparation for the new ptwrite feature, which is based on
auxiliary instructions.
Approved-By: Markus Metzger <markus.t.metzger@intel.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Felix Willgerodt [Mon, 18 Feb 2019 12:49:25 +0000 (13:49 +0100)]
btrace: Introduce auxiliary instructions.
Auxiliary instructions are pseudo instructions pointing to auxiliary data.
This auxiliary data can be printed in all commands displaying (record
function-call-history, record instruction-history) or stepping through
(stepi etc.) the execution history, which will be introduced in the next
commits.
This patch is in preparation for the new ptwrite feature, which is based on
auxiliary instructions.
Approved-By: Markus Metzger <markus.t.metzger@intel.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Mark unavailable bytes of limited-length arrays when allocating contents
I spotted that there was some code in value::record_latest relating to
limited-length arrays which appeared redundant. The code was added
with the first introduction on limited-length arrays in commit:
GDB: Introduce limited array lengths while printing values
The code in question is in value::record_latest. When the value being
recorded is lazy we need to fetch its value before adding it to the
history list. The code I spotted checks to see if the value is lazy,
if we currently have array limiting in effect, and if we do sets
m_limited_length to max_value_size before finally calling fetch_lazy.
The first thing fetch_lazy does is call allocate_contents to setup the
value's buffer, and in allocate_contents we perform the same set of
checks: if the value is an array, and array length limiting is in
effect then only allocate max_value_size buffer for the contents.
In ::allocate_contents the `if` condition check is spread out between
::allocate_contents and ::set_limited_array_length, but I'm certain
it's checking the same condition.
As such the checks and m_limited_length adjustment in ::record_latest
is redundant and can be removed.
Out of curiosity I went back to the original a0c07915778486a commit
and removed the same block of code from record_latest_value (as
value::record_latest was called back then) and non of the tests added
by commit a0c07915778486a failed. I think this block of code was
never needed.
Anyway, I removed the unnecessary code and retested and there are no
regressions.
There should be no user visible changes after this commit.
Alan Modra [Tue, 13 Aug 2024 02:53:03 +0000 (12:23 +0930)]
gas macro arg1 test
A number of targets pad out the data section, and there are targets
that have 2 or 4 octets per byte. And some even that don't have '#'
as a line comment char. tic6x-elf fails the test with "Error: too
many positional arguments".
* testsuite/gas/macros/arg1.s: Pad out data section. Use C style
comments.
* testsuite/gas/macros/arg1.d: Adjust to suit. Don't run on
multi-octet per byte targes. xfail tic6x.
Extend the -H option:
-H {off|on|N1[-N2]} disable , or enable heap tracing, or
specify the heap data collection range.
The default is "-H off".
gprofng/ChangeLog
2024-08-08 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* libcollector/heaptrace.c: Read the range in the -H option.
Do not collect data if the allocated memory is out of range.
* src/collctrl.h (heaptrace_mode): Define as char * value.
* src/envsets.cc: Updated since heaptrace_mode is changed.
* src/collctrl.cc: Accept the extended -H option.
* src/gp-collect-app.cc: Accept the extended -H option.
Remove unused code.
Dimitar Dimitrov [Mon, 12 Aug 2024 17:40:16 +0000 (20:40 +0300)]
sim: pru: Fix test case assembly with latest GAS
After the recent change in GAS [1], macro arguments must be quoted or
grouped with parenthesis. Add the necessary parenthesis in order to fix
assembly errors like:
mul.s:31: Error: too many positional arguments
Tom Tromey [Mon, 29 Jul 2024 15:38:29 +0000 (09:38 -0600)]
Simplify typename_concat
This patch simplifies typename_concat, changing the return type and
removing the obstack allocation code. The latter is possible because
the only caller using this mode uses the name when creating a new
type, and 'new_type' copies the string to the appropriate obstack
anyway. It also changes typename_concat to use 'concat'. This change
lets us remove a mildly fragile macro as well.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
H.J. Lu [Mon, 12 Aug 2024 15:43:22 +0000 (08:43 -0700)]
gas: Add macro tests for PR gas/32073
1. Add a macro test for expression argument with inner white spaces and
a white space before argument added by C preprocessor.
2. Add a x86-64 specific macro test.
PR gas/32073
* testsuite/gas/i386/x86-64-macro-1.d: New file.
* testsuite/gas/i386/x86-64-macro-1.s: Likewise.
* testsuite/gas/i386/x86-64.exp: Run x86-64-macro-1.
* testsuite/gas/macros/arg1.d: New file.
* testsuite/gas/macros/arg1.s: Likewise.
* testsuite/gas/macros/macros.exp: Run arg1.
projects / thirdparty / binutils-gdb.git / log
