Another bug exposed by gdb.server/extended-remote-restart.exp in the
multi-target work is that remote_target::start_remote can leave
inferior_ptid and current_inferior() out of sync:
(top-gdb) p current_inferior_->pid
$1 = 29541
(top-gdb) p inferior_ptid
$2 = {m_pid = 29540, m_lwp = 29540, m_tid = 0}
This is caused by writing to inferior_ptid directly instead of using
switch_to_thread. Also, "inferior_list->thread_list->ptid" assumes
that we want the first thread of the first inferior, but that inferior
may not have threads, or with multi-target, that target may be
connected to some other target.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* remote.c (remote_target::start_remote): Don't set inferior_ptid
directly. Instead find the first thread in the thread list and
use switch_to_thread.
The multi-target patch will change the remote target's behavior when:
- the current inferior is connected to an extended-remote target.
- the current inferior is attached to any process.
- some other inferior than than the current one is live.
In current master, we get:
(gdb) tar extended-remote :9999
A program is being debugged already. Kill it? (y or n)
While after multi-target, since each inferior may have its own target
connection, we'll get:
(gdb) tar extended-remote :9999
Already connected to a remote target. Disconnect? (y or n)
That change made gdb.server/extended-remote-restart.exp expose a gdb
bug, because it made "target remote", via gdb_reconnect, just
disconnect from the previous connection, while in current master that
command would kill the inferior before disconnecting. In turn, that
would make a multi-target gdb find processes already running under
control of gdbserver as soon as it reconnects, while in current master
there is never any process around when gdb reconnects, since they'd
all been killed prior to disconnection.
The bug this exposed is that remote_target::remote_add_inferior was
always reusing current_inferior() for the new process, even if the
current inferior was already bound to a process. In the testcase's
case, when we reconnect, the remote is debugging two processes. So
we'd bind the first remote process to the empty current inferior the
first time, and then bind the second remote process to the same
inferior again, essencially losing track of the first process. That
resulted in failed assertions when we look up the inferior for the
first process by PID. The fix is to still prefer binding to the
current inferior (so that plain "target remote" keeps doing what you'd
expect), but not reuse the current inferior if it is already bound to
a process.
This patch tweaks the test to explicitly disconnect before
reconnecting, to avoid GDB killing processes, thus making current GDB
behave the same as it will behave when the multi-target work lands.
That change alone without the GDB fix exposes the bug like so:
(gdb) PASS: gdb.server/extended-remote-restart.exp: kill: 0, follow-child 0: disconnect
target extended-remote localhost:2350
Remote debugging using localhost:2350
src/gdb/thread.c:93: internal-error: thread_info* inferior_thread(): Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
The original bug that the testcase was written for was related to
killing, (git 9d4a934ce6 ("gdb: Fix assert for extended-remote
target (PR gdb/18050)")), but since the testcase tries reconnecting
with both explicitly killing and not explicitly killing, I think we're
covering the original bug with this testcase change.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* remote.c (remote_target::remote_add_inferior): Don't bind a
process to the current inferior if the current inferior is already
bound to a process.
gdb/testsuite/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* gdb.server/extended-remote-restart.exp (test_reload): Explicitly
disconnect before reconnecting.
The multi-target patch makes inferior_ptid point to null_ptid before
calling into target_wait, which catches bad uses of inferior_ptid,
since the current selected thread in gdb shouldn't have much relation
to the thread that reports an event.
One such bad use is found in remote_target::remote_parse_stop_reply,
where we handle the 'W' or 'X' packets (process exit), and the remote
target does not support the multi-process extensions, i.e., it does
not report the PID of the process that exited.
With the multi-target patch, that would result in a failed assertion,
trying to find the inferior for process pid 0.
gdb/ChangeLog:
2020-01-10 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Pedro Alves <palves@redhat.com>
* remote.c (remote_target::remote_parse_stop_reply) <W/X packets>:
If no process is specified, return null_ptid instead of
inferior_ptid.
(remote_target::wait_as): Handle TARGET_WAITKIND_EXITED /
TARGET_WAITKIND_SIGNALLED with no pid.
gdb/testsuite/ChangeLog:
2020-01-10 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Pedro Alves <palves@redhat.com>
* gdb.server/connect-without-multi-process.exp: Also test
continuing to end.
With current master, on a Fedora 27 machine with a kernel with buggy
watchpoint support, I see:
(gdb) PASS: gdb.threads/watchpoint-fork.exp: parent: singlethreaded: hardware breakpoints work
continue
Continuing.
warning: Remote failure reply: E01
Remote communication error. Target disconnected.: Connection reset by peer.
(gdb) FAIL: gdb.threads/watchpoint-fork.exp: parent: singlethreaded: watchpoints work
continue
The program is not being run.
(gdb) FAIL: gdb.threads/watchpoint-fork.exp: parent: singlethreaded: breakpoint after the first fork (the program is no longer running)
The FAILs themselves aren't what's interesting here. What is
interesting is that with the main multi-target patch applied, I was getting this:
(gdb) PASS: gdb.threads/watchpoint-fork.exp: parent: singlethreaded: hardware breakpoints work
continue
Continuing.
warning: Remote failure reply: E01
/home/pedro/brno/pedro/gdb/binutils-gdb-2/build/../src/gdb/inferior.c:285: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/watchpoint-fork.exp: parent: singlethreaded: watchpoints work (GDB internal error)
The problem is that in remote_target::wait_as, we're hitting this:
switch (buf[0])
{
case 'E': /* Error of some sort. */
/* We're out of sync with the target now. Did it continue or
not? Not is more likely, so report a stop. */
rs->waiting_for_stop_reply = 0;
warning (_("Remote failure reply: %s"), buf);
status->kind = TARGET_WAITKIND_STOPPED;
status->value.sig = GDB_SIGNAL_0;
break;
which leaves event_ptid as null_ptid. At the end of the function, we then reach:
else if (status->kind != TARGET_WAITKIND_EXITED
&& status->kind != TARGET_WAITKIND_SIGNALLED)
{
if (event_ptid != null_ptid)
record_currthread (rs, event_ptid);
else
event_ptid = inferior_ptid; <<<<< here
}
and the trouble is that with the multi-target patch, we'll get here
with inferior_ptid as null_ptid too. That is done exactly to find
these implicit assumptions that inferior_ptid is a good choice for
default thread, which isn't generaly true.
I first thought of fixing this in the "case 'E'" path, but, given that
this "event_ptid = inferior_ptid" path is also taken when the remote
target does not support threads at all, no thread-related packets or
extensions, it's better to fix it in latter path, to handle all
scenarios that miss reporting a thread.
That's what this patch does.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* remote.c (first_remote_resumed_thread): New.
(remote_target::wait_as): Use it as default event_ptid instead of
inferior_ptid.
It's not possible to open a tfile target with an invalid trace_fd, and
it's not possible to close a closed target, so this early return is dead.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* tracefile-tfile.c (tfile_target::close): Assert that trace_fd is
not -1.
- Make get_last_target_status arguments optional. A following patch
will add another argument to get_last_target_status (the event's
target), and passing nullptr when we don't care for some piece of
info is handier than creating dummy local variables.
- Declare nullify_last_target_wait_ptid in a header, and remove the
local extern declaration from linux-fork.c.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* break-catch-sig.c (signal_catchpoint_print_it): Don't pass a
ptid to get_last_target_status.
* break-catch-syscall.c (print_it_catch_syscall): Don't pass a
ptid to get_last_target_status.
* infcmd.c (continue_command): Don't pass a target_waitstatus to
get_last_target_status.
(info_program_command): Don't pass a target_waitstatus to
get_last_target_status.
* infrun.c (init_wait_for_inferior): Use
nullify_last_target_wait_ptid.
(get_last_target_status): Handle nullptr arguments.
(nullify_last_target_wait_ptid): Clear target_last_waitstatus.
(print_stop_event): Don't pass a ptid to get_last_target_status.
(normal_stop): Don't pass a ptid to get_last_target_status.
* infrun.h (get_last_target_status, set_last_target_status): Move
comments here and update.
(nullify_last_target_wait_ptid): Declare.
* linux-fork.c (fork_load_infrun_state): Remove local extern
declaration of nullify_last_target_wait_ptid.
* linux-nat.c (get_detach_signal): Don't pass a target_waitstatus
to get_last_target_status.
Once each inferior has its own target stack, we'll need to make sure
that the right inferior is selected before we call into target
methods.
It kind of sounds worse than it is in practice. Not that many places
need to be concerned.
In thread.c, we add a new switch_to_thread_if_alive function that
centralizes the switching before calls to target_thread_alive. Other
cases are handled with explicit switching.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* gdbthread.h (scoped_restore_current_thread)
<dont_restore, restore, m_dont_restore>: Declare.
* thread.c (thread_alive): Add assertion. Return bool.
(switch_to_thread_if_alive): New.
(prune_threads): Switch inferior/thread.
(print_thread_info_1): Switch thread before calling target methods.
(scoped_restore_current_thread::restore): New, factored out from
...
(scoped_restore_current_thread::~scoped_restore_current_thread):
... this.
(scoped_restore_current_thread::scoped_restore_current_thread):
Add assertion.
(thread_apply_all_command, thread_select): Use
switch_to_thread_if_alive.
* infrun.c (proceed, restart_threads, handle_signal_stop)
(switch_back_to_stepped_thread): Switch current thread before
calling target methods.
Several places want to switch context to an inferior and its pspace,
while at the same time switch to "no thread selected". This commit
adds a function that does that, and uses it in a few places.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* inferior.c (switch_to_inferior_no_thread): New function,
factored out from ...
(inferior_command): ... here.
* inferior.h (switch_to_inferior_no_thread): Declare.
* mi/mi-main.c (run_one_inferior): Use
switch_to_inferior_no_thread.
I believe this comment:
/* Killing off the inferior can leave us with a core file. If
so, print the state we are left in. */
Referred to the fact that a decade ago, by design, GDB would let you
type "run" when debugging a core dump, keeping the core open. That
"run" would push a process_stratum target on the target stack for the
live process, and, the core would remain open -- we used to have a
core_stratum. When the live process was killed/detached or exited,
GDB would go back to debugging the core, since the core_stratum target
was now at the top of the stack. That design had a number of
problems, see here for example:
https://sourceware.org/ml/gdb-patches/2008-08/msg00290.html
In 2010, core_stratum was finaly eliminated and cores now have
process_stratum too, with commit c0edd9edad ("Make core files the
process_stratum."). Pushing a live process on the stack while you're
debugging a core discards the core completely.
I also thought that this might be in use with checkpoints, but it does
not -- "kill" when you have multiple checkpoints kills all the
checkpoints.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* infcmd.c (kill_command): Remove dead code.
I believe the tail end of remote_target::mourn_inferior is broken, and
it's been broken for too long to even bother trying to fix. Most
probably nobody needs it. If the code is reached and we find the
target is running, we'd need to resync the thread list, at least,
since generic_mourn_inferior got rid of all the threads in the
inferior, otherwise, we'd hit an assertion on the next call to
inferior_thread(), for example. A "correct" fix would probably
involve restarting the whole remote_target::start_remote requence,
exactly as if we had completely disconnected and reconnected from
scratch.
Note that regular stub debugging usually uses plain target remote, but
this code is only reachable in target extended-mode:
- The !remote_multi_process_p check means that it's only reacheable if
the stub does not support multi-process. I.e., there can only ever
be one live process.
- remote_target::mourn_inferior has this at the top:
/* In 'target remote' mode with one inferior, we close the connection. */
if (!rs->extended && number_of_live_inferiors () <= 1)
{
unpush_target (this);
/* remote_close takes care of doing most of the clean up. */
generic_mourn_inferior ();
return;
}
Which means that if we only had one live inferior (which for our
case, must be true), we'll have closed the connection already,
unless we're in extended-remote mode.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* remote.c (remote_target::mourn_inferior): No longer check
whether the target is running.
With the multi-target work, each inferior will have its own target
stack, so to call a target method, we'll need to make sure that the
inferior in question is the current one, otherwise target->beneath()
calls will find the target beneath in the wrong inferior.
In some places, it's much more convenient to be able to check whether
an inferior has execution without having to switch to it in order to
call target_has_execution on the right inferior/target stack, to avoid
side effects with switching inferior/thread/program space.
The current target_ops::has_execution method takes a ptid_t as
parameter, which, in a multi-target world, isn't sufficient to
identify the target. This patch prepares to address that, by changing
the parameter to an inferior pointer instead. From the inferior,
we'll be able to query its target stack to tell which target is
beneath.
Also adds a new inferior::has_execution() method to make callers a bit
more natural to read.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* corelow.c (core_target::has_execution): Change parameter type to
inferior pointer.
* inferior.c (number_of_live_inferiors): Use
inferior::has_execution instead of target_has_execution_1.
* inferior.h (inferior::has_execution): New.
* linux-thread-db.c (thread_db_target::update_thread_list): Use
inferior::has_execution instead of target_has_execution_1.
* process-stratum-target.c
(process_stratum_target::has_execution): Change parameter type to
inferior pointer. Check the inferior's PID instead of
inferior_ptid.
* process-stratum-target.h
(process_stratum_target::has_execution): Change parameter type to
inferior pointer.
* record-full.c (record_full_core_target::has_execution): Change
parameter type to inferior pointer.
* target.c (target_has_execution_1): Change parameter type to
inferior pointer.
(target_has_execution_current): Adjust.
* target.h (target_ops::has_execution): Change parameter type to
inferior pointer.
(target_has_execution_1): Change parameter type to inferior
pointer. Change return type to bool.
* tracefile.h (tracefile_target::has_execution): Change parameter
type to inferior pointer.
Commit 20f0d60db4 ("Avoid crash when calling warning too early"),
added a "current_top_target () != NULL" check to
target_supports_terminal_ours, so this check in exceptions.c is now
obsolete.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* exceptions.c (print_flush): Remove current_top_target() check.
The "set remote exec-file" setting is per-inferior, but the "show
remote exec-file" command always shows the last set exec-file,
irrespective of the current inferior. E.g.:
# Set inferior 1's exec-file:
(gdb) set remote exec-file prog1
# Add inferior 2, switch to it, and set its exec-file:
(gdb) add-inferior
Added inferior 2
(gdb) inferior 2
(gdb) set remote exec-file prog2
# Switch back to inferior 1, and show its exec-file:
(gdb) inferior 1
(gdb) show remote exec-file
prog2
^^^^^ should show "prog1" instead here.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* remote.c (show_remote_exec_file): Show the current inferior's
exec-file instead of the command variable's value.
gdb/testsuite/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* gdb.base/remote-exec-file.exp: New file.
The multi-target patch sets inferior_ptid to null_ptid before handling
a target event, and thus before calling target_wait, in order to catch
places in target_ops::wait implementations that are incorrectly
relying on inferior_ptid (which could otherwise be a ptid of a
different target, for example). That caught this instance in
record-full.c.
Fix it by saving the last resumed ptid, and then using it in
record_full_wait_1, just like how the last "step" argument passed to
record_full_target::resume is handled too.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* record-full.c (record_full_resume_ptid): New global.
(record_full_target::resume): Set it.
(record_full_wait_1): Use record_full_resume_ptid instead of
inferior_ptid.
In non-stop mode, if you resume the program in the background (with
"continue&", for example), then gdb makes sure to not switch the
current thread behind your back. That means that you can be sure that
the commands you type apply to the thread you selected, even if some
other thread that was running in the background hits some event just
while you're typing.
In all-stop mode, however, if you resume the program in the
background, gdb let's the current thread switch behind your back.
This is bogus, of course. All-stop and non-stop background
resumptions should behave the same.
This patch fixes that, and adds a testcase that exposes the bad
behavior in current master.
The fork-running-state.exp changes are necessary because that
preexisting testcase was expecting the old behavior:
Before:
continue &
Continuing.
(gdb)
[Attaching after process 8199 fork to child process 8203]
[New inferior 2 (process 8203)]
info threads
Id Target Id Frame
1.1 process 8199 "fork-running-st" (running)
* 2.1 process 8203 "fork-running-st" (running)
(gdb)
After:
continue &
Continuing.
(gdb)
[Attaching after process 24660 fork to child process 24664]
[New inferior 2 (process 24664)]
info threads
Id Target Id Frame
* 1.1 process 24660 "fork-running-st" (running)
2.1 process 24664 "fork-running-st" (running)
(gdb)
Here we see that before this patch GDB switches current inferior to
the new inferior behind the user's back, as a side effect of handling
the fork.
The delete_exited_threads call in inferior_appeared is there to fix an
issue that Baris found in a previous version of this patch. The
fetch_inferior_event change increases the refcount of the current
thread, and in case the fetched inferior event denotes a thread exit,
the thread will not be deleted right away. A non-deleted but exited
thread stays in the inferior's thread list. This, in turn, causes the
"init_thread_list" call in inferior.c to be skipped. A consequence is
that the global thread ID counter is not restarted if the current
thread exits, and then the inferior is restarted:
(gdb) start
Temporary breakpoint 1 at 0x4004d6: file main.c, line 21.
Starting program: /tmp/main
Temporary breakpoint 1, main () at main.c:21
21 foo ();
(gdb) info threads -gid
Id GId Target Id Frame
* 1 1 process 16106 "main" main () at main.c:21
(gdb) c
Continuing.
[Inferior 1 (process 16106) exited normally]
(gdb) start
Temporary breakpoint 2 at 0x4004d6: file main.c, line 21.
Starting program: /tmp/main
Temporary breakpoint 2, main () at main.c:21
21 foo ();
(gdb) info threads -gid
Id GId Target Id Frame
* 1 2 process 16138 "main" main () at main.c:21
^^^
Notice that GId == 2 above. It should have been "1" instead.
The new tids-git-reset.exp testcase exercises the problem above.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* gdbthread.h (scoped_restore_current_thread)
<dont_restore, restore, m_dont_restore>: Declare.
* thread.c (thread_alive): Add assertion. Return bool.
(switch_to_thread_if_alive): New.
(prune_threads): Switch inferior/thread.
(print_thread_info_1): Switch thread before calling target methods.
(scoped_restore_current_thread::restore): New, factored out from
...
(scoped_restore_current_thread::~scoped_restore_current_thread):
... this.
(scoped_restore_current_thread::scoped_restore_current_thread):
Add assertion.
(thread_apply_all_command, thread_select): Use
switch_to_thread_if_alive.
gdb/testsuite/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* gdb.base/fork-running-state.exp (do_test): Adjust expected
output.
* gdb.threads/async.c: New.
* gdb.threads/async.exp: New.
* gdb.multi/tids-gid-reset.c: New.
* gdb.multi/tids-gid-reset.exp: New.
According to the SystemTap documentation on user-space probes[0], stap
probe points without semaphores are denoted by setting the semaphore
address in the probe's note to zero. At present the code does do a
comparison of the semaphore address against zero, but only after it's
been relocated; as such it will (almost?) always fail, commonly
resulting in GDB trying to overwrite the ELF magic located at the
image's base address.
This commit tests the address as specified in the SDT note rather than
the relocated value in order to correctly detect absent probe
semaphores.
[0]: https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
gdb/Changelog:
2020-01-11 George Barrett <bob@bob131.so>
* stap-probe.c (stap_modify_semaphore): Don't check for null
semaphores.
(stap_probe::set_semaphore, stap_probe::clear_semaphore): Check
for null semaphores.
gdb/testsuite/ChangeLog:
2020-01-11 George Barrett <bob@bob131.so>
* gdb.base/stap-probe.c (relocation_marker): Add dummy variable
to help in finding the image relocation offset.
* gdb.base/stap-probe.exp (stap_test): Accept arbitrary compile
options in arguments.
(stap_test_no_debuginfo): Likewise.
(stap-probe-nosem-noopt-pie, stap-probe-nosem-noopt-nopie): Add
test variants.
(stap_test): Add null semaphore relocation test.
This patch resolves a couple of issues with the test case for SystemTap
user-space probe points:
1. The preprocessor macro guarding the semaphore variables in the C
file is (rather confusingly) named USE_PROBES. This has been
renamed to USE_SEMAPHORES, to better reflect its function.
2. The test procedures in the expect file improperly pass the flag
defining USE_PROBES to prepare_for_testing; as such, the test
binary that's supposed to have probes with semaphores is the same
as the one without. This has also been fixed.
3. No test is performed to check that `info probes' returns
information about probe semaphores. Such a test is included in this
patch.
gdb/testsuite/ChangeLog
2020-01-10 George Barrett <bob@bob131.so>
* gdb.base/stap-probe.c: Rename USE_PROBES to USE_SEMAPHORES.
* gdb.base/stap-probe.exp: Likewise.
(stap_test): Pass argument as an additional flag.
(stap_test_no_debuginfo): Likewise.
(stap_test): Check `info probes stap' output for semaphore
addresses if the test binary is supposed to have them.
With static PIE linking undefined weak symbols are resolved to 0, so no
dynamic relocation is needed for them. The UNDEFWEAK_NO_DYNAMIC_RELOC
macro was introduced so this case can be handled easily, but it was not
applied consistently in the first attempt to fix ld/22269 for arm:
commit 95b03e4ad6
arm: Check UNDEFWEAK_NO_DYNAMIC_RELOC
This patch fixes spurious relative relocs in static PIE binaries against
GOT entries created for undefined weak symbols on arm*-*, this fixes
FAIL: pr22269-1 (static pie undefined weak)
bfd/ChangeLog:
PR ld/22269
* elf32-arm.c (elf32_arm_final_link_relocate): Use
UNDEFWEAK_NO_DYNAMIC_RELOC.
(allocate_dynrelocs_for_symbol): Likewise.
This changes the fix to PR 25210 by removing the ELF class change.
As it turns out the correct change was only the change in compress.c.
Everything else is unneeded and setting the elf class is making the linker
behave very oddly under LTO. The first stub is correctly written out but for
the rest the suddenly don't have a pointer to the stub section anymore.
This caused SPEC to fail as the program would branch to the stub and it wouldn't
be filled in.
Committed to master under the trivial rule as this is partially reverting a previous commit.
bfd/ChangeLog:
PR 25210
* elfnn-aarch64.c (_bfd_aarch64_create_stub_section): Remove elfclass.
* m10300-dis.c (disassemble): Move extraction of DREG, AREG, RREG,
and XRREG value earlier to avoid a shift with negative exponent.
* m10200-dis.c (disassemble): Similarly.
Also fixes a real bug. The DECODE_INSN_I9a and DECODE_INSN_I9b both
use UNSIGNED_EXTRACT for 7 low bits of the result, but this was an
unsigned value due to "insn" being unsigned. DECODE_INSN_I9* is
therefore unsigned too, leading to a zero extension in an expression
using a bfd_vma if bfd_vma is 64 bits.
* opcode/spu.h: Formatting.
(UNSIGNED_EXTRACT): Use 1u.
(SIGNED_EXTRACT): Don't sign extend with shifts.
(DECODE_INSN_I9a, DECODE_INSN_I9b): Avoid left shift of signed value.
Keep result signed.
(DECODE_INSN_U9a, DECODE_INSN_U9b): Delete.
Until recently when the source window was scrolled the assembler
window would scroll in sync - keeping the disassembly for the current
line in view.
This was broken in commit:
commit b4b49dcbff
Date: Wed Nov 13 16:47:58 2019 -0700
Don't call tui_show_source from tui_ui_out
This commit restores the synchronised scrolling and also maintains the
horizontal scroll within the source view when it is vertically
scrolled, something that was broken before.
This commit does not mean that scrolling the assembler view scrolls
the source view. The connection this way never existed, though maybe
it should, but I'll leave adding this feature for a separate commit.
gdb/ChangeLog:
* tui/tui-source.c (tui_source_window::do_scroll_vertical): Update
all source windows, and maintain horizontal scroll status while
doing so.
gdb/testsuite/ChangeLog:
* gdb.tui/basic.exp: Add more scrolling tests.
Change-Id: I250114a3bc670040a6a759d41905776771b2f818
Hannes Domani pointed out that my previous patch to fix the "list"
command in the TUI instead broke vertical scrolling. While looking at
this, I found that do_scroll_vertical calls print_source_lines, which
seems like a very roundabout way to change the source window. This
patch removes this oddity and fixes the bug at the same time.
I've added a new test case. This is somewhat tricky, because the
obvious approach of sending a dummy command after the scroll did not
work -- due to how the TUI works, sennding a command causes the scroll
to take effect.
gdb/ChangeLog
2019-12-22 Tom Tromey <tom@tromey.com>
PR tui/18932:
* tui/tui-source.c (tui_source_window::do_scroll_vertical): Call
update_source_window, not print_source_lines.
gdb/testsuite/ChangeLog
2019-12-22 Tom Tromey <tom@tromey.com>
PR tui/18932:
* lib/tuiterm.exp (Term::wait_for): Rename from _accept. Return a
meangingful value.
(Term::command, Term::resize): Update.
* gdb.tui/basic.exp: Add scrolling test.
Change-Id: I9636a7c8a8cade37431c6165ee996a9d556ef1c8
Currently if a user starts the tui with 'layout asm' then they will be
presented with the 'src' layout.
What happens is:
1. Layout command enables TUI, selecting the SRC layout by default.
2. As part of tui_enable we call tui_display_main, which calls
tui_get_begin_asm_address, which calls
set_default_source_symtab_and_line. This changes core GDBs
current symtab and line, which triggers a call to the symtab
changed hook tui_symtab_changed, which sets the flag
from_source_symtab.
3. Back in the layout command, the layout is changed from SRC to
ASM. After this the layout command completes and we return to
core GDB which prints the prompt, however...
4. The before prompt hook is called which sees the
from_source_symtab flag is set and forces the SRC window to be
displayed. This switches us back to SRC view.
The solution I propose here is to delay installing the hooks into core
GDB until after we have finished setting up the tui and selecting the
default frame to view. In this way we effectively ignore the first
symtab changed event triggered when making main the default symtab.
gdb/ChangeLog:
* tui/tui.c (tui_enable): Register tui hooks after calling
tui_display_main.
gdb/testsuite/ChangeLog:
* gdb.tui/tui-layout-asm.exp: New file.
Change-Id: I858ab81a17ffb4aa72deb3f36c3755228a9c9d9a
A new test procedure for matching the contents of one screen box
against a regexp. This can be used to match the contents of one TUI
window against a regexp without any of the borders, or other windows
being included in the matched output (as is currently the case with
check_contents).
This will be used in a later commit.
gdb/testsuite/ChangeLog:
* lib/tuiterm.exp (Term::check_box_contents): New proc.
Change-Id: Icf795bf38dd9295e282a34eecc318a9cdbc73926
Split Term::enter_tui into two procedures, a core which does the
setup, but doesn't actually enable tui mode, and the old enter_tui
that calls the new core, and then enables tui mode.
This is going to be useful in a later commit.
gdb/testsuite/ChangeLog:
* lib/tuiterm.exp (Term::prepare_for_tui): New proc.
(Term::enter_tui): Use Term::prepare_for_tui.
Change-Id: I501dfb2ddaa4a4e7246a5ad319ab428e4f42b3af
The Term::dump_screen routine currently dumps the screen using calls
to 'verbose', this means it will only dump the screen when the
testsuite is running in verbose mode.
However, the Term::dump_screen is most often called when a test fails,
in this case I think it is useful to have the screen dumped even when
we're not in verbose mode.
This commit changes the calls to 'verbose' to be 'verbose -log' so we
always get the screen dump.
gdb/testsuite/ChangeLog:
* lib/tuiterm.exp (Term::dump_screen): Always dump the screen when
called.
Change-Id: I5f0a7f5ac2ece04d6fe6e9c5a28ea2a0dda38955
In this commit:
commit 5024637fac
Date: Sun Dec 15 11:05:47 2019 +0100
Fix skip.exp test failure observed with gcc-9.2.0
A race condition was introduced into the gdb.base/skip.exp test when
this line:
gdb_test "step" "foo \\(\\) at.*" "step 3"
Was changed to this:
gdb_test "step" "foo \\(\\) at.*" "step 3" "main \\(\\) at .*" "step"
Before the above change we expected GDB to behave like this:
(gdb) step
foo () at /path/to/gdb/testsuite/gdb.base/skip.c:42
42 return 0;
(gdb)
However, when the test is compiled with GCC 9.2.0 we get a different
behaviour, and so we need a second 'step', like this:
(gdb) step
main () at /path/to/gdb.base/skip.c:32
32 x = baz ((bar (), foo ()));
(gdb) step
foo () at /path/to/gdb/testsuite/gdb.base/skip.c:42
42 return 0;
(gdb)
Now the change to the test matches against 'main () at .*', however if
GDB or expect is being slow then we might only get to see output like
this:
(gdb) step
main () at /path/to/g
This will happily match the question pattern, so we send 'step' to GDB
again. Now GDB continues to produce output which expect accepts, we
now see this:
b.base/skip.c:32
32 x = baz ((bar (), foo ()));
(gdb)
This has carried on from where the previous block of output left off.
This doesn't match the final pattern 'foo \\(\\) at.*', but it does
match the prompt pattern that gdb_test_multiple adds, and so we report
the test as failing.
The solution is to simply ensure that the question consumes everything
up to, and including the prompt. This ensures that the prompt can't
then match the failure case. The new test line becomes:
gdb_test "step" "foo \\(\\) at.*" "step 3" \
"main \\(\\) at .*\r\n$gdb_prompt " "step"
gdb/testsuite/ChangeLog:
* gdb.base/skip.exp: Fix race condition in test.
Change-Id: I9f0b0b52ef1b4f980bfaa8fe405ff06d520f3482
Recent MinGW versions require -lssp when using _FORTIFY_SOURCE, which
gdb does (in common-defs.h)
https://github.com/msys2/MINGW-packages/issues/5868#issuecomment-544107564
To avoid all the complications with checking for -lssp and making sure it's
linked statically, just don't define it.
gdb/ChangeLog:
2020-01-09 Christian Biesinger <cbiesinger@google.com>
* gdbsupport/common-defs.h: Don't define _FORTIFY_SOURCE on MinGW.
Change-Id: Ide6870ab57198219a2ef78bc675768a789ca2b1d
The body of this this big "for" loop is missing an indentation level,
this patch fixes that.
gdb/ChangeLog:
* thread.c (print_thread_info_1): Fix indentation.
compute_and_set_names would only free the name if we did not find the name
in the hashtable, but it needs to always free it. Solve this by moving the
smart pointer outside the if.
Thanks to PhilippeW for finding this.
gdb/ChangeLog:
2020-01-09 Christian Biesinger <cbiesinger@google.com>
* symtab.c (general_symbol_info::compute_and_set_names): Move the
unique_xmalloc_ptr outside the if to always free the demangled name.
Change-Id: Id7c6b8408432183700ccb5ff634818d6c5a3ac95
PR 25220
* objcopy.c (empty_name): New variable.
(need_sym_before): Prevent an attempt to free a static variable.
(filter_symbols): Avoid strcmp test by checking for pointer
equality.
debuginfod is a lightweight web service that indexes ELF/DWARF
debugging resources by build-id and serves them over HTTP. This patch
enables objdump and readelf to query debuginfod servers when they are
otherwise not able to find separate debug files. Binutils can be built
with debuginfod using the --with-debuginfod configure option. This
requires that libdebuginfod be installed and found at configure time.
debuginfod is packaged with elfutils, starting with version 0.178. For
more information see https://sourceware.org/elfutils/.
toplevel* config/debuginfod.m4: New file. Add macro AC_DEBUGINFOD. Adds
new configure option --with-debuginfod.
* configure: Regenerate.
* configure.ac: Call AC_DEBUGINFOD.
binutils* Makefile.am (readelf_LDADD, objdump_LDADD): Add libdebuginfod.
* Makefile.in: Regenerate.
* NEWS: Update.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Call AC_DEBUGINFOD.
* doc/Makefile.in: Regenerate.
* doc/binutils.texi: Add section on using binutils
with debuginfod.
* dwarf.c (debuginfod_fetch_separate_debug_info): New function.
Query debuginfod servers for the target debug file.
(load_separate_debug_info): Call
debuginfod_fetch_separate_debug_info if configured with
debuginfod.
(load_separate_debug_files): Add file argument to
load_separate_debug_info calls.
* dwarf.h (get_build_id): Add declaration.
* objdump.c (get_build_id): New function. Get build-id of file.
* readelf.c (get_build_id): Likewise.
* testsuite/binutils-all/debuginfod.exp: New tests.
* testsuite/binutils-all/linkdebug.s: Add .note.gnu.build-id
section.
Checking just the base opcode without also checking this isn't a VEX
encoding, and without there being other insn properties avoiding a match
once respective VEX/XOP/EXEX-encoded insns would appear, is at least
dangerous. Add respective checks. At the same time there's no real need
to check the extension opcode to be None for the 0xA8 form - there's
nothing it can be confused with, and non-VEX-and-alike forms also can't
appear.
Commit ac0ab1842d ("i386: Also check R12-R15 registers when optimizing
testq to testb") didn't go quite far enough: In order to avoid confusing
other code registers would better be converted to byte ones uniformly.
The disassembler change is such that in default mode we'd disassemble
the insns (for there not ebing any conflicts), but when AMD64 mode was
explicitly requested, we'd show them as "(bad)".
This replaces two instances of manual string management in
dwarf2read.c with std::string.
gdb/ChangeLog
2020-01-08 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (parse_macro_definition): Use std::string.
(parse_macro_definition): Likewise.
Change-Id: Iec437100105484aa4a116fb5d651d7ed52ee9d81
Pedro Alves
Tankut Baris Aktemur
George Barrett
Szabolcs Nagy
Tamar Christina
Alan Modra
GDB Administrator
Andrew Burgess
Tom Tromey
Christian Biesinger
Simon Marchi
Nick Clifton
Aaron Merey
Sergey Belyashov
Jan Beulich
Tom Tromey