| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Sometimes, if I'm testing on a loaded machine, the
gdb.gdb/index-file.exp test will timeout during some early steps,
which then cases a TCL error to be thrown later in the test script.
Dejagnu then reports this error once the test run has completed, which
can be pretty noisy, and isn't really very helpful.
The underlying problem is that if GDB takes too long to load the
executable (which is GDB itself in this test) then GDB will still be
busy loading the executable when dejagnu moves on and call
gdb_get_worker_threads. The gdb_get_worker_threads call itself times
out as GDB is _still_ busy loading the executable, and so
gdb_get_worker_threads returns the string "UNKNOWN".
Later we try to perform arithmetic on the worker thread count, which
results in errors when we try to do 'UNKNOWN / 2'.
I propose that after calling gdb_get_worker_threads, we check if the
result was UNKNOWN. If it was then we should report an UNRESOLVED and
abandon the test, this avoids the later TCL errors.
|
|
I noticed that the x86 instruction:
sar $1,%rsi
would fail to style the '$0x1' as an immediate. This commit fixes
that case.
|
|
On s390x-linux, I ran into:
...
(gdb) ptype crash^M
type = class crash {^M
^M
public:^M
crash(int (class {...}::*)(class {...} * const @mode32));^M
}^M
(gdb) FAIL: gdb.dwarf2/dw2-anon-mptr.exp: ptype crash
...
The problem is that the test-case doesn't expect the address class annotation
@mode32.
The test-case uses a .S file, with the address size hard-coded to 4 bytes, and
that's something that is annotated with @mode32 on s390x (which uses 8 byte
addresses).
Fix this by allowing the annotation in the regexp.
Likewise in two other test-cases.
Tested on s390-linux and x86_64-linux.
|
|
With test-case gdb.cp/m-static.exp on arm-linux, I get:
...
(gdb) ptype test5.single_constructor^M
type = class single_constructor {^M
^M
public:^M
single_constructor(void);^M
~single_constructor(void);^M
} *(single_constructor * const)^M
(gdb) FAIL: gdb.cp/m-static.exp: simple object instance, ptype constructor
...
The test-case expects:
- no empty line before "public:", and
- no "~single_constructor(void)", but "~single_constructor()"
The latter is due to commit 137c886e9a6 ("[gdb/c++] Print destructor the same
for gcc and clang").
The failing test is in a part only enabled for is_aarch32_target == 1, so it
looks like it was left behind.
I'm assuming the same happened for the other difference.
Fix this by updating the regexps to match the observed output.
Tested on arm-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
bfd/
PR 32001
* elfxx-riscv.c (riscv_update_subset1): Fixed the untranslated
"internal:" prefix for error message.
|
|
|
|
The DAP spec recently changed to add a new scope for the return value
from a "stepOut" request. This new scope uses the "returnValue"
presentation hint. See:
https://github.com/microsoft/debug-adapter-protocol/issues/458
This patch implements this for gdb.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31945
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
A while ago, an AdaCore user reported some difficulties with the
'define' command. While some of these difficulties are intrinsic, or
at least difficult to change, it seemed sensible to document a couple
of the typical problems -- and to make the text describing argument
substitution a bit more prominent.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
I noticed that the lm_info_frv objects created in frv_current_sos are
never moved to the solib object. This bug was introduced in 8971d2788e
("gdb: link so_list using intrusive_list"), which mistakenly removed the
line
sop->lm_info = std::move (li);
... probably due so a bad merge conflict resolution.
Re-add this line.
If merged in master, I would cherry-pick this to gdb-15-branch.
Change-Id: I609a1a5ad39e93f70a95ea5ebe3f8ff4ab6a8db2
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32005
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
On an aarch64-linux system with 32-bit userland running in a chroot, and using
target board unix/mthumb I get:
...
(gdb) hbreak hbreak.c:27^M
Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M
(gdb) PASS: gdb.base/hbreak.exp: hbreak
continue^M
Continuing.^M
Unexpected error setting breakpoint: Invalid argument.^M
(gdb) FAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak
...
due to this call in arm_linux_nat_target::low_prepare_to_resume:
...
if (ptrace (PTRACE_SETHBPREGS, pid,
(PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0)
perror_with_name (_("Unexpected error setting breakpoint"));
...
This problem does not happen if instead we use a 4-byte aligned address.
I'm not sure if this is simply unsupported or if there's a kernel bug of some
sort, but I don't see what gdb can do about this.
Tentatively mark this as xfail.
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
|
|
On arm-linux, I run into:
...
PASS: gdb.ada/mi_task_arg.exp: mi runto task_switch.break_me
Expecting: ^(-stack-list-arguments 1[^M
]+)?(\^done,stack-args=\[frame={level="0",args=\[\]},frame={level="1",args=\[{name="<_task>",value="0x[0-9A-Fa-f]+"}(,{name="<_taskL>",value="[0-9]+"})?\]},frame={level="2",args=\[({name="self_id",value="(0x[0-9A-Fa-f]+|<optimized out>)"})?\]},.*[^M
]+[(]gdb[)] ^M
[ ]*)
-stack-list-arguments 1^M
^done,stack-args=[frame={level="0",args=[]},frame={level="1",args=[{name="<_task>",value="0x40bc48"}]},frame={level="2",args=[]}]^M
(gdb) ^M
FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
...
The problem is that the test-case expects a level 3 frame, but there is none.
This can be reproduced using cli bt:
...
$ gdb -q -batch outputs/gdb.ada/mi_task_arg/task_switch \
-ex "b task_switch.break_me" \
-ex run \
-ex bt
Breakpoint 1 at 0x34b4: file task_switch.adb, line 57.
Thread 3 "my_caller" hit Breakpoint 1, task_switch.break_me () \
at task_switch.adb:57
57 null;
#0 task_switch.break_me () at task_switch.adb:57
#1 0x00403424 in task_switch.caller (<_task>=0x40bc48) at task_switch.adb:51
#2 0xf7f95a08 in ?? () from /lib/arm-linux-gnueabihf/libgnarl-12.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
...
The purpose of the test-case is printing the frame at level 1, so I don't
think we should bother about the presence of the frame at level 3.
Fix this by allowing the backtrace to stop at level 2.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
PR 31953
|
|
|
|
These objects are not used.
Change-Id: I90127f7b2d1543718c841b54173521d9ab3f652f
|
|
Make the current program space reference bubble up one level.
Change-Id: I6113c9ef57cb31ca8ea129ab58e7c318c09b5123
|
|
A comment above an `if` check was accidentally left in place after
this commit:
commit ddb3f3d89cf62df6be3cb9e110504def19625160
Date: Tue Mar 19 12:34:34 2024 +0100
Add "error_message+" feature to qSupported
The comment relates to how 'E.msg' style remote replies are not
supported by every packet, but after the above commit they are
supported in all cases (that call packet_check_result), and the
comment should have been removed.
|
|
Fix 'text' to 'test' in a test comment.
|
|
|
|
Testcases like ld-elf/pr19719a.c that
printf ("PASS\n");
on success ought to see the whole output for "string match".
Similarly, the ld-pe/ pdb*.d files shouldn't need to remove the last
newline to match. For most of the testsuite it doesn't matter whether
the trailing newline is present or not, and there are only a few cases
where we need to remove it.
* testsuite/lib/ld-lib.exp (run_host_cmd): Don't regsub away
output trailing newline. Do string trim for gcc/ld version checks.
* testsuite/config/default.exp (plug_so): Do string trim output of
run_host_cmd.
* testsuite/ld-elf/shared.exp (mix_pic_and_non_pic): Adjust
string match to include trailing newline.
* testsuite/ld-i386/i386.exp (undefined_weak): Likewise.
* testsuite/ld-x86-64/x86-64.exp (undefined_weak): Likewise.
* testsuite/ld-plugin/libdep.exp (run_test): Likewise.
* testsuite/ld-plugin/lto.exp (PR ld/28138 run): Likewise.
* testsuite/ld-pe/pdb-strings.d,
* testsuite/ld-pe/pdb-syms1-globals.d,
* testsuite/ld-pe/pdb-syms1-records.d,
* testsuite/ld-pe/pdb-syms1-symbols1.d,
* testsuite/ld-pe/pdb-syms1-symbols2.d,
* testsuite/ld-pe/pdb-syms2-symbols1.d,
* testsuite/ld-pe/pdb-types1-hashlist.d,
* testsuite/ld-pe/pdb-types1-skiplist.d,
* testsuite/ld-pe/pdb-types1-typelist.d,
* testsuite/ld-pe/pdb-types2-hashlist.d,
* testsuite/ld-pe/pdb-types2-skiplist.d,
* testsuite/ld-pe/pdb-types2-typelist.d,
* testsuite/ld-pe/pdb-types3-hashlist.d,
* testsuite/ld-pe/pdb-types3-skiplist.d,
* testsuite/ld-pe/pdb-types3-typelist.d,
* testsuite/ld-pe/pdb1-publics.d,
* testsuite/ld-pe/pdb1-sym-record.d,
* testsuite/ld-pe/pdb2-section-contrib.d,
* testsuite/ld-pe/pdb3-c13-info1.d,
* testsuite/ld-pe/pdb3-c13-info2.d,
* testsuite/ld-pe/pdb3-source-info.d: Add trailing newline.
|
|
The commit:
commit 22836ca88591ac7efacf06d5b6db191763fd8aba
Date: Tue May 21 09:57:49 2024 +0100
gdb: check for multiple matching build-id files
Was missing a 'require allow_gdbserver_tests' in a gdbserver test.
Add it now.
|
|
When running test-case gdb.dap/rust-slices.exp on aarch64-linux
(debian 12/bookworm), I run into:
...
{"request_seq": 6, "type": "response", "command": "scopes", "body": {"scopes": [{"variablesReference": 1, "name": "Locals", "presentationHint": "locals", "expensive": false, "namedVariables": 3, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}, {"variablesReference": 2, "name": "Registers", "presentationHint": "registers", "expensive": false, "namedVariables": 261, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}]}, "success": true, "seq": 20}PASS: gdb.dap/rust-slices.exp: get scopes success
FAIL: gdb.dap/rust-slices.exp: three scopes
PASS: gdb.dap/rust-slices.exp: scope is locals
PASS: gdb.dap/rust-slices.exp: locals presentation hint
PASS: gdb.dap/rust-slices.exp: three vars in scope
...
The test-case expects three scopes due to a rust compiler issue:
...
# There are three scopes because an artificial symbol ends up in the
# DWARF. See https://github.com/rust-lang/rust/issues/125126.
gdb_assert {[llength $scopes] == 3} "three scopes"
...
but it seems that the version used here (rustc 1.63.0, llvm 14.0.6) doesn't
have this issue.
Fix this by allowing two or three scopes, and changing the test name to
"two scopes".
Tested on aarch64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
PR testsuite/31983
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31983
|
|
|
|
The file pdb-syms1a.s was missing a definition for T_VOID, which was
causing some types not to be deduplicated. It also meant that the test
couldn't be run against LLVM's lld, which throws an error for this.
This particular test only tests the symbols stream, not the types
stream, which is why the deduplication doesn't result in a change in the
file size.
|
|
add_globals_ref was hashing using CRC32 rather than the hashing
algorithm used for symbols, which meant that windbg was unable to put
breakpoints against unmangled names.
|
|
Change 2.42 to 2.43 for binutils 2.43 NEWS entries.
binutils/
* NEWS: Change 2.42 to 2.43 for 2.43 NEWS entries.
ld/
* NEWS: Change 2.42 to 2.43 for 2.43 NEWS entries.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
The tracepoint_probe_create_sals_from_location_spec function just
forwards all its arguments to
bkpt_probe_create_sals_from_location_spec, and is only used in one
place.
Lets delete tracepoint_probe_create_sals_from_location_spec and
replace it with bkpt_probe_create_sals_from_location_spec.
There should be no user visible changes after this commit.
|
|
During a later patch I wanted to reset a single breakpoint, so I
called breakpoint_re_set_one. However, this is not the right thing to
do. If we look at breakpoint_re_set then we see that there's a whole
bunch of state that needs to be preserved prior to calling
breakpoint_re_set_one, and after calling breakpoint_re_set_one we
still need to call update_global_location_list.
I could just update the comment on breakpoint_re_set_one to make it
clearer how the function should be used -- or more likely to warn that
the function should only be used as a helper from breakpoint_re_set.
However, breakpoint_re_set_one is only 3 lines long. So I figure it
might actually be easier to just fold breakpoint_re_set_one into
breakpoint_re_set, then there's no risk of accidentally calling
breakpoint_re_set_one when we shouldn't.
There should be no user visible changes after this commit.
|
|
I noticed that in the 'info breakpoints' output, GDB sometimes prints
the inferior list for pending breakpoints, this doesn't seem right to
me. A pending breakpoint has no locations (at least, as far as we
display things in the 'info breakpoints' output), so including an
inferior list seems odd.
Here's what I see right now:
(gdb) info breakpoint 5
Num Type Disp Enb Address What
5 breakpoint keep y <PENDING> foo inf 1
(gdb)
It's the 'inf 1' at the end of the line that I'm objecting too.
To trigger this behaviour we need to be in a multi-inferior debug
session. The breakpoint must have been non-pending at some point in
the past, and so have a location assigned to it.
The breakpoint becomes pending again as a result of a shared library
being unloaded. When this happens the location itself is marked
pending (via bp_location::shlib_disabled).
In print_one_breakpoint_location, in order to print the inferior list
we check that the breakpoint has a location, and that we have multiple
inferiors, but we don't check if the location itself is pending.
This commit adds that check, which means the output is now:
(gdb) info breakpoint 5
Num Type Disp Enb Address What
5 breakpoint keep y <PENDING> foo
(gdb)
Which I think makes more sense -- indeed, the format without the
inferior list is what we display for a pending breakpoint that has
never had any locations assigned, so I think this change in behaviour
makes GDB more consistent.
|
|
|
|
|
|
|
|
The new test wasn't being run, and failed due to relocations against
.gnu.build.attributes being stripped by default strip behaviour.
We probably should be keeping these relocations, but I haven't made
that change here.
BTW, the new test fails on ia64-hpux but that's just a repeat of the
existing note-5 fail.
PR 31999
* testsuite/binutils-all/strip-16.d: strip with --strip-unneeded
and --merge-notes.
* testsuite/binutils-all/objcopy.exp: Run the new test. Sort
other strip tests.
|
|
Add a test for strip with build notes.
PR binutils/31999
* testsuite/binutils-all/strip-16.d: New.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
PR 31999
* objcopy.c (merge_gnu_build_notes): Always set *new_size.
|
|
|
|
When debugging gdb itself and trying to print a intrusive_list that has
more than one element, I get:
File "/home/simark/build/binutils-gdb-all-targets/gdb/gdb-gdb.py", line 365, in _children_generator
node_ptr = self._as_node_ptr(elem_ptr)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/simark/build/binutils-gdb-all-targets/gdb/gdb-gdb.py", line 345, in _as_node_ptr
assert elem_ptr.type.code == gdb.TYPE_CODE_PTR
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
This is because node_ptr is a typedef
(intrusive_list_base_iterator::pointer). Add a call to strip_typedefs
to get to the real type.
Enhance gdb.gdb/python-helper.exp with a test that would have caught
this bug.
Change-Id: I3eaca8de5ed06d05756ed979332b6a431e15b700
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Replace the "y" microMIPS operand code, used with ALNV.PS only, with "x"
so as to make "y" available for microMIPS MT use.
|
|
A number of instructions in the regular MIPS opcode table are assembly
idioms for the MT thread context move MFTR and MTTR instructions, so
mark them as aliases accordingly. Add suitable test cases, which also
cover the PAUSE assembly idiom.
|
|
PAUSE is an assembly idiom for 'sll $0,$0,5', so mark it as an alias in
the regular MIPS opcode table, matching the microMIPS opcode table. A
test case will be supplied separately.
|
|
Verify that MT ASE instructions assemble and disassemble correctly
across the compatible architectures.
|
|
A number of coprocessor move encodings have been randomly sprinkled over
the regular MIPS and microMIPS opcode tables rather than where they'd be
expected following the alphabetic order. Fix the ordering, taking into
account precedence where it has to be observed for correct disassembly.
No functional change.
|
|
Make AL a shorthand for INSN2_ALIAS with the regular MIPS and microMIPS
opcode tables, just as with the MIPS16 opcode table, and use it
throughout. No functional change.
|
|
Make room for AL as a shorthand for INSN2_ALIAS with the regular MIPS
opcode table, just as with the MIPS16 opcode table. No functional
change.
|
|
The semantics of the regular MIPS "+t" operand code is exactly the same
as that of the "E" operand code, so replace the former with the latter
in the single MFTC0 instruction with implicit 'sel' == 0 encoding where
it's used, matching the encoding with explicit 'sel' as well as other
instructions.
|
|
We print MFTR and MTTR instructions' thread context register operand in
disassembly using the ABI name the register number would correspond to
should the targeted register be a general-purpose register.
However in most cases it is wrong, because general-purpose registers are
only referred when the 'u' and 'sel' operands are 1 and 0 respectively.
And even in these cases the MFGPR and MTGPR aliases take precedence over
the corresponding generic instruction encodings, so you won't see the
valid case to normally trigger.
Conversely decoding the thread context register operand numerically is
always valid, so switch to using it. Adjust test coverage accordingly.
|
|
As from commit ab90248154ba ("Add structures to describe MIPS
operands"), <https://sourceware.org/ml/binutils/2013-07/msg00135.html>,
the use of numerous regular MIPS and microMIPS OP_SH and OP_MASK macros
has been removed.
Similarly as from commit c3c0747817f4 ("Use operand structures for
MIPS16"), <https://sourceware.org/ml/binutils/2013-07/msg00136.html>,
the use of numerous MIPS16 OP_SH and OP_MASK macros has been removed.
And as from commit 9e12b7a2b022 ("Rewrite main mips_ip parsing loop"),
<https://sourceware.org/ml/binutils/2013-07/msg00139.html>, none of the
OP_OP macros are used anymore.
Discard all the unused macros then and only keep the small subset that
is still referred. This simplifies maintenance and removes the need to
keep the artificial arrangement where some regular MIPS and microMIPS
macros expand to 0 and are kept for compatibility with the opposite ISA
mode only, as it used to be required before the commit referred.
|
|
The "-t", "-u", "-v", and "-w" operand types refer 'rt' operand, which
is the target register rather than the source register. Additionally
the "-x" and "-y" R6 operand types refer 'rs' rather than 'rt' operand
of the BOVC/BNVC and the BEQC/BNEC instructions respectively. Also the
"-x" operand type does not permit 'rs' to be the same as 'rt'.
Correct inline documentation in opcode/mips.h accordingly.
|
|
The "-x" operand type is used for the reverse encoding of the BOVC and
BNVC instructions, where 'rs' and 'rt' have been supplied as the second
and the first operand respectively rather than the order the instruction
expects.
In this case we require the register associated with the "-x" operand to
have a higher number than the register associated with the preceding "t"
operand, which precludes the use of $0. The case where 'rs' and 'rt'
both refer to the same register is handled by the straight encoding of
the BOVC and BNVC instructions, which come in the opcode table ahead of
the corresponding reverse encoding.
Therefore clear the ZERO_OK flag for the "-x" operand. No need for an
extra test case as the encodings involved are already covered by "r6"
and its associated GAS tests.
|
|
In a subsequent change the scrubber is going to be changed to retain
further whitespace. Test case expectations generally would better not
depend on the specific whitespace treatment by the scrubber, unless of
course a test is specifically about it. Adjust relevant test cases to
permit blanks where those will subsequently appear.
|
|
Whitespace in macro arguments either needs quoting / parenthesizing to
reliably not be mistaken for an argument separator, or respective macro
parameters need to be marked as covering all remaining arguments. The
latter appears more appropriate (and far less intrusive) here.
|
