Objcopy was used to create a binary file of just the executable code
since the environment requires code to based at address 0. We can
accomplish the same thing with the -Ttext=0 flag, so switch to that
to get rid of custom logic.
Simon pointed out that my recent patches to .debug_loclists caused
some regressions. After a brief discussion we realized it was because
his system compiler defaults to PIE.
This patch changes this code to unconditionally apply the text offset
here. It also changes loclist_describe_location to work more like
dwarf2_find_location_expression.
I tested this by running the gdb.dwarf2 tests both with and without
-pie.
This patch is adding support for Cortex-A710 CPU in Arm.
bfd/
* cpu-arm.c (processors): Add cortex-a710.
gas/
* NEWS: Update docs.
* config/tc-arm.c (arm_cpus): Add cortex-a710 to -mcpu.
* doc/c-arm.texi: Update docs.
* testsuite/gas/arm/cpu-cortex-a710.d: New test.
Commit e86fc4a5bc ("PR 28447: implement multiple parameters for .file
on XCOFF") changes the structure associated to the internal
representation of files in COFF formats. However, gdb directory update
has been forgotten, leading to compilation errors of this kind:
CXX coffread.o
/home/simark/src/binutils-gdb/gdb/coffread.c: In function 'const char* coff_getfilename(internal_auxent*)':
/home/simark/src/binutils-gdb/gdb/coffread.c:1343:29: error: 'union internal_auxent::<unnamed struct>::<unnamed>' has no member named 'x_zeroes'
1343 | if (aux_entry->x_file.x_n.x_zeroes == 0)
| ^~~~~~~~
Fix it by adjusting the COFF code in GDB.
Change-Id: I703fa134bc722d47515efbd72b88fa5650af6c3c
Add a test-case to excercise the problem scenario reported in PR28527 and
fixed in commit a50bdb99af "[gdb/tdep, rs6000] Don't skip system call in
skip_prologue":
- set a breakpoint on _exit, and
- verify that it triggers.
Note that this is not a regression test for that commit. Since the actual
code in _exit may vary across os instances, we cannot guarantee that the
problem will always trigger with this test-case.
Rather, this test-case is a version of the original test-case
(gdb.threads/process-dies-while-detaching.exp) that is minimal while still
reproducing the problem reported in PR28527, in that same setting.
The benefit of this test-case is that it exercise real-life code and may
expose similar problems in other settings. Also, it provides a much easier
test-case to investigate in case a similar problem occurs.
Tested on x86_64-linux and ppc64le-linux.
When I refactored this by scoping it to sim-frv-xxx in commit
e7954ef5e5 ("sim: frv: scope the
unique configure flag"), I changed the default from off to on.
While the feature is nice for developers, it breaks a bunch of
tests which aren't expecting this extra output. So flip it back
to off by default.
Since --unicode support (commit b3aa80b45c) both binutils/readelf.c
and binutils/strings.c use 'uint' in a few locations. It likely
should be 'unsigned int' since there isn't anything defining 'uint'
within binutils (besides zlib) and AFAIK it isn't a standard type.
* readelf.c (print_symbol): Replace uint with unsigned int.
* strings.c (string_min, display_utf8_char): Likewise.
(print_unicode_stream_body, print_unicode_stream): Likewise.
(print_strings): Likewise.
(get_unicode_byte): Wrap long line.
Previous flags were aimed to be run with XLC.
Nowadays, only GCC is being tested with GNU toolchain. Moreover,
recent XLC versions might also accept "-shared".
* testsuite/ld-shared/shared.exp: Adjust shared flags.
The purpose of this test is described in the comments in
dprintf-execution-x-script.exp.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28308
The name of this new test was based on that of an existing test,
bp-cmds-execution-x-script.exp. I started off by copying that test,
adding to it, and then rewriting almost all of it. It's different
enough that I decided that listing the copyright year as 2021
was sufficient.
This commit fixes Bug 28308, titled "Strange interactions with
dprintf and break/commands":
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28308
Since creating that bug report, I've found a somewhat simpler way of
reproducing the problem. I've encapsulated it into the GDB test case
which I've created along with this bug fix. The name of the new test
is gdb.base/dprintf-execution-x-script.exp, I'll demonstrate the
problem using this test case, though for brevity, I've placed all
relevant files in the same directory and have renamed the files to all
start with 'dp-bug' instead of 'dprintf-execution-x-script'.
The script file, named dp-bug.gdb, consists of the following commands:
dprintf increment, "dprintf in increment(), vi=%d\n", vi
break inc_vi
commands
continue
end
run
Note that the final command in this script is 'run'. When 'run' is
instead issued interactively, the bug does not occur. So, let's look
at the interactive case first in order to see the correct/expected
output:
$ gdb -q -x dp-bug.gdb dp-bug
... eliding buggy output which I'll discuss later ...
(gdb) run
Starting program: /mesquite2/sourceware-git/f34-master/bld/gdb/tmp/dp-bug
vi=0
dprintf in increment(), vi=0
Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
26 in dprintf-execution-x-script.c
vi=1
dprintf in increment(), vi=1
Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
26 in dprintf-execution-x-script.c
vi=2
dprintf in increment(), vi=2
Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
26 in dprintf-execution-x-script.c
vi=3
[Inferior 1 (process 1539210) exited normally]
In this run, in which 'run' was issued from the gdb prompt (instead
of at the end of the script), there are three dprintf messages along
with three 'Breakpoint 2' messages. This is the correct output.
Now let's look at the output that I snipped above; this is the output
when 'run' is issued from the script loaded via GDB's -x switch:
$ gdb -q -x dp-bug.gdb dp-bug
Reading symbols from dp-bug...
Dprintf 1 at 0x40116e: file dprintf-execution-x-script.c, line 38.
Breakpoint 2 at 0x40113a: file dprintf-execution-x-script.c, line 26.
vi=0
dprintf in increment(), vi=0
Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
26 dprintf-execution-x-script.c: No such file or directory.
vi=1
Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
26 in dprintf-execution-x-script.c
vi=2
Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
26 in dprintf-execution-x-script.c
vi=3
[Inferior 1 (process 1539175) exited normally]
In the output shown above, only the first dprintf message is printed.
The 2nd and 3rd dprintf messages are missing! However, all three
'Breakpoint 2...' messages are still printed.
Why does this happen?
bpstat_do_actions_1() in gdb/breakpoint.c contains the following
comment and code near the start of the function:
/* Avoid endless recursion if a `source' command is contained
in bs->commands. */
if (executing_breakpoint_commands)
return 0;
scoped_restore save_executing
= make_scoped_restore (&executing_breakpoint_commands, 1);
Also, as described by this comment prior to the 'async' field
in 'struct ui' in top.h, the main UI starts off in sync mode
when processing command line arguments:
/* True if the UI is in async mode, false if in sync mode. If in
sync mode, a synchronous execution command (e.g, "next") does not
return until the command is finished. If in async mode, then
running a synchronous command returns right after resuming the
target. Waiting for the command's completion is later done on
the top event loop. For the main UI, this starts out disabled,
until all the explicit command line arguments (e.g., `gdb -ex
"start" -ex "next"') are processed. */
This combination of things, the state of the static global
'executing_breakpoint_commands' plus the state of the async
field in the main UI causes this behavior.
This is a backtrace after hitting the dprintf breakpoint for
the second time when doing 'run' from the script file, i.e.
non-interactively:
Thread 1 "gdb" hit Breakpoint 3, bpstat_do_actions_1 (bsp=0x7fffffffc2b8)
at /ironwood1/sourceware-git/f34-master/bld/../../worktree-master/gdb/breakpoint.c:4431
4431 if (executing_breakpoint_commands)
#0 bpstat_do_actions_1 (bsp=0x7fffffffc2b8)
at gdb/breakpoint.c:4431
#1 0x00000000004d8bc6 in dprintf_after_condition_true (bs=0x1538090)
at gdb/breakpoint.c:13048
#2 0x00000000004c5caa in bpstat_stop_status (aspace=0x116dbc0, bp_addr=0x40116e, thread=0x137f450, ws=0x7fffffffc718,
stop_chain=0x1538090) at gdb/breakpoint.c:5498
#3 0x0000000000768d98 in handle_signal_stop (ecs=0x7fffffffc6f0)
at gdb/infrun.c:6172
#4 0x00000000007678d3 in handle_inferior_event (ecs=0x7fffffffc6f0)
at gdb/infrun.c:5662
#5 0x0000000000763cd5 in fetch_inferior_event ()
at gdb/infrun.c:4060
#6 0x0000000000746d7d in inferior_event_handler (event_type=INF_REG_EVENT)
at gdb/inf-loop.c:41
#7 0x00000000007a702f in handle_target_event (error=0, client_data=0x0)
at gdb/linux-nat.c:4207
#8 0x0000000000b8cd6e in gdb_wait_for_event (block=block@entry=0)
at gdbsupport/event-loop.cc:701
#9 0x0000000000b8d032 in gdb_wait_for_event (block=0)
at gdbsupport/event-loop.cc:597
#10 gdb_do_one_event () at gdbsupport/event-loop.cc:212
#11 0x00000000009d19b6 in wait_sync_command_done ()
at gdb/top.c:528
#12 0x00000000009d1a3f in maybe_wait_sync_command_done (was_sync=0)
at gdb/top.c:545
#13 0x00000000009d2033 in execute_command (p=0x7fffffffcb18 "", from_tty=0)
at gdb/top.c:676
#14 0x0000000000560d5b in execute_control_command_1 (cmd=0x13b9bb0, from_tty=0)
at gdb/cli/cli-script.c:547
#15 0x000000000056134a in execute_control_command (cmd=0x13b9bb0, from_tty=0)
at gdb/cli/cli-script.c:717
#16 0x00000000004c3bbe in bpstat_do_actions_1 (bsp=0x137f530)
at gdb/breakpoint.c:4469
#17 0x00000000004c3d40 in bpstat_do_actions ()
at gdb/breakpoint.c:4533
#18 0x00000000006a473a in command_handler (command=0x1399ad0 "run")
at gdb/event-top.c:624
#19 0x00000000009d182e in read_command_file (stream=0x113e540)
at gdb/top.c:443
#20 0x0000000000563697 in script_from_file (stream=0x113e540, file=0x13bb0b0 "dp-bug.gdb")
at gdb/cli/cli-script.c:1642
#21 0x00000000006abd63 in source_gdb_script (extlang=0xc44e80 <extension_language_gdb>, stream=0x113e540,
file=0x13bb0b0 "dp-bug.gdb") at gdb/extension.c:188
#22 0x0000000000544400 in source_script_from_stream (stream=0x113e540, file=0x7fffffffd91a "dp-bug.gdb",
file_to_open=0x13bb0b0 "dp-bug.gdb")
at gdb/cli/cli-cmds.c:692
#23 0x0000000000544557 in source_script_with_search (file=0x7fffffffd91a "dp-bug.gdb", from_tty=1, search_path=0)
at gdb/cli/cli-cmds.c:750
#24 0x00000000005445cf in source_script (file=0x7fffffffd91a "dp-bug.gdb", from_tty=1)
at gdb/cli/cli-cmds.c:759
#25 0x00000000007cf6d9 in catch_command_errors (command=0x5445aa <source_script(char const*, int)>,
arg=0x7fffffffd91a "dp-bug.gdb", from_tty=1, do_bp_actions=false)
at gdb/main.c:523
#26 0x00000000007cf85d in execute_cmdargs (cmdarg_vec=0x7fffffffd1b0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND,
ret=0x7fffffffd18c) at gdb/main.c:615
#27 0x00000000007d0c8e in captured_main_1 (context=0x7fffffffd3f0)
at gdb/main.c:1322
#28 0x00000000007d0eba in captured_main (data=0x7fffffffd3f0)
at gdb/main.c:1343
#29 0x00000000007d0f25 in gdb_main (args=0x7fffffffd3f0)
at gdb/main.c:1368
#30 0x00000000004186dd in main (argc=5, argv=0x7fffffffd508)
at gdb/gdb.c:32
There are two frames for bpstat_do_actions_1(), one at frame #16 and
the other at frame #0. The one at frame #16 is processing the actions
for Breakpoint 2, which is a 'continue'. The one at frame #0 is attempting
to process the dprintf breakpoint action. However, at this point,
the value of 'executing_breakpoint_commands' is 1, forcing an early
return, i.e. prior to executing the command(s) associated with the dprintf
breakpoint.
For the sake of comparison, this is what the stack looks like when hitting
the dprintf breakpoint for the second time when issuing the 'run'
command from the GDB prompt.
Thread 1 "gdb" hit Breakpoint 3, bpstat_do_actions_1 (bsp=0x7fffffffccd8)
at /ironwood1/sourceware-git/f34-master/bld/../../worktree-master/gdb/breakpoint.c:4431
4431 if (executing_breakpoint_commands)
#0 bpstat_do_actions_1 (bsp=0x7fffffffccd8)
at gdb/breakpoint.c:4431
#1 0x00000000004d8bc6 in dprintf_after_condition_true (bs=0x16b0290)
at gdb/breakpoint.c:13048
#2 0x00000000004c5caa in bpstat_stop_status (aspace=0x116dbc0, bp_addr=0x40116e, thread=0x13f0e60, ws=0x7fffffffd138,
stop_chain=0x16b0290) at gdb/breakpoint.c:5498
#3 0x0000000000768d98 in handle_signal_stop (ecs=0x7fffffffd110)
at gdb/infrun.c:6172
#4 0x00000000007678d3 in handle_inferior_event (ecs=0x7fffffffd110)
at gdb/infrun.c:5662
#5 0x0000000000763cd5 in fetch_inferior_event ()
at gdb/infrun.c:4060
#6 0x0000000000746d7d in inferior_event_handler (event_type=INF_REG_EVENT)
at gdb/inf-loop.c:41
#7 0x00000000007a702f in handle_target_event (error=0, client_data=0x0)
at gdb/linux-nat.c:4207
#8 0x0000000000b8cd6e in gdb_wait_for_event (block=block@entry=0)
at gdbsupport/event-loop.cc:701
#9 0x0000000000b8d032 in gdb_wait_for_event (block=0)
at gdbsupport/event-loop.cc:597
#10 gdb_do_one_event () at gdbsupport/event-loop.cc:212
#11 0x00000000007cf512 in start_event_loop ()
at gdb/main.c:421
#12 0x00000000007cf631 in captured_command_loop ()
at gdb/main.c:481
#13 0x00000000007d0ebf in captured_main (data=0x7fffffffd3f0)
at gdb/main.c:1353
#14 0x00000000007d0f25 in gdb_main (args=0x7fffffffd3f0)
at gdb/main.c:1368
#15 0x00000000004186dd in main (argc=5, argv=0x7fffffffd508)
at gdb/gdb.c:32
This relatively short backtrace is due to the current UI's async field
being set to 1.
Yet another thing to be aware of regarding this problem is the
difference in the way that commands associated to dprintf breakpoints
versus regular breakpoints are handled. While they both use a command
list associated with the breakpoint, regular breakpoints will place
the commands to be run on the bpstat chain constructed in
bp_stop_status(). These commands are run later on. For dprintf
breakpoints, commands are run via the 'after_condition_true' function
pointer directly from bpstat_stop_status(). (The 'commands' field in
the bpstat is cleared in dprintf_after_condition_true(). This
prevents the dprintf commands from being run again later on when other
commands on the bpstat chain are processed.)
Another thing that I noticed is that dprintf breakpoints are the only
type of breakpoint which use 'after_condition_true'. This suggests
that one possible way of fixing this problem, that of making dprintf
breakpoints work more like regular breakpoints, probably won't work.
(I must admit, however, that my understanding of this code isn't
complete enough to say why. I'll trust that whoever implemented it
had a good reason for doing it this way.)
The comment referenced earlier regarding 'executing_breakpoint_commands'
states that the reason for checking this variable is to avoid
potential endless recursion when a 'source' command appears in
bs->commands. We know that a dprintf command is constrained to either
1) execution of a GDB printf command, 2) an inferior function call of
a printf-like function, or 3) execution of an agent-printf command.
Therefore, infinite recursion due to a 'source' command cannot happen
when executing commands upon hitting a dprintf breakpoint.
I chose to fix this problem by having dprintf_after_condition_true()
directly call execute_control_commands(). This means that it no
longer attempts to go through bpstat_do_actions_1() avoiding the
infinite recursion check for potential 'source' commands on the
command chain. I think it simplifies this code a little bit too, a
definite bonus.
Summary:
* breakpoint.c (dprintf_after_condition_true): Don't call
bpstat_do_actions_1(). Call execute_control_commands()
instead.
This little tweak terminates fuzzed binary readelf output a little
quicker.
PR 28543
* dwarf.c (read_and_display_attr_value): Consume a byte when
form is unrecognized.
PR 28542
* readelf.c (dump_relocations): Check that section headers have
been read before attempting to access section name.
(print_dynamic_symbol): Likewise.
(process_mips_specific): Delete dead code.
This test fails for me, showing:
ERROR: tcl error sourcing /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.debuginfod/fetch_src_and_symbols.exp.
ERROR: This GDB was configured as follows:
configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-auto-load-dir=$debugdir:$datadir/auto-load
--with-auto-load-safe-path=$debugdir:$datadir/auto-load
... and much more ...
The problem is that TCL's exec throws an error as soon as the exec'ed
process outputs on stderr. When GDB is built with ASan, it prints some
warnings about pre-existing signal handlers:
warning: Found custom handler for signal 7 (Bus error) preinstalled.
warning: Found custom handler for signal 8 (Floating point exception) preinstalled.
warning: Found custom handler for signal 11 (Segmentation fault) preinstalled.
Pass --quiet to GDB to avoid these warnings.
Change-Id: I3751d89b9b1df646da19149d7cb86775e2d3e80f
When the code to handle DW_LLE_start_end was added (as part of some
DWARF 5 work), it was written to add the base address. However, this
seems incorrect -- the DWARF standard describes this as an address,
not an offset from the base address.
This patch changes a couple of spots in dwarf2/loc.c to fix this
problem. It then changes decode_debug_loc_addresses to return
DEBUG_LOC_OFFSET_PAIR instead, which preserves the previous semantics.
This only showed up on the RISC-V target internally, due to the
combination of DWARF 5 and a newer version of GCC. I've updated a
couple of existing loclists test cases to demonstrate the bug.
The rhES5 build failed due to an upstream import a while back. The
bug here is that, while the 'personality' function exists,
ADDR_NO_RANDOMIZE is only defined in <linux/personality.h>, not
<sys/personality.h>.
However, <linux/personality.h> does not declare the 'personality'
function, and <sys/personality.h> and <linux/personality.h> cannot
both be included.
This patch restores one of the removed configure checks and updates
the code to check it.
We had this as a local patch at AdaCore, because it seemed like there
was no interest upstream. However, now it turns out that this fixes
PR build/28555, so I'm sending it now.
Remove @validatemenus from ctf-spec.texi, which has been removed from
texinfo by
commit a16dd1a9ece08568a1980b9a65a3a9090717997f
Author: Gavin Smith <gavinsmith0123@gmail.com>
Date: Mon Oct 12 16:32:37 2020 +0100
* doc/texinfo.texi
(Writing a Menu, Customization Variables for @-Commands)
(Command List),
* doc/refcard/txirefcard.tex
Remove @validatemenus.
* tp/Texinfo/XS/Makefile.am (command_ids.h): Use gawk instead
of awk. Avoid discouraged "$p" usage, using "$(p)" instead.
* tp/Texinfo/XS/configure.ac: Check for gawk.
commit 128acab3889b51809dc3bd3c6c74b61d13f7f5f4
Author: Gavin Smith <gavinsmith0123@gmail.com>
Date: Thu Jan 3 14:51:53 2019 +0000
Update refcard.
* doc/refcard/txirefcard.tex: @setfilename is no longer
mandatory. Do not mention @validatemenus or explicitly giving
@node pointers, as these are not very important features.
PR libctf/28567
* doc/ctf-spec.texi: Remove "@validatemenus off".
* nm.c: Add --unicode option to control how unicode characters are
handled.
* objdump.c: Likewise.
* readelf.c: Likewise.
* strings.c: Likewise.
* binutils.texi: Document the new feature.
* NEWS: Document the new feature.
* testsuite/binutils-all/unicode.exp: New file.
* testsuite/binutils-all/nm.hex.unicode
* testsuite/binutils-all/strings.escape.unicode
* testsuite/binutils-all/objdump.highlight.unicode
* testsuite/binutils-all/readelf.invalid.unicode
Switch from the centralized list in the exp file to each test declaring
its own requirements which they're already (mostly) doing. This will
increase coverage slightly by running more tests in more configurations
since the hardcoded exp list was a little out of date.
We have to mark the psh* tests as shdsp only (to match what the exp
file was doing), mark the fsca & fsrra tests as failing (since they
weren't even being run by the exp file), and to fix the expected
output & status of the fail test.
Move some unused funcs under existing #if 0 protection, mark a few
local funcs as static, and add missing prototypes for the rest which
are used from other files. This fixes all the fatal warnings in the
mloop files so we can turn -Werror on here fully.
While reading the interface of gdb::array_view, I realized that the
constructor that builds an array_view on top of a contiguous container
(such as std::vector, std::array or even gdb::array_view) can be
missused.
Lets consider the following code sample:
struct Parent
{
Parent (int a): a { a } {}
int a;
};
std::ostream &operator<< (std::ostream& os, const Parent & p)
{ os << "Parent {a=" << p.a << "}"; return os; }
struct Child : public Parent
{
Child (int a, int b): Parent { a }, b { b } {}
int b;
};
std::ostream &operator<< (std::ostream& os, const Child & p)
{ os << "Child {a=" << p.a << ", b=" << p.b << "}"; return os; }
template <typename T>
void print (const gdb::array_view<const T> &p)
{
std::for_each (p.begin (), p.end (), [](const T &p) { std::cout << p << '\n'; });
}
Then with the current interface nothinng prevents this usage of
array_view to be done:
const std::array<Child, 3> elts = {
Child {1, 2},
Child {3, 4},
Child {5, 6}
};
print_all<Parent> (elts);
This compiles fine and produces the following output:
Parent {a=1}
Parent {a=2}
Parent {a=3}
which is obviously wrong. There is nowhere in memory a Parent-like
object for which the A member is 2 and this call to print_all<Parent>
shold not compile at all (calling print_all<Child> is however fine).
This comes down to the fact that a Child* is convertible into a Parent*,
and that an array view is constructed to a pointer to the first element
and a size. The valid type pointed to that can be used with this
constructor are restricted using SFINAE, which requires that a
pointer to a member into the underlying container can be converted into a
pointer the array_view's data type.
This patch proposes to change the constraints on the gdb::array_view
ctor which accepts a container now requires that the (decayed) type of
the elements in the container match the (decayed) type of the array_view
being constructed.
Applying this change required minimum adjustment in GDB codebase, which
are also included in this patch.
Tested by rebuilding.
This commits adds const versions for the GET and AS_ARRAX_VIEW methods
of gdb_argv. Those methods will be required in the following patch of
the series.
When doing "continue -a" in non-stop mode, each thread is individually
resumed while the commit resumed state is enabled. This forces the
target to commit each resumption immediately, instead of being able to
batch things.
The reason is that there is no scoped_disable_commit_resumed around the
loop over threads in continue_1, when "non_stop && all_threads" is true.
Since the proceed function is called once for each thread, the
scoped_disable_commit_resumed in proceed therefore forces commit-resumed
between each thread resumption. Add the necessary
scoped_disable_commit_resumed in continue_1 to avoid that.
I looked at the MI side of things, the function exec_continue, and found
that it was correct. There is a similar iteration over threads, and
there is a scoped_disable_commit_resumed at the function scope. This is
not wrong, but a bit more than we need. The branches that just call
continue_1 do not need it, as continue_1 takes care of disabling commit
resumed. So, move the scoped_disable_commit_resumed to the inner scope
where we iterate on threads and proceed them individually.
Here's an example debugging a multi-threaded program attached by
gdbserver (debug output trimmed for brevity):
$ ./gdb -nx -q --data-directory=data-directory -ex "set non-stop" -ex "tar rem :1234"
(gdb) set debug remote
(gdb) set debug infrun
(gdb) c -a
Continuing.
[infrun] proceed: enter
[infrun] scoped_disable_commit_resumed: reason=proceeding
[remote] Sending packet: $vCont;c:p14388.14388#90
[infrun] reset: reason=proceeding
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
[infrun] proceed: exit
[infrun] proceed: enter
[infrun] scoped_disable_commit_resumed: reason=proceeding
[remote] Sending packet: $vCont;c:p14388.1438a#b9
[infrun] reset: reason=proceeding
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
[infrun] proceed: exit
... and so on for each thread ...
Notice how we send one vCont;c for each thread. With the patch applied, we
send a single vCont;c at the end:
[infrun] scoped_disable_commit_resumed: reason=continue all threads in non-stop
[infrun] proceed: enter
[infrun] scoped_disable_commit_resumed: reason=proceeding
[infrun] reset: reason=proceeding
[infrun] proceed: exit
[infrun] clear_proceed_status_thread: Thread 85790.85792
[infrun] proceed: enter
[infrun] scoped_disable_commit_resumed: reason=proceeding
[infrun] reset: reason=proceeding
[infrun] proceed: exit
... proceeding threads individually ...
[infrun] reset: reason=continue all threads in non-stop
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
[remote] Sending packet: $vCont;c#a8
Change-Id: I331dd2473c5aa5114f89854196fed2a8fdd122bb
While reading another patch, I saw that this function didn't need to
take a dwarf2_per_objfile, but could take a dwarf2_per_bfd instead.
It doesn't change the behavior, but doing this shows that this function
is objfile-independent (can work with only the shared per-bfd data).
Change-Id: I58f9c9cef6688902e95226480285da2d0005d77f
I don't find that the bpstat typedef, which hides a pointer, is
particularly useful. In fact, it confused me many times, and I just see
it as something to remember that adds cognitive load. Also, with C++,
we might want to be able to pass bpstats objects by const-reference, not
necessarily by pointer.
So, remove the bpstat typedef and rename struct bpstats to bpstat (since
it represents one bpstat, it makes sense that it is singular).
Change-Id: I52e763b6e54ee666a9e045785f686d37b4f5f849
It's been a long time since most of this was written: it's long past
time to put it in the binutils source tree. It's believed correct and
complete insofar as it goes: it documents format v3 (the current
version) but not the libctf API or any earlier versions. (The
earlier versions can be read by libctf but not generated by it, and you
are highly unlikely ever to see an example of any of them.)
libctf/ChangeLog
2021-11-08 Nick Alcock <nick.alcock@oracle.com>
* doc/ctf-spec.texi: New file.
* configure.ac (MAKEINFO): Add.
(BUILD_INFO): Likewise.
(AC_CONFIG_FILES) [doc/Makefile]: Add.
* Makefile.am [BUILD_INFO] (SUBDIRS): Add doc/.
* doc/Makefile.am: New file.
* doc/Makefile.in: Likewise.
* configure: Regenerated.
* Makefile.in: Likewise.
On LLP64 targets where sizeof(long) != sizeof(void*), this code fails:
sim/sh/interp.c:704:24: error: cast from pointer to integer of different size -Werror=pointer-to-int-cast]
704 | do { memstalls += ((((long) PC & 3) != 0) ? (n) : ((n) - 1)); } while (0)
| ^
Since this code simply needs to check alignment, cast it using uintptr_t
which is the right type for this.
Casting 0 to a pointer via (long *) doesn't work on LLP64 targets:
error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
It's also unnecessary here. We can simply pass NULL like every other
bit of code does.
The code assumes that all _WIN32 targets are the same and can
define isnan to _isnan. For mingw targets, they provide an isnan
define already, so no need for the fallback here.
Some targets (like cygwin) will export page size defines that clash
with our local usage here. Undefine the system one to fix building
for these targets.
With most of the warnings fixed in interp.c, we can enable -Werror
here too now. There are some -Wmaybe-uninitialized warnings still
lurking that look legitimate, but we don't flag those are fatal,
and I don't have the expertise to dive into each opcode to figure
out the right way to clean them up.
This block of code relies on i to control which bits to test and how
many times to run through the loop, but it never actually initialized
it. There is another chunk of code that handles the pdmsb instruction
that sets i to 16, so use that here too assuming it's correct. The
programming manual suggests this is the right value too, but I am by
no means a SuperH DSP expert. The tests are still passing though ...
These macro expansions are deliberate in not using the computed value
so that they trigger side-effects (possible invalid memory accesses)
but while otherwise being noops. Add a (void) cast so the compiler
knows these are intentional.
Now that we require C11, we can leverage anonymous unions & structs
to fix a long standing issue with the SH register layout. The use
of sregs.i for sh-dsp has generated a lot of compiler warnings about
the access being out of bounds -- it only has 7 elements declared,
but code goes beyond that to reach into the fregs that follow. But
now that we have anonymous unions, we can reduce the nested names
and have sregs cover all of these registers.
Since the first argument type is unsigned32 or unsigned64, just use
sim_fpu_to{32,64}u instead of sim_fpu_to{32,64}i to fix the following
build warnings:
CC cp1.o
.../sim/mips/cp1.c: In function 'convert':
.../sim/mips/cp1.c:1425:32: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
status |= sim_fpu_to32i (&result32, &wop, round);
^~~~~~~~~
In file included from .../sim/mips/sim-main.h:67,
from .../sim/mips/cp1.c:46:
.../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
^~~~~~~~~~~~~
.../sim/mips/cp1.c:1429:32: warning: pointer targets in passing argument 1 of 'sim_fpu_to64i' differ in signedness [-Wpointer-sign]
status |= sim_fpu_to64i (&result64, &wop, round);
^~~~~~~~~
In file included from .../sim/mips/sim-main.h:67,
from .../sim/mips/cp1.c:46:
.../sim/mips/../common/sim-fpu.h:274:22: note: expected 'signed64 *' {aka 'long int *'} but argument is of type 'unsigned64 *' {aka 'long unsigned int *'}
INLINE_SIM_FPU (int) sim_fpu_to64i (signed64 *i, const sim_fpu *f,
^~~~~~~~~~~~~
.../sim/mips/cp1.c: In function 'convert_ps':
.../sim/mips/cp1.c:1528:34: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
status_u |= sim_fpu_to32i (&res_u, &wop_u, round);
^~~~~~
In file included from .../sim/mips/sim-main.h:67,
from .../sim/mips/cp1.c:46:
.../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
^~~~~~~~~~~~~
.../sim/mips/cp1.c:1529:34: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
status_l |= sim_fpu_to32i (&res_l, &wop_l, round);
^~~~~~
In file included from .../sim/mips/sim-main.h:67,
from .../sim/mips/cp1.c:46:
.../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
^~~~~~~~~~~~~
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
