This commit addresses one of the issues identified in PR gdb/28275.
Bug gdb/28275 identifies a number of situations in which this assert:
Assertion `!proc_target->commit_resumed_state' failed.
could be triggered. There's actually a number of similar places where
this assert is found in GDB, the two of interest in gdb/28275 are in
target_wait and target_stop.
In one of the comments:
https://sourceware.org/bugzilla/show_bug.cgi?id=28275#c1
steps to trigger the assertion within target_stop were identified when
using a modified version of the gdb.threads/detach-step-over.exp test
script.
In the gdb.threads/detach-step-over.exp test, we attach to a
multi-threaded inferior, and continue the inferior in asynchronous
(background) mode. Each thread is continuously hitting a conditional
breakpoint where the condition is always false. While the inferior is
running we detach. The goal is that we detach while GDB is performing a
step-over for the conditional breakpoint in at least one thread.
While detaching, if a step-over is in progress, then GDB has to
complete the step over before we can detach. This involves calling
target_stop and target_wait (see prepare_for_detach).
As far as gdb/28275 is concerned, the interesting part here, is the
the process_stratum_target::commit_resumed_state variable must be
false when target_stop and target_wait are called.
This is currently ensured because, in detach_command (infrun.c), we
create an instance of scoped_disable_commit_resumed, this ensures that
when target_detach is called, ::commit_resumed_state will be false.
The modification to the test that I propose here, and which exposed
the bug, is that, instead of using "detach" to detach from the
inferior, we instead use "quit". Quitting GDB after attaching to an
inferior will cause GDB to first detach, and then exit.
When we quit GDB we end up calling target_detach via a different code
path, the stack looks like:
#0 target_detach
#1 kill_or_detach
#2 quit_force
#3 quit_command
Along this path there is no scoped_disable_commit_resumed created.
::commit_resumed_state can be true when we reach prepare_for_detach,
which calls target_wait and target_stop, so the assertion will trigger.
In this commit, I propose fixing this by adding the creation of a
scoped_disable_commit_resumed into target_detach. This will ensure
that ::commit_resumed_state is false when calling prepare_for_detach
from within target_detach.
I did consider placing the scoped_disable_commit_resumed in
prepare_for_detach, however, placing it in target_detach ensures that
the target's commit_resumed_state flag is left to false if the detached
inferior was the last one for that target. It's the same rationale as
for patch "gdb: disable commit resumed in target_kill" that comes later
in this series, but for detach instead of kill.
detach_command still includes a scoped_disable_commit_resumed too, but I
think it is still relevant to cover the resumption at the end of the
function.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28275
Change-Id: Ie128f7aba6ef0e018859275eca372e6ea738e96f
Factor out some bits of gdb.threads/detach-step-over.exp to procs in
preparation to adding some new variations of the test. Rename the
existing "test" proc and make it use proc_with_prefix.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ib4412545c81c8556029e0f7bfa9dd48d7a9f3189
Before doing further changes to this file, change to use the :: notation
instead of declaring global variables with the `global` keyword.
Change-Id: I72301fd8f4693fea61aac054ba17245a1f4442fb
Approved-By: Andrew Burgess <aburgess@redhat.com>
On powerpc64le-linux, using gcc 4.8.5, I run into:
...
(gdb) PASS: gdb.arch/altivec-regs.exp: next (1)
next^M
11 c = vec_add (a, b);^M
(gdb) PASS: gdb.arch/altivec-regs.exp: next (2)
print/x a^M
$67 = {0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe}^M
(gdb) FAIL: gdb.arch/altivec-regs.exp: print vector parameter a
...
Looking at the disassembly and the debug info, it's clear why there's
a FAIL.
The debug info says that the variable can be found at some stack location, but
the instructions don't seem to be writing there.
We can work around this by marking variable a volatile. Likewise for b.
Note that marking the variables as volatile doesn't change the location
information.
Tested on power64le-linux.
With test-case gdb.base/msym-bp-shl.exp on powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.base/msym-bp-shl.exp: debug=0: before run: break foo
info breakpoint^M
Num Type Disp Enb Address What^M
1 breakpoint keep y <MULTIPLE> ^M
1.1 y 0x00000000000008d4 <foo+12>^M
1.2 y 0x0000000000000a34 crti.S:88^M
(gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: info breakpoint
...
The problem is that the prologue skipper walks from foo@plt at 0xa28 to 0xa34:
...
0000000000000a28 <foo@plt>:
a28: c0 ff ff 4b b 9e8 <__glink_PLTresolve>
Disassembly of section .fini:
0000000000000a2c <_fini>:
a2c: 02 00 4c 3c addis r2,r12,2
a30: d4 74 42 38 addi r2,r2,29908
a34: a6 02 08 7c mflr r0
...
This is caused by ppc_elfv2_elf_make_msymbol_special which marks foo@plt as
having a local entry point, due to incorrectly accessing an asymbol struct
using a (larger) elf_symbol_type.
Fix this by simply ignoring artificial symbols in
ppc_elfv2_elf_make_msymbol_special.
Tested on powerpc64le.
Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
Reviewed-By: Carl Love <cel@us.ibm.com>
Tested-By: Carl Love <cel@us.ibm.com>
PR tdep/29814
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29814
* emultempl/msp430.em (add_region_prefix <REGION_EITHER>): Use
bfd_rename_section.
* testsuite/ld-msp430-elf/msp430-tiny-rom.ld: Handle varian data
and bss input sections.
Because riscv_merge_std_ext function did not merge the 'H' extension, linked
executables lacked 'H' extension when multiple objects are merged.
This issue is found while building OpenSBI with 'H' extension (resulting
ELF files did not contain "h1p0" in "Tag_RISCV_arch" even if *all* linked
object files contained it).
This commit adds 'h' to standard_exts variable to merge 'H' extension.
bfd/ChangeLog:
* elfnn-riscv.c (riscv_merge_std_ext): Add 'H' extension merging.
This commit tests both (assembler and disassembler) fixes of "Better support
for long instructions".
gas/ChangeLog:
* testsuite/gas/riscv/insn.s: Add testcases such that big number
handling is required and should be disassembled as long ".byte"
sequence with correct instruction bits.
* testsuite/gas/riscv/insn.d: Likewise.
* testsuite/gas/riscv/insn-na.d: Likewise.
* testsuite/gas/riscv/insn-dwarf.d: Likewise.
Commit bb996692bd ("RISC-V/gas: allow generating up to 176-bit
instructions with .insn") tried to start supporting long instructions but
it was insufficient.
1. It heavily depended on the bignum internals (radix of 2^16),
2. It generates "value conflicts with instruction length" even if a big
number instruction encoding does not exceed its expected length and
3. Because long opcode was handled separately (from struct riscv_cl_insn),
some information like DWARF line number correspondence was missing.
To resolve these problems, this commit:
1. Handles bignum (and its encodings) precisely and
2. Incorporates long opcode handling into regular instruction handling.
This commit will be tested on the separate commit.
gas/ChangeLog:
* config/tc-riscv.c (struct riscv_cl_insn): Add long opcode field.
(create_insn) Clear long opcode marker.
(install_insn) Install longer opcode as well.
(s_riscv_insn) Likewise.
(riscv_ip_hardcode): Make big number handling stricter. Length and
the value conflicts only if the bignum size exceeds the expected
maximum length.
Commit bb996692bd ("RISC-V/gas: allow generating up to 176-bit
instructions with .insn") tried to start supporting long instructions but
it was insufficient.
On the disassembler, correct ".byte" output was limited to the first 64-bits
of an instruction. After that, zeroes are incorrectly printed.
Note that, it only happens on ".byte" output (instruction part) and not on
hexdump (data) part. For example, before this commit, hexdump and ".byte"
produces different values:
Assembly:
.insn 22, 0xfedcba98765432100123456789abcdef55aa33cc607f
objdump output example (before the fix):
10: 607f 33cc 55aa cdef .byte 0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
18: 89ab 4567 0123 3210
20: 7654 ba98 fedc
Note that, after 0xcd (after first 64-bits of the target instruction), all
".byte" values are incorrectly printed as zero while hexdump prints correct
instruction bits.
To resolve this, this commit adds "packet" argument to support dumping
instructions longer than 64-bits (to print correct instruction bits on
".byte"). This commit will be tested on the separate commit.
Assembly:
.insn 22, 0xfedcba98765432100123456789abcdef55aa33cc607f
objdump output example (after the fix):
10: 607f 33cc 55aa cdef .byte 0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe
18: 89ab 4567 0123 3210
20: 7654 ba98 fedc
opcodes/ChangeLog:
* riscv-dis.c (riscv_disassemble_insn): Print unknown instruction
using the new argument packet.
(riscv_disassemble_data): Add unused argument packet.
(print_insn_riscv): Pass packet to the disassemble function.
Valgrind reports a leak in the dwarf reader (see details below).
The function dw2_get_file_names_reader is interning in the per_objfile
all the file names it finds, except the name of 'fnd file name and directory'.
Instead, it was xstrdup-ing the name.
Fix the leaks by also interning the name.
This was validated running the tests natively, and under valgrind.
Leaks have decreased as mentionned below.
Valgrind detected no error such as double free or use after free.
Stack trace of the leak:
==4113266== 490,735 bytes in 17,500 blocks are definitely lost in loss record 7,061 of 7,074
==4113266== at 0x483979B: malloc (vg_replace_malloc.c:393)
==4113266== by 0x25A454: xmalloc (alloc.c:57)
==4113266== by 0x7D1E1E: xstrdup (xstrdup.c:34)
==4113266== by 0x39D141: dw2_get_file_names_reader (read.c:2825)
==4113266== by 0x39D141: dw2_get_file_names(dwarf2_per_cu_data*, dwarf2_per_objfile*) (read.c:2851)
==4113266== by 0x39DD6C: dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) (read.c:4149)
==4113266== by 0x3BC8B5: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18688)
==4113266== by 0x5DD1EA: objfile::map_symtabs_matching_filename(char const*, char const*, gdb::function_view<bool (symtab*)>) (symfile-debug.c:207)
==4113266== by 0x5F04CC: iterate_over_symtabs(char const*, gdb::function_view<bool (symtab*)>) (symtab.c:633)
==4113266== by 0x477EE3: collect_symtabs_from_filename(char const*, program_space*) (linespec.c:3712)
==4113266== by 0x477FC1: symtabs_from_filename(char const*, program_space*) (linespec.c:3726)
==4113266== by 0x47A9B8: convert_explicit_location_spec_to_linespec(linespec_state*, linespec*, char const*, char const*, symbol_name_match_type, char const*, line_offset) (linespec.c:2329)
==4113266== by 0x47E86E: convert_explicit_location_spec_to_sals (linespec.c:2388)
==4113266== by 0x47E86E: location_spec_to_sals(linespec_parser*, location_spec const*) (linespec.c:3104)
==4113266== by 0x47EDAC: decode_line_full(location_spec*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) (linespec.c:3149)
...
Without the fix, the top 10 leaks are:
./gdb/testsuite/outputs/gdb.base/condbreak-bad/gdb.log:345:==3213924== definitely lost: 130,937 bytes in 5,409 blocks
./gdb/testsuite/outputs/gdb.base/hbreak2/gdb.log:619:==3758919== definitely lost: 173,323 bytes in 7,204 blocks
./gdb/testsuite/outputs/gdb.mi/mi-var-cp/gdb.log:1320:==4152873== definitely lost: 172,826 bytes in 7,207 blocks
./gdb/testsuite/outputs/gdb.base/advance-until-multiple-locations/gdb.log:398:==2992643== definitely lost: 172,965 bytes in 7,211 blocks
./gdb/testsuite/outputs/gdb.mi/mi-var-cmd/gdb.log:2302:==4159476== definitely lost: 173,129 bytes in 7,211 blocks
./gdb/testsuite/outputs/gdb.cp/gdb2384/gdb.log:222:==3811851== definitely lost: 218,106 bytes in 7,761 blocks
./gdb/testsuite/outputs/gdb.cp/mb-templates/gdb.log:310:==3787344== definitely lost: 290,311 bytes in 10,340 blocks
./gdb/testsuite/outputs/gdb.mi/mi-var-rtti/gdb.log:2568:==4158350== definitely lost: 435,427 bytes in 15,507 blocks
./gdb/testsuite/outputs/gdb.mi/mi-catch-cpp-exceptions/gdb.log:1704:==4119722== definitely lost: 435,405 bytes in 15,510 blocks
./gdb/testsuite/outputs/gdb.mi/mi-vla-fortran/gdb.log:768:==4113266== definitely lost: 508,585 bytes in 18,109 blocks
With the fix:
./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1536:==2924193== indirectly lost: 13,848 bytes in 98 blocks
./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1675:==2928777== indirectly lost: 13,848 bytes in 98 blocks
./gdb/testsuite/outputs/gdb.python/py-inferior-leak/gdb.log:4729:==3353335== definitely lost: 3,360 bytes in 140 blocks
./gdb/testsuite/outputs/gdb.base/kill-detach-inferiors-cmd/gdb.log:210:==2746927== indirectly lost: 13,246 bytes in 154 blocks
./gdb/testsuite/outputs/gdb.base/inferior-clone/gdb.log:179:==3034984== indirectly lost: 12,921 bytes in 161 blocks
./gdb/testsuite/outputs/gdb.base/interrupt-daemon/gdb.log:209:==3006248== indirectly lost: 20,683 bytes in 174 blocks
./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:714:==3512403== indirectly lost: 20,707 bytes in 175 blocks
./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:962:==3514498== indirectly lost: 20,851 bytes in 178 blocks
./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:336:==2585839== indirectly lost: 53,630 bytes in 386 blocks
./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:1338:==2592417== indirectly lost: 100,008 bytes in 1,154 blocks
Approved-By: Simon Marchi <simon.marchi@efficios.com>
valgrind reports a leak when assigning a gdb_environ to another gdb_environ.
The memory allocated for the target gdb_environ env variables is not released.
The gdb_environ selftest reproduces the leak (see below).
Fix the leak by clearing the target gdb_environ before std::move-ing the
members.
Tested natively and re-running all tests under valgrind.
==3261873== 4,842 bytes in 69 blocks are definitely lost in loss record 6,772 of 6,839
==3261873== at 0x483979B: malloc (vg_replace_malloc.c:393)
==3261873== by 0x25A454: xmalloc (alloc.c:57)
==3261873== by 0x7D1E4E: xstrdup (xstrdup.c:34)
==3261873== by 0x7E2A51: gdb_environ::from_host_environ() (environ.cc:56)
==3261873== by 0x66F1C8: test_reinit_from_host_environ (environ-selftests.c:78)
==3261873== by 0x66F1C8: selftests::gdb_environ_tests::run_tests() (environ-selftests.c:285)
==3261873== by 0x7EFC43: operator() (std_function.h:622)
=
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Some class members were changed to bool, but there was
still some assignments or comparisons using 0/1.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Consider the executable from test-case gdb.base/interrupt-daemon.exp.
When starting it using gdbserver:
...
$ ./build/gdbserver/gdbserver localhost:2345 \
./outputs/gdb.base/interrupt-daemon/interrupt-daemon
...
and connecting to it using gdb:
...
$ gdb -q -ex "target remote localhost:2345" \
-ex "set follow-fork-mode child" \
-ex "break daemon_main" -ex cont
...
we are setup to do the same as in the test-case: interrupt a running inferior
using ^C.
So let's try:
...
(gdb) continue
Continuing.
^C
...
After pressing ^C, nothing happens. This a known problem, filed as
PR remote/18772.
The problem is that in linux_process_target::request_interrupt, a kill is used
to send a SIGINT, but it fails. And it fails silently.
Make the failure verbose by adding a warning, such that the gdbserver output
becomes more helpful:
...
Process interrupt-daemon created; pid = 15068
Listening on port 2345
Remote debugging from host ::1, port 35148
Detaching from process 15068
Detaching from process 15085
gdbserver: Sending SIGINT to process group of pid 15068 failed: \
No such process
...
Note that the failure can easily be reproduced using the test-case and target
board native-gdbserver:
...
(gdb) continue^M
Continuing.^M
PASS: gdb.base/interrupt-daemon.exp: fg: continue
^CFAIL: gdb.base/interrupt-daemon.exp: fg: ctrl-c stops process (timeout)
...
as reported in PR server/23382.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
When running test-case gdb.base/bt-on-fatal-signal.exp on powerpc64le-linux I
noticed:
...
FAIL: gdb.base/bt-on-fatal-signal.exp: SEGV: scan for backtrace (timeout)
...
The timeout is 10 seconds, but generating the core file takes more than a
minute, probably due to slow NFS.
I managed to reproduce this behaviour independently of gdb, by compiling
"int main (void) { __builtin_abort (); }" and running it, which took 1.5
seconds for a core file 50 times smaller than the one for gdb.
Fix this by preventing the core file from being generated, using a wrapper
around gdb that does "ulimit -c 0".
Tested on x86_64-linux.
If we instrument cc-with-tweaks.sh to remove the .gnu_debugaltlink file after
dwz has created it, with test-case
gdb.threads/access-mem-running-thread-exit.exp and target board cc-with-dwz-m
we run into:
...
(gdb) file access-mem-running-thread-exit^M
Reading symbols from access-mem-running-thread-exit...^M
could not find '.gnu_debugaltlink' file for access-mem-running-thread-exit^M
...
followed a bit later by:
...
(gdb) file access-mem-running-thread-exit^M
Reading symbols from access-mem-running-thread-exit...^M
gdb/dwarf2/read.c:7284: internal-error: create_all_units: \
Assertion `per_objfile->per_bfd->all_units.empty ()' failed.^M
...
The problem is that create_units does not catch the error thrown by
dwarf2_get_dwz_file.
Fix this by catching the error and performing the necessary cleanup, getting
the same result for the first and second file command.
PR symtab/29805
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29805
xrefautomaticsectiontitle appears to be available from texinfo 5.0 or
greater. As such, it is not worthwhile to add requirement for a minimum
necessary makeinfo version. So remove the usage of it.
Also align node name with section title where possible.
ChangeLog:
* libsframe/doc/sframe-spec.texi: Remove usage of
xrefautomaticsectiontitle.
Move all the remaining tests to a single test_break proc. It's a bit
big, but all of these are kind of tied together. The procs starts by
setting breakpoints, checks that we can see them in "info breakpoints",
and tries stopping on them.
Move all the "set bp_locationX" calls together at the top.
Change-Id: Id05f98957e1a3462532d2dbd577cd0a7c7263900
Approved-By: Kevin Buettner <kevinb@redhat.com>
Leave setting bp_location11 in the global scope, so that it's accessible
to other procs.
Change-Id: I8928f01640d3a1e993649b2168b9eda0724ee1d9
Approved-By: Kevin Buettner <kevinb@redhat.com>
One special thing here is that the part just above this one, that sets
catchpoints and verifies they are not hit, requires that we resume
execution to verify that the catchpoints are indeed not hit. I guess
it was previously achieved by the until command, but it doesn't happen
now that the until is moved into test_break_default. Add a
gdb_continue_to_end after setting the catchpoints. If any catchpoint
were to be hit, it would catch the problem.
Change-Id: I5d4b43da91886b1beda9f6e56b05aa04331a9c05
Approved-By: Kevin Buettner <kevinb@redhat.com>
This one is a bit tricky. The clear tests seem to depend on the various
breakpoints that have been set before, starting with the "silent"
breakpoints. So, move all this in a single chunk, it can always be
split later if needed.
Change-Id: I7ba61a5b130ade63eda0c4790534840339f8a72f
Approved-By: Kevin Buettner <kevinb@redhat.com>
This one is already in a proc, just make the proc use proc_with_prefix,
for consistency.
Change-Id: I313ecf5097ff04526c29396529baeba84e37df5a
Approved-By: Kevin Buettner <kevinb@redhat.com>
First of all make operand_type_register_match() apply to all sized
operands, i.e. in Intel Syntax also to respective memory ones. This
addresses gas wrongly accepting certain SIMD insns where register and
memory operand sizes should match but don't. This apparently has
affected all templates with one memory-only operand and one or more
register ones, both permitting at least two sizes, due to CheckRegSize
not taking effect.
Then also add CheckRegSize to a couple of non-SIMD templates matching
that same pattern of memory-only vs register operands. This replaces
bogus (for Intel Syntax) diagnostics referring to a wrong suffix (when
none was used at all) by "type mismatch" ones, just like already emitted
for insns where the template allows a register operand alongside a
memory one at any particular position.
This also is a prereq to limiting (ideally eliminating in the long run)
suffix "derivation" in Intel Syntax mode.
While making the code adjustment also flip order of checks to do the
cheaper one first in both cases.
To properly and predictably determine operand size encoding (operand
size or REX.W prefixes), consistent operand sizes need to be specified.
Add CheckRegSize where this was previously missing.
Both uniformly only ever take 16-bit memory operands while at the same
time requiring matching (in size) register operands, which then also
should disassemble that way. This in particular requires splitting each
of the templates for the assembler and separating decode of the
register and memory forms in the disassembler.
