Toolchain/binutils-gdb
1
0
Fork 0
forked from Imagelibrary/binutils-gdb
Code Pull Requests Activity
115,013 Commits 422 Branches 140 Tags
71a75b51a62b5cbc12c68b9c4d1dcae0f8a59263
Commit Graph

143 Commits

Author SHA1 Message Date
Tom de Vries
3bfdcabbc2 [gdb] Fix more typos 
Fix some more typos:
- distinquish -> distinguish
- actualy -> actually
- singe -> single
- frash -> frame
- chid -> child
- dissassembler -> disassembler
- uninitalized -> uninitialized
- precontidion -> precondition
- regsiters -> registers
- marge -> merge
- sate -> state
- garanteed -> guaranteed
- explictly -> explicitly
- prefices (nonstandard plural) -> prefixes
- bondary -> boundary
- formated -> formatted
- ithe -> the
- arrav -> array
- coresponding -> corresponding
- owend -> owned
- fials -> fails
- diasm -> disasm
- ture -> true
- tpye -> type

There's one code change, the name of macro SIG_CODE_BONDARY_FAULT changed to
SIG_CODE_BOUNDARY_FAULT.

Tested on x86_64-linux.
 2023-06-05 12:53:15 +02:00
Simon Marchi
287de65625 gdb, gdbserver, gdbsupport: fix whitespace issues 
Replace spaces with tabs in a bunch of places.

Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0
 2023-03-09 16:32:00 -05:00
Tom Tromey
8b2d5ef8d4 Fix btrace regression 
Tom de Vries pointed out that my earlier patch:

    commit 873a185be2
    Date:   Fri Dec 16 07:56:57 2022 -0700

	Don't use struct buffer in handle_qxfer_btrace

regressed gdb.btrace/reconnect.exp.  I didn't notice this because I
did not have libipt installed.

This patch fixes the bug.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30169
Tested-By: Bruno Larsen <blarsen@redhat.com>
 2023-03-01 06:38:19 -07:00
Khem Raj
2e977d9901 gdbserver/linux-low.cc: Fix a typo in ternary operator 
Signed-off-by: Khem Raj <raj.khem@gmail.com>
 2023-02-24 12:09:05 -07:00
Tom Tromey
873a185be2 Don't use struct buffer in handle_qxfer_btrace 
This changes handle_qxfer_btrace and handle_qxfer_btrace_conf, in
gdbserver, to use std::string rather than struct buffer.
 2023-02-24 11:52:48 -07:00
Thiago Jung Bauermann
43e5fbd8b7 gdbserver: Add PID parameter to linux_get_auxv and linux_get_hwcap 
This patch doesn't change gdbserver behaviour, but after later changes are
made it avoids a null pointer dereference when HWCAP needs to be obtained
for a specific process while current_thread is nullptr.

Fixing linux_read_auxv, linux_get_hwcap and linux_get_hwcap2 to take a PID
parameter seems more correct than setting current_thread in one particular
code path.

Changes are propagated to allow passing the new parameter through the call
chain.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
 2023-02-01 20:42:50 +00:00
Joel Brobecker
213516ef31 Update copyright year range in header of all files managed by GDB 
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
 2023-01-01 17:01:16 +04:00
Simon Marchi
de75275fe5 gdbsupport: change xml_escape_text_append's parameter from pointer to reference 
The passed in string can't be nullptr, it makes more sense to pass in a
reference.

Change-Id: Idc8bd38abe1d6d9b44aa227d7856956848c233b3
 2022-12-15 21:56:25 -05:00
Tom de Vries
4c35c4c6a7 [gdb/server] Emit warning for SIGINT failure 
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>
 2022-11-27 10:31:50 +01:00
Simon Marchi
d4895ba2df gdbserver/linux: take condition out of callback in find_lwp_pid 
Just a small optimization, it's not necessary to recompute lwp at each
iteration.

While at it, change the variable type to long, as ptid_t::lwp returns a
long.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I181670ce1f90b59cb09ea4899367750be2ad9105
 2022-11-18 11:09:11 -05:00
Tankut Baris Aktemur
8263b346fa gdbserver: do not report btrace support if target does not announce it 
Gdbserver unconditionally reports support for btrace packets.  Do not
report the support, if the underlying target does not say it supports
it.  Otherwise GDB would query the server with btrace-related packets
unnecessarily.
 2022-11-09 17:46:21 +01:00
Pedro Alves
f34652de0b internal_error: remove need to pass __FILE__/__LINE__ 
Currently, every internal_error call must be passed __FILE__/__LINE__
explicitly, like:

  internal_error (__FILE__, __LINE__, "foo %d", var);

The need to pass in explicit __FILE__/__LINE__ is there probably
because the function predates widespread and portable variadic macros
availability.  We can use variadic macros nowadays, and in fact, we
already use them in several places, including the related
gdb_assert_not_reached.

So this patch renames the internal_error function to something else,
and then reimplements internal_error as a variadic macro that expands
__FILE__/__LINE__ itself.

The result is that we now should call internal_error like so:

  internal_error ("foo %d", var);

Likewise for internal_warning.

The patch adjusts all calls sites.  99% of the adjustments were done
with a perl/sed script.

The non-mechanical changes are in gdbsupport/errors.h,
gdbsupport/gdb_assert.h, and gdb/gdbarch.py.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
 2022-10-19 15:32:36 +01:00
Markus Metzger
2733d9d5d6 gdb, gdbserver: extend RSP to support namespaces 
Introduce a new qXfer:libraries-svr4:read annex key/value pair

    lmid=<namespace identifier>

to be used together with start and prev to provide the namespace of start
and prev to gdbserver.

Unknown key/value pairs are ignored by gdbserver so no new supports check
is needed.

Introduce a new library-list-svr4 library attribute

    lmid

to provide the namespace of a library entry to GDB.

This implementation uses the address of a namespace's r_debug object as
namespace identifier.

This should have incremented the minor version but since unknown XML
attributes are ignored, anyway, and since changing the version results in
a warning from GDB, the version is left at 1.0.
 2022-10-18 14:16:09 +02:00
Markus Metzger
ad10f44e56 gdbserver: move main_lm handling into caller 
When listing SVR4 shared libraries, special care has to be taken about the
first library in the default namespace as that refers to the main
executable.  The load map address of this main executable is provided in
an attribute of the library-list-svr4 element.

Move that code from where we enumerate libraries inside a single namespace
to where we generate the rest of the library-list-svr4 element.  This
allows us to complete the library-list-svr4 element inside one function.

There should be no functional change.
 2022-10-18 14:16:08 +02:00
Markus Metzger
8d56636a0e gdb, gdbserver: support dlmopen() 
In glibc, the r_debug structure contains (amongst others) the following
fields:

  int r_version:
    Version number for this protocol.  It should be greater than 0.

If r_version is 2, struct r_debug is extended to struct r_debug_extended
with one additional field:

  struct r_debug_extended *r_next;
    Link to the next r_debug_extended structure.  Each r_debug_extended
    structure represents a different namespace.  The first r_debug_extended
    structure is for the default namespace.

1. Change solib_svr4_r_map argument to take the debug base.
2. Add solib_svr4_r_next to find the link map in the next namespace from
the r_next field.
3. Update svr4_current_sos_direct to get the link map in the next namespace
from the r_next field.
4. Don't check shared libraries in other namespaces when updating shared
libraries in a new namespace.
5. Update svr4_same to check the load offset in addition to the name
6. Update svr4_default_sos to also set l_addr_inferior
7. Change the flat solib_list into a per-namespace list using the
namespace's r_debug address to identify the namespace.

Add gdb.base/dlmopen.exp to test this.

To remain backwards compatible with older gdbserver, we reserve the
namespace zero for a flat list of solibs from all namespaces.  Subsequent
patches will extend RSP to allow listing libraries grouped by namespace.

This fixes PR 11839.

Co-authored-by: Lu, Hongjiu  <hongjiu.lu@intel.com>
 2022-10-18 14:16:08 +02:00
Pedro Alves
a9deee17d3 gdb+gdbserver/Linux: avoid reading registers while going through shell 
For every stop, Linux GDB and GDBserver save the stopped thread's PC,
in lwp->stop_pc.  This is done in save_stop_reason, in both
gdb/linux-nat.c and gdbserver/linux-low.cc.  However, while we're
going through the shell after "run", in startup_inferior, we shouldn't
be reading registers, as we haven't yet determined the target's
architecture -- the shell's architecture may not even be the same as
the final inferior's.

In gdb/linux-nat.c, lwp->stop_pc is only needed when the thread has
stopped for a breakpoint, and since when going through the shell, no
breakpoint is going to hit, we could simply teach save_stop_reason to
only record the stop pc when the thread stopped for a breakpoint.

However, in gdbserver/linux-low.cc, lwp->stop_pc is used in more cases
than breakpoint hits (e.g., it's used in tracepoints & the
"while-stepping" feature).

So to avoid GDB vs GDBserver divergence, we apply the same approach to
both implementations.

We set a flag in the inferior (process in GDBserver) whenever it is
being nursed through the shell, and when that flag is set,
save_stop_reason bails out early.  While going through the shell,
we'll only ever get process exits (normal or signalled), random
signals, and exec events, so nothing is lost.

Change-Id: If0f01831514d3a74d17efd102875de7d2c6401ad
 2022-06-28 18:11:29 +01:00
Simon Marchi
f551c8ef32 gdbserver/linux: free process_info_private and arch_process_info when failing to attach 
Running

  $ ../gdbserver/gdbserver --once --attach :1234 539436

with ASan while /proc/sys/kernel/yama/ptrace_scope is set to 1 (prevents
attaching) shows that we fail to free some platform-specific objects
tied to the process_info (process_info_private and arch_process_info):

    Direct leak of 32 byte(s) in 1 object(s) allocated from:
        #0 0x7f6b558b3fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
        #1 0x562eaf15d04a in xcalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:100
        #2 0x562eaf251548 in xcnew<process_info_private> /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/poison.h:122
        #3 0x562eaf22810c in linux_process_target::add_linux_process_no_mem_file(int, int) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:426
        #4 0x562eaf22d33f in linux_process_target::attach(unsigned long) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:1132
        #5 0x562eaf1a7222 in attach_inferior /home/simark/src/binutils-gdb/gdbserver/server.cc:308
        #6 0x562eaf1c1016 in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3949
        #7 0x562eaf1c1d60 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:4084
        #8 0x7f6b552f630f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

    Indirect leak of 56 byte(s) in 1 object(s) allocated from:
        #0 0x7f6b558b3fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
        #1 0x562eaf15d04a in xcalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:100
        #2 0x562eaf2a0d79 in xcnew<arch_process_info> /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/poison.h:122
        #3 0x562eaf295e2c in x86_target::low_new_process() /home/simark/src/binutils-gdb/gdbserver/linux-x86-low.cc:723
        #4 0x562eaf22819b in linux_process_target::add_linux_process_no_mem_file(int, int) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:428
        #5 0x562eaf22d33f in linux_process_target::attach(unsigned long) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:1132
        #6 0x562eaf1a7222 in attach_inferior /home/simark/src/binutils-gdb/gdbserver/server.cc:308
        #7 0x562eaf1c1016 in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3949
        #8 0x562eaf1c1d60 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:4084
        #9 0x7f6b552f630f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

Those objects are deleted by linux_process_target::mourn, but that is
not called if we fail to attach, we only call remove_process.  I
initially fixed this by making linux_process_target::attach call
linux_process_target::mourn on failure (before calling error).  But this
isn't done anywhere else (including in GDB) so it would just be
confusing to do things differently here.

Instead, add a linux_process_target::remove_linux_process helper method
(which calls remove_process), and call that instead of remove_process in
the Linux target.  Move the free-ing of the extra data from the mourn
method to that new method.

Change-Id: I277059a69d5f08087a7f3ef0b8f1792a1fcf7a85
 2022-04-22 14:04:36 -04:00
Pedro Alves
421490af33 gdbserver/linux: Access memory even if threads are running 
Similarly to how the native Linux target was changed
and subsequently reworked in these commits:

 05c06f318f Linux: Access memory even if threads are running
 8a89ddbda2 Avoid /proc/pid/mem races (PR 28065)

... teach GDBserver to access memory even when the current thread is
running, by always accessing memory via /proc/PID/mem.

The existing comment:

  /* Neither ptrace nor /proc/PID/mem allow accessing memory through a
     running LWP.  */

... is incorrect for /proc/PID/mem does allow that.

Actually, from GDB's perspective, GDBserver could already access
memory while threads were running, but at the expense of pausing all
threads for the duration of the memory access, via
prepare_to_access_memory.  This new implementation does not require
pausing any thread, thus
linux_process_target::prepare_to_access_memory /
linux_process_target::done_accessing_memory become nops.  A subsequent
patch will remove the whole prepare_to_access_memory infrastructure
completely.

The GDBserver linux-low.cc implementation is simpler than GDB's
linux-nat.c's, because GDBserver always adds the unfollowed vfork/fork
children to the process list immediately when the fork/vfork event is
seen out of ptrace.  I.e., there's no need to keep the file descriptor
stored on a side map, we can store it directly in the process
structure.

Change-Id: I0abfd782ceaa4ddce8d3e5f3e2dfc5928862ef61
 2022-04-14 20:22:56 +01:00
Simon Marchi
e88cf517e9 gdbserver: report correct status in thread stop race condition 
The test introduced by the following patch would sometimes fail in this
configuration:

    FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=14: next to for loop

The test has multiple threads constantly forking or vforking while the
main thread keep doing "next"s.

(After writing the commit message, I realized this also fixes a similar
failure in gdb.threads/forking-threads-plus-breakpoint.exp with the
native-gdbserver and native-extended-gdbserver boards.)

As stop_all_threads is called, because the main thread finished its
"next", it inevitably happens at some point that we ask the remote
target to stop a thread and wait() reports that this thread stopped with
a fork or vfork event, instead of the SIGSTOP we sent to try to stop it.

While running this test, I attached to GDBserver and stopped at
linux-low.cc:3626.  We can see that the status pulled from the kernel
for 2742805 is indeed a vfork event:

    (gdb) p/x w
    $3 = 0x2057f
    (gdb) p WIFSTOPPED(w)
    $4 = true
    (gdb) p WSTOPSIG(w)
    $5 = 5
    (gdb) p/x (w >> 8) & (PTRACE_EVENT_VFORK << 8)
    $6 = 0x200

However, the statement at line 3626 overrides that:

    ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));

OURSTATUS becomes "stopped by a SIGTRAP".  The information about the
fork or vfork is lost.

It's then all downhill from there, stop_all_threads eventually asks for
a thread list update.  That thread list includes the child of that
forgotten fork or vfork, the remote target goes "oh cool, a new process,
let's attach to it!", when in fact that vfork child's destiny was to be
detached.

My reverse-engineered understanding of the code around there is that the
if/else between lines 3562 and 3583 (in the original code) makes sure
OURSTATUS is always initialized (not "ignore").  Either the details are
already in event_child->waitstatus (in the case of fork/vfork, for
example), in which case we just copy event_child->waitstatus to
ourstatus.  Or, if the event is a plain "stopped by a signal" or a
syscall event, OURSTATUS is set to "stopped", but without a signal
number.  Lines 3601 to 3629 (in the original code) serve to fill in that
last bit of information.

The problem is that when `w` holds the vfork status, the code wrongfully
takes this branch, because WSTOPSIG(w) returns SIGTRAP:

  else if (current_thread->last_resume_kind == resume_stop
       && WSTOPSIG (w) != SIGSTOP)

The intent of this branch is, for example, when we sent SIGSTOP to try
to stop a thread, but wait() reports that it stopped with another signal
(that it must have received from somewhere else simultaneously), say
SIGWINCH.  In that case, we want to report the SIGWINCH.  But in our
fork/vfork case, we don't want to take this branch, as the thread didn't
really stop because it received a signal.  For the non "stopped by a
signal" and non "syscall signal" cases, we would ideally skip over all
that snippet that fills in the signal or syscall number.

The fix I propose is to move this snipppet of the else branch of the
if/else above.  In addition to moving the code, the last two "else if"
branches:

  else if (current_thread->last_resume_kind == resume_stop
	   && WSTOPSIG (w) != SIGSTOP)
    {
      /* A thread that has been requested to stop by GDB with vCont;t,
	 but, it stopped for other reasons.  */
      ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));
    }
  else if (ourstatus->kind () == TARGET_WAITKIND_STOPPED)
    ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));

are changed into a single else:

  else
    ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));

This is the default path we take if:

 - W is not a syscall status
 - W does not represent a SIGSTOP that have sent to stop the thread and
   therefore want to suppress it

Change-Id: If2dc1f0537a549c293f7fa3c53efd00e3e194e79
 2022-04-04 22:11:53 -04:00
Simon Marchi
20471e00e2 gdbserver/linux: set lwp !stopped when failing to resume 
I see some failures, at least in gdb.multi/multi-re-run.exp and
gdb.threads/interrupted-hand-call.exp.  Running `stress -C $(nproc)` at
the same time as the test makes those tests relatively frequent.

Let's take gdb.multi/multi-re-run.exp as an example.  The failure looks
like this, an unexpected "no resumed":

    continue
    Continuing.
    No unwaited-for children left.
    (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=2: iter=1: continue until exit

The situation is:

 - Inferior 1 is stopped somewhere, it won't really play a role here.
 - Inferior 2 has 2 threads, both stopped.
 - We resume inferior 2, the leader thread is expected to exit, making
   the process exit.

From GDB's perspective, a failing run looks like this:

    [infrun] fetch_inferior_event: enter
      [infrun] scoped_disable_commit_resumed: reason=handling event
      [infrun] do_target_wait: Found 2 inferiors, starting at #1
      [infrun] random_pending_event_thread: None found.
      [remote] wait: enter
        [remote] Packet received: T0506:20dcffffff7f0000;07:20dcffffff7f0000;10:9551555555550000;thread:pae4cd.ae4cd;core:e;
      [remote] wait: exit
      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
      [infrun] print_target_wait_results:   713933.713933.0 [Thread 713933.713933],
      [infrun] print_target_wait_results:   status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
      [infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
      [infrun] clear_step_over_info: clearing step over info
      [infrun] context_switch: Switching context from 0.0.0 to 713933.713933.0
      [infrun] handle_signal_stop: stop_pc=0x555555555195
      [infrun] start_step_over: enter
        [infrun] start_step_over: stealing global queue of threads to step, length = 0
        [infrun] operator(): step-over queue now empty
      [infrun] start_step_over: exit
      [infrun] process_event_stop_test: no stepping, continue
      [remote] Sending packet: $Z0,555555555194,1#8e
      [remote] Packet received: OK
      [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [713933.713933.0] at 0x555555555195
      [remote] Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a
      [remote] Packet received: OK
      [remote] Sending packet: $vCont;c:pae4cd.-1#9f
      [infrun] prepare_to_wait: prepare_to_wait
      [infrun] reset: reason=handling event
      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
    [infrun] fetch_inferior_event: exit
    [infrun] fetch_inferior_event: enter
      [infrun] scoped_disable_commit_resumed: reason=handling event
      [infrun] do_target_wait: Found 2 inferiors, starting at #0
      [infrun] random_pending_event_thread: None found.
      [remote] wait: enter
        [remote] Packet received: N
      [remote] wait: exit
      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
      [infrun] print_target_wait_results:   -1.0.0 [process -1],
      [infrun] print_target_wait_results:   status->kind = NO_RESUMED
      [infrun] handle_inferior_event: status->kind = NO_RESUMED
      [remote] Sending packet: $Hgp0.0#ad
      [remote] Packet received: OK
      [remote] Sending packet: $qXfer:threads:read::0,1000#92
      [remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="40b6c6f7ff7f0000"/>\n</threads>\n
      [infrun] stop_waiting: stop_waiting
      [remote] Sending packet: $qXfer:threads:read::0,1000#92
      [remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="40b6c6f7ff7f0000"/>\n</threads>\n
      [infrun] infrun_async: enable=0
      [infrun] reset: reason=handling event
      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
    [infrun] fetch_inferior_event: exit

We can see that we resume the inferior with vCont;c, but got NO_RESUMED.
When the test passes, we get an EXITED status to indicate the process
has exited.

From GDBserver's point of view, it looks like this.  The logs contain
some logging I added and that are part of this patch.

    [remote] getpkt: getpkt ("vCont;c:pae4cf.-1");  [no ack sent]
    [threads] resume: enter
      [threads] thread_needs_step_over: Need step over [LWP 713931]? Ignoring, should remain stopped
      [threads] thread_needs_step_over: Need step over [LWP 713932]? Ignoring, should remain stopped
      [threads] get_pc: pc is 0x555555555195
      [threads] thread_needs_step_over: Need step over [LWP 713935]? No, no breakpoint found at 0x555555555195
      [threads] get_pc: pc is 0x7ffff7d35a95
      [threads] thread_needs_step_over: Need step over [LWP 713936]? No, no breakpoint found at 0x7ffff7d35a95
      [threads] resume: Resuming, no pending status or step over needed
      [threads] resume_one_thread: resuming LWP 713935
      [threads] proceed_one_lwp: lwp 713935
      [threads] resume_one_lwp_throw:   continue from pc 0x555555555195
      [threads] resume_one_lwp_throw: Resuming lwp 713935 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: NOW ptid=713935.713935.0 stopped=0 resumed=0
      [threads] resume_one_thread: resuming LWP 713936
      [threads] proceed_one_lwp: lwp 713936
      [threads] resume_one_lwp_throw:   continue from pc 0x7ffff7d35a95
      [threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
    [threads] resume: exit
    [threads] wait_1: enter
      [threads] wait_1: [<all threads>]
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
      [threads] resume_stopped_resumed_lwps: resuming stopped-resumed LWP LWP 713935.713936 at 7ffff7d35a95: step=0
      [threads] resume_one_lwp_throw:   continue from pc 0x7ffff7d35a95
      [threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
      [threads] operator(): check_zombie_leaders: leader_pid=713931, leader_lp!=NULL=1, num_lwps=2, zombie=0
      [threads] operator(): check_zombie_leaders: leader_pid=713935, leader_lp!=NULL=1, num_lwps=2, zombie=1
      [threads] operator(): Thread group leader 713935 zombie (it exited, or another thread execd).
      [threads] delete_lwp: deleting 713935
      [threads] wait_for_event_filtered: exit (no unwaited-for LWP)
    sigchld_handler
      [threads] wait_1: ret = null_ptid, TARGET_WAITKIND_NO_RESUMED
    [threads] wait_1: exit

What happens is:

 - We resume the leader (713935) successfully.
 - The leader exits.
 - We resume the secondary thread (713936), we get ESRCH.  This is
   expected this the leader has exited.
 - resume_one_lwp_throw throws, it's caught by resume_one_lwp.
 - resume_one_lwp checks with check_ptrace_stopped_lwp_gone that the
   failure can be explained by the LWP becoming zombie, and swallows the
   error.
 - Note that this means that the secondary lwp still has stopped==1.
 - wait_1 is called, probably because linux_process_target::resume marks
   the async pipe at the end.
 - The exit event isn't ready yet, probably because the machine is under
   load, so waitpid returns nothing.
 - check_zombie_leaders detects that the leader is zombie and deletes
 - We try to find a resumed (non-stopped) LWP to get an event from,
   there's none since the leader (that was resumed) is now deleted, and
   the secondary thread is still marked stopped.
   wait_for_event_filtered returns -1, causing wait_1 to return
   NO_RESUMED.

What I notice here is that there is some kind of race between the
availability of the process' exit notification and the call to wait_1
that results from marking the async pipe at the end of resume.

I think what we want from this wait_1 invocation is to keep waiting, as
we will eventually get thread exit notifications for both of our
threads.

The fix I came up with is to mark the secondary thread as !stopped (or
resumed) when we fail to resume it.  This makes wait_1 see that there is
at least one resume lwp, so it won't return NO_RESUMED.  I think this
makes sense to consider it resumed, because we are going to receive an
exit event for it.  Here's the GDBserver logs with the fix applied:

    [threads] resume: enter
      [threads] thread_needs_step_over: Need step over [LWP 724595]? Ignoring, should remain stopped
      [threads] thread_needs_step_over: Need step over [LWP 724596]? Ignoring, should remain stopped
      [threads] get_pc: pc is 0x555555555195
      [threads] thread_needs_step_over: Need step over [LWP 724597]? No, no breakpoint found at 0x555555555195
      [threads] get_pc: pc is 0x7ffff7d35a95
      [threads] thread_needs_step_over: Need step over [LWP 724598]? No, no breakpoint found at 0x7ffff7d35a95
      [threads] resume: Resuming, no pending status or step over needed
      [threads] resume_one_thread: resuming LWP 724597
      [threads] proceed_one_lwp: lwp 724597
      [threads] resume_one_lwp_throw:   continue from pc 0x555555555195
      [threads] resume_one_lwp_throw: Resuming lwp 724597 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: NOW ptid=724597.724597.0 stopped=0 resumed=0
      [threads] resume_one_thread: resuming LWP 724598
      [threads] proceed_one_lwp: lwp 724598
      [threads] resume_one_lwp_throw:   continue from pc 0x7ffff7d35a95
      [threads] resume_one_lwp_throw: Resuming lwp 724598 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
    [threads] resume: exit
    [threads] wait_1: enter
      [threads] wait_1: [<all threads>]
    sigchld_handler
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
      [threads] operator(): check_zombie_leaders: leader_pid=724595, leader_lp!=NULL=1, num_lwps=2, zombie=0
      [threads] operator(): check_zombie_leaders: leader_pid=724597, leader_lp!=NULL=1, num_lwps=2, zombie=1
      [threads] operator(): Thread group leader 724597 zombie (it exited, or another thread execd).
      [threads] delete_lwp: deleting 724597
      [threads] wait_for_event_filtered: sigsuspend'ing
    sigchld_handler
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 724598, ERRNO-OK
      [threads] wait_for_event_filtered: waitpid 724598 received 0 (exited)
      [threads] filter_event: 724598 exited
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 724597, ERRNO-OK
      [threads] wait_for_event_filtered: waitpid 724597 received 0 (exited)
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
    sigchld_handler
      [threads] wait_1: ret = LWP 724597.724598, exited with retcode 0
    [threads] wait_1: exit

Change-Id: Idf0bdb4cb0313f1b49e4864071650cc83fb3c100
 2022-03-31 13:04:22 -04:00
Pedro Alves
8a841a3579 Re-add zombie leader on exit, gdbserver/linux 
Same as the previous patch, but for GDBserver.

In summary, the current zombie leader detection code in linux-low.cc
has a race -- if a multi-threaded inferior exits just before
check_zombie_leaders finds that the leader is now zombie via checking
/proc/PID/status, check_zombie_leaders deletes the leader, assuming we
won't get an event for that exit (which we won't in some scenarios,
but not in this one), which is a false-positive scenario, where the
whole process is simply exiting.  Later when we see the last LWP in
our list exit, we report that LWP's exit status as exit code, even
though for the (real) parent process, the exit code that counts is the
child's leader thread's exit code.

Like for GDB, the solution here is to:

   - only report whole-process exit events for the leader.
   - re-add the leader back to the LWP list when we finally see it
     exit.

Change-Id: Id2d7bbb51a415534e1294fff1d555b7ecaa87f1d
 2022-03-10 11:35:54 +00:00
Pedro Alves
aa40a989ef gdbserver: Reindent check_zombie_leaders 
This fixes the indentation of
linux_process_target::check_zombie_leaders, which will help with
keeping its comments in sync with the gdb/linux-nat.c counterpart.

Change-Id: I37332343bd80423d934249e3de2d04feefad1891
 2022-03-10 11:35:53 +00:00
Pedro Alves
5406bc3f1b gdbserver: Reorganize linux_process_target::filter_event 
Reorganize linux-low.cc:linux_process_target::filter_event such that
all the handling for events for LWPs not in the LWP list is together.
This helps make a following patch clearer.  The comments and debug
messages have also been tweaked to have them synchronized with the GDB
counterpart.

Change-Id: If9019635f63a846607cfda44b454b4254a404019
 2022-03-10 11:35:53 +00:00
Pedro Alves
e48359eaa8 Fix gdbserver/linux target_waitstatus logging assert 
Turning on debug output in gdbserver leads to an assertion failure if
gdbserver reports a non-signal event:

    [threads] wait_1: LWP 3273770: extended event with waitstatus status->kind = EXECD, execd_pathname = gdb.threads/non-ldr-exc-1/non-ldr-exc-1
    [threads] wait_1: Hit a non-gdbserver trap event.
  ../../src/gdbserver/../gdb/target/waitstatus.h:365: A problem internal to GDBserver has been detected.
  sig: Assertion `m_kind == TARGET_WAITKIND_STOPPED || m_kind == TARGET_WAITKIND_SIGNALLED' failed.

Fix it in the obvious way, using target_waitstatus::to_string(),
resulting in, for example:

  [threads] wait_1: ret = LWP 1542412.1542412, status->kind = STOPPED, sig = GDB_SIGNAL_TRAP

Change-Id: Ia4832f9b4fa39f4af67fcaf21fd4d909a285a645
 2022-03-10 11:35:53 +00:00
Roland McGrath
8674f082e3 Avoid conflict with gnulib open/close macros. 
On some systems, the gnulib configuration will decide to define open
and/or close as macros to replace the POSIX C functions.  This
interferes with using those names in C++ class or namespace scopes.

gdbsupport/
	* event-pipe.cc (event_pipe::open): Renamed to ...
	(event_pipe::open_pipe): ... this.
	(event_pipe::close): Renamed to ...
	(event_pipe::close_pipe): ... this.
	* event-pipe.h (class event_pipe): Updated.
gdb/
	* inf-ptrace.h (async_file_open, async_file_close): Updated.
gdbserver/
	* gdbserver/linux-low.cc (linux_process_target::async): Likewise.
 2022-03-03 11:21:36 -08:00
John Baldwin
cdc8e9b285 gdbserver linux-low: Convert linux_event_pipe to the event_pipe class. 
Use event_pipe from gdbsupport in place of the existing file
descriptor array.
 2022-02-22 11:22:14 -08:00
Simon Marchi
a288518611 gdb/linux: remove ptrace support check for exec, fork, vfork, vforkdone, clone, sysgood 
I think it's safe to remove checking support for these ptrace features,
they have all been added in what is now ancient times (around the
beginning of Linux 2.6).  This allows removing a bit of complexity in
linux-nat.c and nat/linux-ptrace.c.

It also allows saving one extra fork every time we start debugging on
Linux: linux_check_ptrace_features forks a child process to test if some
ptrace features are supported.  That child process forks a grand-child,
to test whether ptrace reports an event for the fork by the child.  This
is no longer needed, if we assume the kernel supports reporting forks.

PTRACE_O_TRACEVFORKDONE was introduced in Linux in this change, in 2003:

  https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=45c1a159b85b3b30afd26a77b4be312226bba416

PTRACE_O_TRACESYSGOOD was supported at least as of this change, in 2002:

  https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=acc7088569c8eef04eeed0eff51d23bb5bcff964

PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, PTRACE_O_TRACEEXEC and
PTRACE_O_TRACECLONE were introduced in this change, in 2002:

  https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=a0691b116f6a4473f0fa264210ab9b95771a2b46

Change-Id: Iffb906549a89cc6b619427f976ec044706ab1e8d
 2022-02-10 20:10:12 -05:00
Markus Metzger
696c0d5ef2 gdb, gdbserver: update thread identifier in enable_btrace target method 
The enable_btrace target method takes a ptid_t to identify the thread on
which tracing shall be enabled.

Change this to thread_info * to avoid translating back and forth between
the two.  This will be used in a subsequent patch.
 2022-01-27 13:31:20 +01:00
Simon Marchi
c058728c31 gdbserver: introduce threads_debug_printf, THREADS_SCOPED_DEBUG_ENTER_EXIT 
Add the threads_debug_printf and THREADS_SCOPED_DEBUG_ENTER_EXIT, which
use the logging infrastructure from gdbsupport/common-debug.h.  Replace
all debug_print uses that are predicated by debug_threads with
threads_dethreads_debug_printf.  Replace uses of the debug_enter and
debug_exit macros with THREADS_SCOPED_DEBUG_ENTER_EXIT, which serves
essentially the same purpose, but allows showing what comes between the
enter and the exit in an indented form.

Note that "threads" debug is currently used for a bit of everything in
GDBserver, not only threads related stuff.  It should ideally be cleaned
up and separated logically as is done in GDB, but that's out of the
scope of this patch.

Change-Id: I2d4546464462cb4c16f7f1168c5cec5a89f2289a
 2022-01-18 13:44:32 -05:00
Joel Brobecker
4a94e36819 Automatic Copyright Year update after running gdb/copyright.py 
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.

For the avoidance of doubt, all changes in this commits were
performed by the script.
 2022-01-01 19:13:23 +04:00
Tankut Baris Aktemur
20ac1cdb8c gdbserver/linux-low: replace direct assignment to current_thread 
Use scoped_restore_current_thread and switch_to_thread in
linux_process_target::wait_for_sigstop.
 2021-12-13 12:22:48 +01:00
Tankut Baris Aktemur
24583e45ef gdbserver: replace direct assignments to current_thread 
Replace the direct assignments to current_thread with
switch_to_thread.  Use scoped_restore_current_thread when appropriate.
There is one instance remaining in linux-low.cc's wait_for_sigstop.
This will be handled in a separate patch.

Regression-tested on X86-64 Linux using the native-gdbserver and
native-extended-gdbserver board files.
 2021-12-13 12:22:48 +01:00
Simon Marchi
df5ad10200 gdb, gdbserver: detach fork child when detaching from fork parent 
While working with pending fork events, I wondered what would happen if
the user detached an inferior while a thread of that inferior had a
pending fork event.  What happens with the fork child, which is
ptrace-attached by the GDB process (or by GDBserver), but not known to
the core?  Sure enough, neither the core of GDB or the target detach the
child process, so GDB (or GDBserver) just stays ptrace-attached to the
process.  The result is that the fork child process is stuck, while you
would expect it to be detached and run.

Make GDBserver detach of fork children it knows about.  That is done in
the generic handle_detach function.  Since a process_info already exists
for the child, we can simply call detach_inferior on it.

GDB-side, make the linux-nat and remote targets detach of fork children
known because of pending fork events.  These pending fork events can be
stored in:

 - thread_info::pending_waitstatus, if the core has consumed the event
   but then saved it for later (for example, because it got the event
   while stopping all threads, to present an all-stop stop on top of a
   non-stop target)
 - thread_info::pending_follow: if we ran to a "catch fork" and we
   detach at that moment

Additionally, pending fork events can be in target-specific fields:

 - For linux-nat, they can be in lwp_info::status and
   lwp_info::waitstatus.
 - For the remote target, they could be stored as pending stop replies,
   saved in `remote_state::notif_state::pending_event`, if not
   acknowledged yet, or in `remote_state::stop_reply_queue`, if
   acknowledged.  I followed the model of remove_new_fork_children for
   this: call remote_notif_get_pending_events to process /
   acknowledge any unacknowledged notification, then look through
   stop_reply_queue.

Update the gdb.threads/pending-fork-event.exp test (and rename it to
gdb.threads/pending-fork-event-detach.exp) to try to detach the process
while it is stopped with a pending fork event.  In order to verify that
the fork child process is correctly detached and resumes execution
outside of GDB's control, make that process create a file in the test
output directory, and make the test wait $timeout seconds for that file
to appear (it happens instantly if everything goes well).

This test catches a bug in linux-nat.c, also reported as PR 28512
("waitstatus.h:300: internal-error: gdb_signal target_waitstatus::sig()
const: Assertion `m_kind == TARGET_WAITKIND_STOPPED || m_kind ==
TARGET_WAITKIND_SIGNALLED' failed.).  When detaching a thread with a
pending event, get_detach_signal unconditionally fetches the signal
stored in the waitstatus (`tp->pending_waitstatus ().sig ()`).  However,
that is only valid if the pending event is of type
TARGET_WAITKIND_STOPPED, and this is now enforced using assertions (iit
would also be valid for TARGET_WAITKIND_SIGNALLED, but that would mean
the thread does not exist anymore, so we wouldn't be detaching it).  Add
a condition in get_detach_signal to access the signal number only if the
wait status is of kind TARGET_WAITKIND_STOPPED, and use GDB_SIGNAL_0
instead (since the thread was not stopped with a signal to begin with).

Add another test, gdb.threads/pending-fork-event-ns.exp, specifically to
verify that we consider events in pending stop replies in the remote
target.  This test has many threads constantly forking, and we detach
from the program while the program is executing.  That gives us some
chance that we detach while a fork stop reply is stored in the remote
target.  To verify that we correctly detach all fork children, we ask
the parent to exit by sending it a SIGUSR1 signal and have it write a
file to the filesystem before exiting.  Because the parent's main thread
joins the forking threads, and the forking threads wait for their fork
children to exit, if some fork child is not detach by GDB, the parent
will not write the file, and the test will time out.  If I remove the
new remote_detach_pid calls in remote.c, the test fails eventually if I
run it in a loop.

There is a known limitation: we don't remove breakpoints from the
children before detaching it.  So the children, could hit a trap
instruction after being detached and crash.  I know this is wrong, and
it should be fixed, but I would like to handle that later.  The current
patch doesn't fix everything, but it's a step in the right direction.

Change-Id: I6d811a56f520e3cb92d5ea563ad38976f92e93dd
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28512
 2021-12-08 21:00:39 -05:00
Simon Marchi
7b961964f8 gdbserver: hide fork child threads from GDB 
This patch aims at fixing a bug where an inferior is unexpectedly
created when a fork happens at the same time as another event, and that
other event is reported to GDB first (and the fork event stays pending
in GDBserver).  This happens for example when we step a thread and
another thread forks at the same time.  The bug looks like (if I
reproduce the included test by hand):

    (gdb) show detach-on-fork
    Whether gdb will detach the child of a fork is on.
    (gdb) show follow-fork-mode
    Debugger response to a program call of fork or vfork is "parent".
    (gdb) si
    [New inferior 2]
    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...
    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...
    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...
    [New Thread 965190.965190]
    [Switching to Thread 965190.965190]
    Remote 'g' packet reply is too long (expected 560 bytes, got 816 bytes): ... <long series of bytes>

The sequence of events leading to the problem is:

 - We are using the all-stop user-visible mode as well as the
   synchronous / all-stop variant of the remote protocol
 - We have two threads, thread A that we single-step and thread B that
   calls fork at the same time
 - GDBserver's linux_process_target::wait pulls the "single step
   complete SIGTRAP" and the "fork" events from the kernel.  It
   arbitrarily choses one event to report, it happens to be the
   single-step SIGTRAP.  The fork stays pending in the thread_info.
 - GDBserver send that SIGTRAP as a stop reply to GDB
 - While in stop_all_threads, GDB calls update_thread_list, which ends
   up querying the remote thread list using qXfer:threads:read.
 - In the reply, GDBserver includes the fork child created as a result
   of thread B's fork.
 - GDB-side, the remote target sees the new PID, calls
   remote_notice_new_inferior, which ends up unexpectedly creating a new
   inferior, and things go downhill from there.

The problem here is that as long as GDB did not process the fork event,
it should pretend the fork child does not exist.  Ultimately, this event
will be reported, we'll go through follow_fork, and that process will be
detached.

The remote target (GDB-side), has some code to remove from the reported
thread list the threads that are the result of forks not processed by
GDB yet.  But that only works for fork events that have made their way
to the remote target (GDB-side), but haven't been consumed by the core
yet, so are still lingering as pending stop replies in the remote target
(see remove_new_fork_children in remote.c).  But in our case, the fork
event hasn't made its way to the GDB-side remote target.  We need to
implement the same kind of logic GDBserver-side: if there exists a
thread / inferior that is the result of a fork event GDBserver hasn't
reported yet, it should exclude that thread / inferior from the reported
thread list.

This was actually discussed a while ago, but not implemented AFAIK:

    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t
    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html

Implementation details-wise, the fix for this is all in GDBserver.  The
Linux layer of GDBserver already tracks unreported fork parent / child
relationships using the lwp_info::fork_relative, in order to avoid
wildcard actions resuming fork childs unknown to GDB.  This information
needs to be made available to the handle_qxfer_threads_worker function,
so it can filter the reported threads.  Add a new thread_pending_parent
target function that allows the Linux target to return the parent of an
eventual fork child.

Testing-wise, the test replicates pretty-much the sequence of events
shown above.  The setup of the test makes it such that the main thread
is about to fork.  We stepi the other thread, so that the step completes
very quickly, in a single event.  Meanwhile, the main thread is resumed,
so very likely has time to call fork.  This means that the bug may not
reproduce every time (if the main thread does not have time to call
fork), but it will reproduce more often than not.  The test fails
without the fix applied on the native-gdbserver and
native-extended-gdbserver boards.

At some point I suspected that which thread called fork and which thread
did the step influenced the order in which the events were reported, and
therefore the reproducibility of the bug.  So I made the test try  both
combinations: main thread forks while other thread steps, and vice
versa.  I'm not sure this is still necessary, but I left it there
anyway.  It doesn't hurt to test a few more combinations.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28288
Change-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990
 2021-12-08 21:00:39 -05:00
Simon Marchi
7dca2ea7ff gdb: rename target_waitstatus_to_string to target_waitstatus::to_string 
Make target_waitstatus_to_string a "to_string" method of
target_waitstatus, a bit like we have ptid_t::to_string already.  This
will save a bit of typing.

Change-Id: Id261b7a09fa9fa3c738abac131c191a6f9c13905
 2021-11-22 13:57:43 -05:00
Simon Marchi
61d7f128e6 gdbserver: make target_pid_to_str return std::string 
I wanted to write a warning that included two target_pid_to_str calls,
like this:

    warning (_("Blabla %s, blabla %s"),
	     target_pid_to_str (ptid1),
	     target_pid_to_str (ptid2));

This doesn't work, because target_pid_to_str stores its result in a
static buffer, so my message would show twice the same ptid.  Change
target_pid_to_str to return an std::string to avoid this.  I don't think
we save much by using a static buffer, but it is more error-prone.

Change-Id: Ie3f649627686b84930529cc5c7c691ccf5d36dc2
 2021-10-25 14:33:55 -04:00
Simon Marchi
183be22290 gdb, gdbserver: make target_waitstatus safe 
I stumbled on a bug caused by the fact that a code path read
target_waitstatus::value::sig (expecting it to contain a gdb_signal
value) while target_waitstatus::kind was TARGET_WAITKIND_FORKED.  This
meant that the active union field was in fact
target_waitstatus::value::related_pid, and contained a ptid.  The read
signal value was therefore garbage, and that caused GDB to crash soon
after.  Or, since that GDB was built with ubsan, this nice error
message:

    /home/simark/src/binutils-gdb/gdb/linux-nat.c:1271:12: runtime error: load of value 2686365, which is not a valid value for type 'gdb_signal'

Despite being a large-ish change, I think it would be nice to make
target_waitstatus safe against that kind of bug.  As already done
elsewhere (e.g. dynamic_prop), validate that the type of value read from
the union matches what is supposed to be the active field.

 - Make the kind and value of target_waitstatus private.
 - Make the kind initialized to TARGET_WAITKIND_IGNORE on
   target_waitstatus construction.  This is what most users appear to do
   explicitly.
 - Add setters, one for each kind.  Each setter takes as a parameter the
   data associated to that kind, if any.  This makes it impossible to
   forget to attach the associated data.
 - Add getters, one for each associated data type.  Each getter
   validates that the data type fetched by the user matches the wait
   status kind.
 - Change "integer" to "exit_status", "related_pid" to "child_ptid",
   just because that's more precise terminology.
 - Fix all users.

That last point is semi-mechanical.  There are a lot of obvious changes,
but some less obvious ones.  For example, it's not possible to set the
kind at some point and the associated data later, as some users did.
But in any case, the intent of the code should not change in this patch.

This was tested on x86-64 Linux (unix, native-gdbserver and
native-extended-gdbserver boards).  It was built-tested on x86-64
FreeBSD, NetBSD, MinGW and macOS.  The rest of the changes to native
files was done as a best effort.  If I forgot any place to update in
these files, it should be easy to fix (unless the change happens to
reveal an actual bug).

Change-Id: I0ae967df1ff6e28de78abbe3ac9b4b2ff4ad03b7
 2021-10-21 16:13:56 -04:00
Simon Marchi
c360a4732b gdbserver: initialize the members of lwp_info in-class 
Add a constructor to initialize the waitstatus members.  Initialize the
others in the class directly.

Change-Id: I10f885eb33adfae86e3c97b1e135335b540d7442
 2021-10-21 16:10:54 -04:00
Tom Tromey
184ea2f731 Remove defaulted 'tid' parameter to ptid_t constructor 
I wanted to find, and potentially modify, all the spots where the
'tid' parameter to the ptid_t constructor was used.  So, I temporarily
removed this parameter and then rebuilt.

In order to make it simpler to search through the "real" (nonzero)
uses of this parameter, something I knew I'd have to do multiple
times, I removed any ", 0" from constructor calls.

Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
 2021-09-23 09:30:54 -06:00
H.J. Lu
4eb629d50d gdbserver: Check r_version < 1 for Linux debugger interface 
Update gdbserver to check r_version < 1 instead of r_version != 1 so
that r_version can be bumped for a new field in the glibc debugger
interface to support multiple namespaces.  Since so far, the gdbserver
only reads fields defined for r_version == 1, it is compatible with
r_version >= 1.

All future glibc debugger interface changes will be backward compatible.
If there is ever the need for backward incompatible change to the glibc
debugger interface, a new DT_XXX element will be provided to access the
new incompatible interface.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11839
 2021-08-17 06:19:49 -07:00
Simon Marchi
8d06918ff5 gdb, gdbserver: make status_to_str return std::string 
Instead of using a static buffer.  This is safer, and we don't really
mind about any extra dynamic allocation here, since it's only used for
debug purposes.

gdb/ChangeLog:

	* nat/linux-waitpid.c (status_to_str): Return std::string.
	* nat/linux-waitpid.h (status_to_str): Likewise.
	* linux-nat.c (linux_nat_post_attach_wait): Adjust.
	(linux_nat_target::attach): Adjust.
	(linux_handle_extended_wait): Adjust.
	(wait_lwp): Adjust.
	(stop_wait_callback): Adjust.
	(linux_nat_filter_event): Adjust.
	(linux_nat_wait_1): Adjust.
	* nat/linux-waitpid.c (status_to_str): Adjust.
	* nat/linux-waitpid.h (status_to_str): Adjust.

gdbserver/ChangeLog:

	* linux-low.cc (linux_process_target::wait_for_event_filtered):
	Adjust to status_to_str returning std::string.

Change-Id: Ia8aead70270438a5690f243e6faafff6c38ff757
 2021-05-08 21:07:20 -04:00
Pedro Alves
4655f8509f Don't run personality syscall at configure time; don't check it at all 
Currently, in order to tell whether support for disabling address
space randomization on Linux is available, GDB checks if the
personality syscall works, at configure time.  I.e., it does a run
test, instead of a compile/link test:

  AC_RUN_IFELSE([PERSONALITY_TEST],
		[have_personality=true],
		[have_personality=false],

This is a bit bogus, because the machine the build is done on may not
(and is when you consider distro gdbs) be the machine that eventually
runs gdb.  It would be better if this were a compile/link test
instead, and then at runtime, GDB coped with the personality syscall
failing.  Actually, GDB already copes.

One environment where this is problematic is building GDB in a Docker
container -- by default, Docker runs the container with seccomp, with
a profile that disables the personality syscall.  You can tell Docker
to use a less restricted seccomp profile, but I think we should just
fix it in GDB.

"man 2 personality" says:

       This system call first appeared in Linux 1.1.20 (and thus first
       in a stable kernel release with Linux 1.2.0); library support
       was added in glibc 2.3.

...

       ADDR_NO_RANDOMIZE (since Linux 2.6.12)
              With this flag set, disable address-space-layout randomization.

glibc 2.3 was released in 2002.
Linux 2.6.12 was released in 2005.

The original patch that added the configure checks was submitted in
2008.  The first version of the patch that was submitted to the list
called personality from common code:

 https://sourceware.org/pipermail/gdb-patches/2008-June/058204.html

and then was moved to Linux-specific code:

 https://sourceware.org/pipermail/gdb-patches/2008-June/058209.html

Since HAVE_PERSONALITY is only checked in Linux code, and
ADDR_NO_RANDOMIZE exists for over 15 years, I propose just completely
removing the configure checks.

If for some odd reason, some remotely modern system still needs a
configure check, then we can revert this commit but drop the
AC_RUN_IFELSE in favor of always doing the AC_LINK_IFELSE
cross-compile fallback.

gdb/ChangeLog:

	* linux-nat.c (linux_nat_target::supports_disable_randomization):
	Remove references to HAVE_PERSONALITY.
	* nat/linux-personality.c: Remove references to HAVE_PERSONALITY.
	(maybe_disable_address_space_randomization)
	(~maybe_disable_address_space_randomizatio): Remove references to
	HAVE_PERSONALITY.
	* config.in, configure: Regenerate.

gdbserver/ChangeLog:

	* linux-low.cc:
	(linux_process_target::supports_disable_randomization): Remove
	reference to HAVE_PERSONALITY.
	* config.in, configure: Regenerate.

gdbsupport/ChangeLog:

	* common.m4 (personality test): Remove.
 2021-05-08 13:45:36 +01:00
Pedro Alves
e2ea3a381a Don't include sys/personality.h in linux-low.cc anymore 
Lancelot pointed out that since the refactor at:

  https://sourceware.org/pipermail/gdb-patches/2015-January/120503.html

the sys/personality.h include is not needed in linux-low.cc anymore,
as it does not call personality directly itself anymore.

gdbserver/ChangeLog:

	* linux-low.cc: Don't include sys/personality.h or define
	ADDR_NO_RANDOMIZE.
 2021-05-08 13:09:52 +01:00
Tankut Baris Aktemur
04977957ec gdbserver: constify the 'pid_to_exec_file' target op 
gdbserver/ChangeLog:
2021-04-12  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* target.h (class process_stratum_target) <pid_to_exec_file>:
	Constify the return type.  Update the definition/references below.
	* target.cc (process_stratum_target::pid_to_exec_file)
	* linux-low.h (class linux_process_target) <pid_to_exec_file>
	* linux-low.cc (linux_process_target::pid_to_exec_file)
	* netbsd-low.h (class netbsd_process_target) <pid_to_exec_file>
	* netbsd-low.cc (netbsd_process_target::pid_to_exec_file)
	* server.cc (handle_qxfer_exec_file)
 2021-04-12 16:36:25 +02:00
Simon Marchi
1a48f0027d gdbserver: linux-low: make linux_process_target::filter_event return void 
Same as the previous patch, but for GDBserver.  The return value of this
method is never used, change it to return void.

gdbserver/ChangeLog:

	* linux-low.cc (linux_process_target::filter_event): Return
	void.
	* linux-low.h (class linux_process_target) <filter_event>:
	Return void.

Change-Id: I79e5dc04d9b21b9f01c6d675fa463d1b1a703b3a
 2021-02-23 10:56:56 -05:00
Pedro Alves
7e9cf1fe36 gdbserver: spurious SIGTRAP w/ detach while step-over in progress 
A following patch will add a new testcase that has two processes, each
with a number of threads constantly tripping a breakpoint and stepping
over it, because the breakpoint has a condition that evals false.
Then GDB detaches from one of the processes, while both processes are
running.  And then the testcase sends a SIGUSR1 to the other process.

When run against gdbserver, that would occasionaly fail like this:

 (gdb) PASS: gdb.threads/detach-step-over.exp: iter 1: detach
 Executing on target: kill -SIGUSR1 208303    (timeout = 300)
 spawn -ignore SIGHUP kill -SIGUSR1 208303

 Thread 2.5 "detach-step-ove" received signal SIGTRAP, Trace/breakpoint trap.
 [Switching to Thread 208303.208305]
 0x000055555555522a in thread_func (arg=0x0) at /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.threads/detach-step-over.c:54
 54            counter++; /* Set breakpoint here.  */

What happened was that GDBserver is doing a step-over for process A
when a detach request for process B arrives.  And that generates a
spurious SIGTRAP report for process A, as seen above.

The GDBserver logs reveal what happened:

 - GDB manages to detach while a step over is in progress.  That reaches
   linux_process_target::complete_ongoing_step_over(), which does:

      /* Passing NULL_PTID as filter indicates we want all events to
	 be left pending.  Eventually this returns when there are no
	 unwaited-for children left.  */
      ret = wait_for_event_filtered (minus_one_ptid, null_ptid, &wstat,
				     __WALL);

   As the comment say, this leaves all events pending, _including_ the
   just finished step SIGTRAP.  We never discard that SIGTRAP.  So
   GDBserver reports the SIGTRAP to GDB.  GDB can't explain the
   SIGTRAP, so it reports it to the user.

The GDBserver log looks like this.  The LWP of interest is 208305:

 Need step over [LWP 208305]? yes, found breakpoint at 0x555555555227
 proceed_all_lwps: found thread 208305 needing a step-over
 Starting step-over on LWP 208305.  Stopping all threads

208305 starts a step-over.

 >>>> entering void linux_process_target::stop_all_lwps(int, lwp_info*)
 stop_all_lwps (stop-and-suspend, except=LWP 208303.208305)
 Sending sigstop to lwp 208303
 Sending sigstop to lwp 207755
 wait_for_sigstop: pulling events
 LWFE: waitpid(-1, ...) returned 207755, ERRNO-OK
 LLW: waitpid 207755 received Stopped (signal) (stopped)
 pc is 0x7f7e045593bf
 Expected stop.
 LLW: SIGSTOP caught for LWP 207755.207755 while stopping threads.
 LWFE: waitpid(-1, ...) returned 208303, ERRNO-OK
 LLW: waitpid 208303 received Stopped (signal) (stopped)
 pc is 0x7ffff7e743bf
 Expected stop.
 LLW: SIGSTOP caught for LWP 208303.208303 while stopping threads.
 LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
 leader_pid=208303, leader_lp!=NULL=1, num_lwps=11, zombie=0
 leader_pid=207755, leader_lp!=NULL=1, num_lwps=11, zombie=0
 LLW: exit (no unwaited-for LWP)
 stop_all_lwps done, setting stopping_threads back to !stopping
 <<<< exiting void linux_process_target::stop_all_lwps(int, lwp_info*)
 Done stopping all threads for step-over.
 pc is 0x555555555227
 Writing 8b to 0x555555555227 in process 208305
 Could not findsigchld_handler
  fast tracepoint jump at 0x555555555227 in list (uninserting).
   pending reinsert at 0x555555555227
   step from pc 0x555555555227
 Resuming lwp 208305 (step, signal 0, stop expected)
 <<<< exiting ptid_t linux_process_target::wait_1(ptid_t, target_waitstatus*, target_wait_flags)
 handling possible serial event
 getpkt ("D;32b8b");  [no ack sent]

The detach request arrives.

 sigchld_handler
 Tracing is already off, ignoring
 detach: step over in progress, finish it first

GDBserver realizes a step over for 208305 was in progress, let's it
finish.

 LWFE: waitpid(-1, ...) returned 208305, ERRNO-OK
 LLW: waitpid 208305 received Stopped (signal) (stopped)
 pc is 0x555555555227
 Expected stop.
 LLW: step LWP 208303.208305, 0, 0 (discard delayed SIGSTOP)
   pending reinsert at 0x555555555227
   step from pc 0x555555555227
 Resuming lwp 208305 (step, signal 0, stop not expected)
 LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
 leader_pid=208303, leader_lp!=NULL=1, num_lwps=11, zombie=0
 leader_pid=207755, leader_lp!=NULL=1, num_lwps=11, zombie=0
 sigsuspend'ing
 LWFE: waitpid(-1, ...) returned 208305, ERRNO-OK
 LLW: waitpid 208305 received Trace/breakpoint trap (stopped)
 pc is 0x55555555522a
 CSBB: LWP 208303.208305 stopped by trace
 LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
 leader_pid=208303, leader_lp!=NULL=1, num_lwps=11, zombie=0
 leader_pid=207755, leader_lp!=NULL=1, num_lwps=11, zombie=0
 LLW: exit (no unwaited-for LWP)
 Finished step over.

The step-over for 208305 finishes.

 Writing cc to 0x555555555227 in process 208305
 Could not find fast tracepoint jump at 0x555555555227 in list (reinserting).
 >>>> entering void linux_process_target::stop_all_lwps(int, lwp_info*)
 stop_all_lwps (stop, except=none)
 wait_for_sigstop: pulling events

The detach proceeds (snipped).

...

 proceed_one_lwp: lwp 208305
    LWP 208305 has pending status, leaving stopped

Later on, 208305 has a pending status (the step SIGTRAP from the
step-over), so GDBserver starts the process of reporting it.

...

 wait_1 ret = LWP 208303.208305, 1, 5
 <<<< exiting ptid_t linux_process_target::wait_1(ptid_t, target_waitstatus*, target_wait_flags)

...

and eventually GDB receives the stop notification (T05 == SIGTRAP):

 getpkt ("vStopped");  [no ack sent]
 sigchld_handler
 vStopped: acking 3
 Writing resume reply for LWP 208303.208305:1
 putpkt ("$T0506:f0ee58f7ff7f0* ;07:f0ee58f7ff7f0* ;10:2a525*"550* ;thread:p32daf.32db1;core:c;#37"); [noack mode]

From the GDB side, we see:

 [infrun] fetch_inferior_event: enter
   [infrun] fetch_inferior_event: fetch_inferior_event enter
   [infrun] do_target_wait: Found 2 inferiors, starting at #1
   [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
   [infrun] print_target_wait_results:   208303.208305.0 [Thread 208303.208305],
   [infrun] print_target_wait_results:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
   [infrun] handle_inferior_event: status->kind = stopped, signal = GDB_SIGNAL_TRAP
   [infrun] start_step_over: enter
     [infrun] start_step_over: stealing global queue of threads to step, length = 6
     [infrun] operator(): putting back 6 threads to step in global queue
   [infrun] start_step_over: exit
   [infrun] handle_signal_stop: context switch
   [infrun] context_switch: Switching context from process 0 to Thread 208303.208305
   [infrun] handle_signal_stop: stop_pc=0x55555555522a
   [infrun] handle_signal_stop: random signal (GDB_SIGNAL_TRAP)
   [infrun] stop_waiting: stop_waiting
   [infrun] stop_all_threads: starting

The fix is to discard the step SIGTRAP, unless GDB wanted the thread
to step.

gdbserver/ChangeLog:

	* linux-low.cc (linux_process_target::complete_ongoing_step_over):
	Discard step SIGTRAP, unless GDB wanted the thread to step.
 2021-02-03 01:14:53 +00:00
Simon Marchi
6bd434d6ca gdb: make some variables static 
I'm trying to enable clang's -Wmissing-variable-declarations warning.
This patch fixes all the obvious spots where we can simply add "static"
(at least, found when building on x86-64 Linux).

gdb/ChangeLog:

	* aarch64-linux-tdep.c (aarch64_linux_record_tdep): Make static.
	* aarch64-tdep.c (tdesc_aarch64_list, aarch64_prologue_unwind,
	aarch64_stub_unwind, aarch64_normal_base, ): Make static.
	* arm-linux-tdep.c (arm_prologue_unwind): Make static.
	* arm-tdep.c (struct frame_unwind): Make static.
	* auto-load.c (auto_load_safe_path_vec): Make static.
	* csky-tdep.c (csky_stub_unwind): Make static.
	* gdbarch.c (gdbarch_data_registry): Make static.
	* gnu-v2-abi.c (gnu_v2_abi_ops): Make static.
	* i386-netbsd-tdep.c (i386nbsd_mc_reg_offset): Make static.
	* i386-tdep.c (i386_frame_setup_skip_insns,
	i386_tramp_chain_in_reg_insns, i386_tramp_chain_on_stack_insns):
	Make static.
	* infrun.c (observer_mode): Make static.
	* linux-nat.c (sigchld_action): Make static.
	* linux-thread-db.c (thread_db_list): Make static.
	* maint-test-options.c (maintenance_test_options_list):
	* mep-tdep.c (mep_csr_registers): Make static.
	* mi/mi-cmds.c (struct mi_cmd_stats): Remove struct type name.
	(stats): Make static.
	* nat/linux-osdata.c (struct osdata_type): Make static.
	* ppc-netbsd-tdep.c (ppcnbsd_reg_offsets): Make static.
	* progspace.c (last_program_space_num): Make static.
	* python/py-param.c (struct parm_constant): Remove struct type
	name.
	(parm_constants): Make static.
	* python/py-record-btrace.c (btpy_list_methods): Make static.
	* python/py-record.c (recpy_gap_type): Make static.
	* record.c (record_goto_cmdlist): Make static.
	* regcache.c (regcache_descr_handle): Make static.
	* registry.h (DEFINE_REGISTRY): Make definition static.
	* symmisc.c (std_in, std_out, std_err): Make static.
	* top.c (previous_saved_command_line): Make static.
	* tracepoint.c (trace_user, trace_notes, trace_stop_notes): Make
	static.
	* unittests/command-def-selftests.c (nr_duplicates,
	nr_invalid_prefixcmd, lists): Make static.
	* unittests/observable-selftests.c (test_notification): Make
	static.
	* unittests/optional/assignment/1.cc (counter): Make static.
	* unittests/optional/assignment/2.cc (counter): Make static.
	* unittests/optional/assignment/3.cc (counter): Make static.
	* unittests/optional/assignment/4.cc (counter): Make static.
	* unittests/optional/assignment/5.cc (counter): Make static.
	* unittests/optional/assignment/6.cc (counter): Make static.

gdbserver/ChangeLog:

	* ax.cc (bytecode_address_table): Make static.
	* debug.cc (debug_file): Make static.
	* linux-low.cc (stopping_threads): Make static.
	(step_over_bkpt): Make static.
	* linux-x86-low.cc (amd64_emit_ops, i386_emit_ops): Make static.
	* tracepoint.cc (stop_tracing_bkpt, flush_trace_buffer_bkpt,
	alloced_trace_state_variables, trace_buffer_ctrl,
	tracing_start_time, tracing_stop_time, tracing_user_name,
	tracing_notes, tracing_stop_note): Make static.

Change-Id: Ic1d8034723b7802502bda23770893be2338ab020
 2021-01-20 20:55:05 -05:00
Joel Brobecker
3666a04883 Update copyright year range in all GDB files 
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...

gdb/ChangeLog

        Update copyright year range in copyright header of all GDB files.
 2021-01-01 12:12:21 +04:00
Simon Marchi
dda83cd783 gdb, gdbserver, gdbsupport: fix leading space vs tabs issues 
Many spots incorrectly use only spaces for indentation (for example,
there are a lot of spots in ada-lang.c).  I've always found it awkward
when I needed to edit one of these spots: do I keep the original wrong
indentation, or do I fix it?  What if the lines around it are also
wrong, do I fix them too?  I probably don't want to fix them in the same
patch, to avoid adding noise to my patch.

So I propose to fix as much as possible once and for all (hopefully).

One typical counter argument for this is that it makes code archeology
more difficult, because git-blame will show this commit as the last
change for these lines.  My counter counter argument is: when
git-blaming, you often need to do "blame the file at the parent commit"
anyway, to go past some other refactor that touched the line you are
interested in, but is not the change you are looking for.  So you
already need a somewhat efficient way to do this.

Using some interactive tool, rather than plain git-blame, makes this
trivial.  For example, I use "tig blame <file>", where going back past
the commit that changed the currently selected line is one keystroke.
It looks like Magit in Emacs does it too (though I've never used it).
Web viewers of Github and Gitlab do it too.  My point is that it won't
really make archeology more difficult.

The other typical counter argument is that it will cause conflicts with
existing patches.  That's true... but it's a one time cost, and those
are not conflicts that are difficult to resolve.  I have also tried "git
rebase --ignore-whitespace", it seems to work well.  Although that will
re-introduce the faulty indentation, so one needs to take care of fixing
the indentation in the patch after that (which is easy).

gdb/ChangeLog:

	* aarch64-linux-tdep.c: Fix indentation.
	* aarch64-ravenscar-thread.c: Fix indentation.
	* aarch64-tdep.c: Fix indentation.
	* aarch64-tdep.h: Fix indentation.
	* ada-lang.c: Fix indentation.
	* ada-lang.h: Fix indentation.
	* ada-tasks.c: Fix indentation.
	* ada-typeprint.c: Fix indentation.
	* ada-valprint.c: Fix indentation.
	* ada-varobj.c: Fix indentation.
	* addrmap.c: Fix indentation.
	* addrmap.h: Fix indentation.
	* agent.c: Fix indentation.
	* aix-thread.c: Fix indentation.
	* alpha-bsd-nat.c: Fix indentation.
	* alpha-linux-tdep.c: Fix indentation.
	* alpha-mdebug-tdep.c: Fix indentation.
	* alpha-nbsd-tdep.c: Fix indentation.
	* alpha-obsd-tdep.c: Fix indentation.
	* alpha-tdep.c: Fix indentation.
	* amd64-bsd-nat.c: Fix indentation.
	* amd64-darwin-tdep.c: Fix indentation.
	* amd64-linux-nat.c: Fix indentation.
	* amd64-linux-tdep.c: Fix indentation.
	* amd64-nat.c: Fix indentation.
	* amd64-obsd-tdep.c: Fix indentation.
	* amd64-tdep.c: Fix indentation.
	* amd64-windows-tdep.c: Fix indentation.
	* annotate.c: Fix indentation.
	* arc-tdep.c: Fix indentation.
	* arch-utils.c: Fix indentation.
	* arch/arm-get-next-pcs.c: Fix indentation.
	* arch/arm.c: Fix indentation.
	* arm-linux-nat.c: Fix indentation.
	* arm-linux-tdep.c: Fix indentation.
	* arm-nbsd-tdep.c: Fix indentation.
	* arm-pikeos-tdep.c: Fix indentation.
	* arm-tdep.c: Fix indentation.
	* arm-tdep.h: Fix indentation.
	* arm-wince-tdep.c: Fix indentation.
	* auto-load.c: Fix indentation.
	* auxv.c: Fix indentation.
	* avr-tdep.c: Fix indentation.
	* ax-gdb.c: Fix indentation.
	* ax-general.c: Fix indentation.
	* bfin-linux-tdep.c: Fix indentation.
	* block.c: Fix indentation.
	* block.h: Fix indentation.
	* blockframe.c: Fix indentation.
	* bpf-tdep.c: Fix indentation.
	* break-catch-sig.c: Fix indentation.
	* break-catch-syscall.c: Fix indentation.
	* break-catch-throw.c: Fix indentation.
	* breakpoint.c: Fix indentation.
	* breakpoint.h: Fix indentation.
	* bsd-uthread.c: Fix indentation.
	* btrace.c: Fix indentation.
	* build-id.c: Fix indentation.
	* buildsym-legacy.h: Fix indentation.
	* buildsym.c: Fix indentation.
	* c-typeprint.c: Fix indentation.
	* c-valprint.c: Fix indentation.
	* c-varobj.c: Fix indentation.
	* charset.c: Fix indentation.
	* cli/cli-cmds.c: Fix indentation.
	* cli/cli-decode.c: Fix indentation.
	* cli/cli-decode.h: Fix indentation.
	* cli/cli-script.c: Fix indentation.
	* cli/cli-setshow.c: Fix indentation.
	* coff-pe-read.c: Fix indentation.
	* coffread.c: Fix indentation.
	* compile/compile-cplus-types.c: Fix indentation.
	* compile/compile-object-load.c: Fix indentation.
	* compile/compile-object-run.c: Fix indentation.
	* completer.c: Fix indentation.
	* corefile.c: Fix indentation.
	* corelow.c: Fix indentation.
	* cp-abi.h: Fix indentation.
	* cp-namespace.c: Fix indentation.
	* cp-support.c: Fix indentation.
	* cp-valprint.c: Fix indentation.
	* cris-linux-tdep.c: Fix indentation.
	* cris-tdep.c: Fix indentation.
	* darwin-nat-info.c: Fix indentation.
	* darwin-nat.c: Fix indentation.
	* darwin-nat.h: Fix indentation.
	* dbxread.c: Fix indentation.
	* dcache.c: Fix indentation.
	* disasm.c: Fix indentation.
	* dtrace-probe.c: Fix indentation.
	* dwarf2/abbrev.c: Fix indentation.
	* dwarf2/attribute.c: Fix indentation.
	* dwarf2/expr.c: Fix indentation.
	* dwarf2/frame.c: Fix indentation.
	* dwarf2/index-cache.c: Fix indentation.
	* dwarf2/index-write.c: Fix indentation.
	* dwarf2/line-header.c: Fix indentation.
	* dwarf2/loc.c: Fix indentation.
	* dwarf2/macro.c: Fix indentation.
	* dwarf2/read.c: Fix indentation.
	* dwarf2/read.h: Fix indentation.
	* elfread.c: Fix indentation.
	* eval.c: Fix indentation.
	* event-top.c: Fix indentation.
	* exec.c: Fix indentation.
	* exec.h: Fix indentation.
	* expprint.c: Fix indentation.
	* f-lang.c: Fix indentation.
	* f-typeprint.c: Fix indentation.
	* f-valprint.c: Fix indentation.
	* fbsd-nat.c: Fix indentation.
	* fbsd-tdep.c: Fix indentation.
	* findvar.c: Fix indentation.
	* fork-child.c: Fix indentation.
	* frame-unwind.c: Fix indentation.
	* frame-unwind.h: Fix indentation.
	* frame.c: Fix indentation.
	* frv-linux-tdep.c: Fix indentation.
	* frv-tdep.c: Fix indentation.
	* frv-tdep.h: Fix indentation.
	* ft32-tdep.c: Fix indentation.
	* gcore.c: Fix indentation.
	* gdb_bfd.c: Fix indentation.
	* gdbarch.sh: Fix indentation.
	* gdbarch.c: Re-generate
	* gdbarch.h: Re-generate.
	* gdbcore.h: Fix indentation.
	* gdbthread.h: Fix indentation.
	* gdbtypes.c: Fix indentation.
	* gdbtypes.h: Fix indentation.
	* glibc-tdep.c: Fix indentation.
	* gnu-nat.c: Fix indentation.
	* gnu-nat.h: Fix indentation.
	* gnu-v2-abi.c: Fix indentation.
	* gnu-v3-abi.c: Fix indentation.
	* go32-nat.c: Fix indentation.
	* guile/guile-internal.h: Fix indentation.
	* guile/scm-cmd.c: Fix indentation.
	* guile/scm-frame.c: Fix indentation.
	* guile/scm-iterator.c: Fix indentation.
	* guile/scm-math.c: Fix indentation.
	* guile/scm-ports.c: Fix indentation.
	* guile/scm-pretty-print.c: Fix indentation.
	* guile/scm-value.c: Fix indentation.
	* h8300-tdep.c: Fix indentation.
	* hppa-linux-nat.c: Fix indentation.
	* hppa-linux-tdep.c: Fix indentation.
	* hppa-nbsd-nat.c: Fix indentation.
	* hppa-nbsd-tdep.c: Fix indentation.
	* hppa-obsd-nat.c: Fix indentation.
	* hppa-tdep.c: Fix indentation.
	* hppa-tdep.h: Fix indentation.
	* i386-bsd-nat.c: Fix indentation.
	* i386-darwin-nat.c: Fix indentation.
	* i386-darwin-tdep.c: Fix indentation.
	* i386-dicos-tdep.c: Fix indentation.
	* i386-gnu-nat.c: Fix indentation.
	* i386-linux-nat.c: Fix indentation.
	* i386-linux-tdep.c: Fix indentation.
	* i386-nto-tdep.c: Fix indentation.
	* i386-obsd-tdep.c: Fix indentation.
	* i386-sol2-nat.c: Fix indentation.
	* i386-tdep.c: Fix indentation.
	* i386-tdep.h: Fix indentation.
	* i386-windows-tdep.c: Fix indentation.
	* i387-tdep.c: Fix indentation.
	* i387-tdep.h: Fix indentation.
	* ia64-libunwind-tdep.c: Fix indentation.
	* ia64-libunwind-tdep.h: Fix indentation.
	* ia64-linux-nat.c: Fix indentation.
	* ia64-linux-tdep.c: Fix indentation.
	* ia64-tdep.c: Fix indentation.
	* ia64-tdep.h: Fix indentation.
	* ia64-vms-tdep.c: Fix indentation.
	* infcall.c: Fix indentation.
	* infcmd.c: Fix indentation.
	* inferior.c: Fix indentation.
	* infrun.c: Fix indentation.
	* iq2000-tdep.c: Fix indentation.
	* language.c: Fix indentation.
	* linespec.c: Fix indentation.
	* linux-fork.c: Fix indentation.
	* linux-nat.c: Fix indentation.
	* linux-tdep.c: Fix indentation.
	* linux-thread-db.c: Fix indentation.
	* lm32-tdep.c: Fix indentation.
	* m2-lang.c: Fix indentation.
	* m2-typeprint.c: Fix indentation.
	* m2-valprint.c: Fix indentation.
	* m32c-tdep.c: Fix indentation.
	* m32r-linux-tdep.c: Fix indentation.
	* m32r-tdep.c: Fix indentation.
	* m68hc11-tdep.c: Fix indentation.
	* m68k-bsd-nat.c: Fix indentation.
	* m68k-linux-nat.c: Fix indentation.
	* m68k-linux-tdep.c: Fix indentation.
	* m68k-tdep.c: Fix indentation.
	* machoread.c: Fix indentation.
	* macrocmd.c: Fix indentation.
	* macroexp.c: Fix indentation.
	* macroscope.c: Fix indentation.
	* macrotab.c: Fix indentation.
	* macrotab.h: Fix indentation.
	* main.c: Fix indentation.
	* mdebugread.c: Fix indentation.
	* mep-tdep.c: Fix indentation.
	* mi/mi-cmd-catch.c: Fix indentation.
	* mi/mi-cmd-disas.c: Fix indentation.
	* mi/mi-cmd-env.c: Fix indentation.
	* mi/mi-cmd-stack.c: Fix indentation.
	* mi/mi-cmd-var.c: Fix indentation.
	* mi/mi-cmds.c: Fix indentation.
	* mi/mi-main.c: Fix indentation.
	* mi/mi-parse.c: Fix indentation.
	* microblaze-tdep.c: Fix indentation.
	* minidebug.c: Fix indentation.
	* minsyms.c: Fix indentation.
	* mips-linux-nat.c: Fix indentation.
	* mips-linux-tdep.c: Fix indentation.
	* mips-nbsd-tdep.c: Fix indentation.
	* mips-tdep.c: Fix indentation.
	* mn10300-linux-tdep.c: Fix indentation.
	* mn10300-tdep.c: Fix indentation.
	* moxie-tdep.c: Fix indentation.
	* msp430-tdep.c: Fix indentation.
	* namespace.h: Fix indentation.
	* nat/fork-inferior.c: Fix indentation.
	* nat/gdb_ptrace.h: Fix indentation.
	* nat/linux-namespaces.c: Fix indentation.
	* nat/linux-osdata.c: Fix indentation.
	* nat/netbsd-nat.c: Fix indentation.
	* nat/x86-dregs.c: Fix indentation.
	* nbsd-nat.c: Fix indentation.
	* nbsd-tdep.c: Fix indentation.
	* nios2-linux-tdep.c: Fix indentation.
	* nios2-tdep.c: Fix indentation.
	* nto-procfs.c: Fix indentation.
	* nto-tdep.c: Fix indentation.
	* objfiles.c: Fix indentation.
	* objfiles.h: Fix indentation.
	* opencl-lang.c: Fix indentation.
	* or1k-tdep.c: Fix indentation.
	* osabi.c: Fix indentation.
	* osabi.h: Fix indentation.
	* osdata.c: Fix indentation.
	* p-lang.c: Fix indentation.
	* p-typeprint.c: Fix indentation.
	* p-valprint.c: Fix indentation.
	* parse.c: Fix indentation.
	* ppc-linux-nat.c: Fix indentation.
	* ppc-linux-tdep.c: Fix indentation.
	* ppc-nbsd-nat.c: Fix indentation.
	* ppc-nbsd-tdep.c: Fix indentation.
	* ppc-obsd-nat.c: Fix indentation.
	* ppc-ravenscar-thread.c: Fix indentation.
	* ppc-sysv-tdep.c: Fix indentation.
	* ppc64-tdep.c: Fix indentation.
	* printcmd.c: Fix indentation.
	* proc-api.c: Fix indentation.
	* producer.c: Fix indentation.
	* producer.h: Fix indentation.
	* prologue-value.c: Fix indentation.
	* prologue-value.h: Fix indentation.
	* psymtab.c: Fix indentation.
	* python/py-arch.c: Fix indentation.
	* python/py-bpevent.c: Fix indentation.
	* python/py-event.c: Fix indentation.
	* python/py-event.h: Fix indentation.
	* python/py-finishbreakpoint.c: Fix indentation.
	* python/py-frame.c: Fix indentation.
	* python/py-framefilter.c: Fix indentation.
	* python/py-inferior.c: Fix indentation.
	* python/py-infthread.c: Fix indentation.
	* python/py-objfile.c: Fix indentation.
	* python/py-prettyprint.c: Fix indentation.
	* python/py-registers.c: Fix indentation.
	* python/py-signalevent.c: Fix indentation.
	* python/py-stopevent.c: Fix indentation.
	* python/py-stopevent.h: Fix indentation.
	* python/py-threadevent.c: Fix indentation.
	* python/py-tui.c: Fix indentation.
	* python/py-unwind.c: Fix indentation.
	* python/py-value.c: Fix indentation.
	* python/py-xmethods.c: Fix indentation.
	* python/python-internal.h: Fix indentation.
	* python/python.c: Fix indentation.
	* ravenscar-thread.c: Fix indentation.
	* record-btrace.c: Fix indentation.
	* record-full.c: Fix indentation.
	* record.c: Fix indentation.
	* reggroups.c: Fix indentation.
	* regset.h: Fix indentation.
	* remote-fileio.c: Fix indentation.
	* remote.c: Fix indentation.
	* reverse.c: Fix indentation.
	* riscv-linux-tdep.c: Fix indentation.
	* riscv-ravenscar-thread.c: Fix indentation.
	* riscv-tdep.c: Fix indentation.
	* rl78-tdep.c: Fix indentation.
	* rs6000-aix-tdep.c: Fix indentation.
	* rs6000-lynx178-tdep.c: Fix indentation.
	* rs6000-nat.c: Fix indentation.
	* rs6000-tdep.c: Fix indentation.
	* rust-lang.c: Fix indentation.
	* rx-tdep.c: Fix indentation.
	* s12z-tdep.c: Fix indentation.
	* s390-linux-tdep.c: Fix indentation.
	* score-tdep.c: Fix indentation.
	* ser-base.c: Fix indentation.
	* ser-mingw.c: Fix indentation.
	* ser-uds.c: Fix indentation.
	* ser-unix.c: Fix indentation.
	* serial.c: Fix indentation.
	* sh-linux-tdep.c: Fix indentation.
	* sh-nbsd-tdep.c: Fix indentation.
	* sh-tdep.c: Fix indentation.
	* skip.c: Fix indentation.
	* sol-thread.c: Fix indentation.
	* solib-aix.c: Fix indentation.
	* solib-darwin.c: Fix indentation.
	* solib-frv.c: Fix indentation.
	* solib-svr4.c: Fix indentation.
	* solib.c: Fix indentation.
	* source.c: Fix indentation.
	* sparc-linux-tdep.c: Fix indentation.
	* sparc-nbsd-tdep.c: Fix indentation.
	* sparc-obsd-tdep.c: Fix indentation.
	* sparc-ravenscar-thread.c: Fix indentation.
	* sparc-tdep.c: Fix indentation.
	* sparc64-linux-tdep.c: Fix indentation.
	* sparc64-nbsd-tdep.c: Fix indentation.
	* sparc64-obsd-tdep.c: Fix indentation.
	* sparc64-tdep.c: Fix indentation.
	* stabsread.c: Fix indentation.
	* stack.c: Fix indentation.
	* stap-probe.c: Fix indentation.
	* stubs/ia64vms-stub.c: Fix indentation.
	* stubs/m32r-stub.c: Fix indentation.
	* stubs/m68k-stub.c: Fix indentation.
	* stubs/sh-stub.c: Fix indentation.
	* stubs/sparc-stub.c: Fix indentation.
	* symfile-mem.c: Fix indentation.
	* symfile.c: Fix indentation.
	* symfile.h: Fix indentation.
	* symmisc.c: Fix indentation.
	* symtab.c: Fix indentation.
	* symtab.h: Fix indentation.
	* target-float.c: Fix indentation.
	* target.c: Fix indentation.
	* target.h: Fix indentation.
	* tic6x-tdep.c: Fix indentation.
	* tilegx-linux-tdep.c: Fix indentation.
	* tilegx-tdep.c: Fix indentation.
	* top.c: Fix indentation.
	* tracefile-tfile.c: Fix indentation.
	* tracepoint.c: Fix indentation.
	* tui/tui-disasm.c: Fix indentation.
	* tui/tui-io.c: Fix indentation.
	* tui/tui-regs.c: Fix indentation.
	* tui/tui-stack.c: Fix indentation.
	* tui/tui-win.c: Fix indentation.
	* tui/tui-winsource.c: Fix indentation.
	* tui/tui.c: Fix indentation.
	* typeprint.c: Fix indentation.
	* ui-out.h: Fix indentation.
	* unittests/copy_bitwise-selftests.c: Fix indentation.
	* unittests/memory-map-selftests.c: Fix indentation.
	* utils.c: Fix indentation.
	* v850-tdep.c: Fix indentation.
	* valarith.c: Fix indentation.
	* valops.c: Fix indentation.
	* valprint.c: Fix indentation.
	* valprint.h: Fix indentation.
	* value.c: Fix indentation.
	* value.h: Fix indentation.
	* varobj.c: Fix indentation.
	* vax-tdep.c: Fix indentation.
	* windows-nat.c: Fix indentation.
	* windows-tdep.c: Fix indentation.
	* xcoffread.c: Fix indentation.
	* xml-syscall.c: Fix indentation.
	* xml-tdesc.c: Fix indentation.
	* xstormy16-tdep.c: Fix indentation.
	* xtensa-config.c: Fix indentation.
	* xtensa-linux-nat.c: Fix indentation.
	* xtensa-linux-tdep.c: Fix indentation.
	* xtensa-tdep.c: Fix indentation.

gdbserver/ChangeLog:

	* ax.cc: Fix indentation.
	* dll.cc: Fix indentation.
	* inferiors.h: Fix indentation.
	* linux-low.cc: Fix indentation.
	* linux-nios2-low.cc: Fix indentation.
	* linux-ppc-ipa.cc: Fix indentation.
	* linux-ppc-low.cc: Fix indentation.
	* linux-x86-low.cc: Fix indentation.
	* linux-xtensa-low.cc: Fix indentation.
	* regcache.cc: Fix indentation.
	* server.cc: Fix indentation.
	* tracepoint.cc: Fix indentation.

gdbsupport/ChangeLog:

	* common-exceptions.h: Fix indentation.
	* event-loop.cc: Fix indentation.
	* fileio.cc: Fix indentation.
	* filestuff.cc: Fix indentation.
	* gdb-dlfcn.cc: Fix indentation.
	* gdb_string_view.h: Fix indentation.
	* job-control.cc: Fix indentation.
	* signals.cc: Fix indentation.

Change-Id: I4bad7ae6be0fbe14168b8ebafb98ffe14964a695
 2020-11-02 10:28:45 -05:00
Andrew Burgess
51a948fdf0 gdb: Have allocate_target_description return a unique_ptr 
Update allocate_target_description to return a target_desc_up, a
specialisation of unique_ptr.

This commit does not attempt to make use of the unique_ptr in the
best possible way, in almost all cases we immediately release the
pointer from within the unique_ptr and then continue as before.

There are a few places where it was easy to handle the unique_ptr, and
in these cases I've done that.

Everything under gdb/features/* is auto-regenerated.

There should be no user visible changes after this commit.

gdb/ChangeLog:

	* arch/aarch32.c (aarch32_create_target_description): Release
	unique_ptr returned from allocate_target_description.
	* arch/aarch64.c (aarch64_create_target_description): Likewise.
	* arch/amd64.c (amd64_create_target_description): Likewise.
	* arch/arc.c (arc_create_target_description): Likewise.
	* arch/arm.c (arm_create_target_description): Likewise.
	* arch/i386.c (i386_create_target_description): Likewise.
	* arch/riscv.c (riscv_create_target_description): Update return
	type.  Handle allocate_target_description returning a unique_ptr.
	(riscv_lookup_target_description): Update to handle unique_ptr.
	* arch/tic6x.c (tic6x_create_target_description): Release
	unique_ptr returned from allocate_target_description.
	* features/microblaze-with-stack-protect.c: Regenerate.
	* features/microblaze.c: Regenerate.
	* features/mips-dsp-linux.c: Regenerate.
	* features/mips-linux.c: Regenerate.
	* features/mips64-dsp-linux.c: Regenerate.
	* features/mips64-linux.c: Regenerate.
	* features/nds32.c: Regenerate.
	* features/nios2.c: Regenerate.
	* features/or1k.c: Regenerate.
	* features/rs6000/powerpc-32.c: Regenerate.
	* features/rs6000/powerpc-32l.c: Regenerate.
	* features/rs6000/powerpc-403.c: Regenerate.
	* features/rs6000/powerpc-403gc.c: Regenerate.
	* features/rs6000/powerpc-405.c: Regenerate.
	* features/rs6000/powerpc-505.c: Regenerate.
	* features/rs6000/powerpc-601.c: Regenerate.
	* features/rs6000/powerpc-602.c: Regenerate.
	* features/rs6000/powerpc-603.c: Regenerate.
	* features/rs6000/powerpc-604.c: Regenerate.
	* features/rs6000/powerpc-64.c: Regenerate.
	* features/rs6000/powerpc-64l.c: Regenerate.
	* features/rs6000/powerpc-7400.c: Regenerate.
	* features/rs6000/powerpc-750.c: Regenerate.
	* features/rs6000/powerpc-860.c: Regenerate.
	* features/rs6000/powerpc-altivec32.c: Regenerate.
	* features/rs6000/powerpc-altivec32l.c: Regenerate.
	* features/rs6000/powerpc-altivec64.c: Regenerate.
	* features/rs6000/powerpc-altivec64l.c: Regenerate.
	* features/rs6000/powerpc-e500.c: Regenerate.
	* features/rs6000/powerpc-e500l.c: Regenerate.
	* features/rs6000/powerpc-isa205-32l.c: Regenerate.
	* features/rs6000/powerpc-isa205-64l.c: Regenerate.
	* features/rs6000/powerpc-isa205-altivec32l.c: Regenerate.
	* features/rs6000/powerpc-isa205-altivec64l.c: Regenerate.
	* features/rs6000/powerpc-isa205-ppr-dscr-vsx32l.c: Regenerate.
	* features/rs6000/powerpc-isa205-ppr-dscr-vsx64l.c: Regenerate.
	* features/rs6000/powerpc-isa205-vsx32l.c: Regenerate.
	* features/rs6000/powerpc-isa205-vsx64l.c: Regenerate.
	* features/rs6000/powerpc-isa207-htm-vsx32l.c: Regenerate.
	* features/rs6000/powerpc-isa207-htm-vsx64l.c: Regenerate.
	* features/rs6000/powerpc-isa207-vsx32l.c: Regenerate.
	* features/rs6000/powerpc-isa207-vsx64l.c: Regenerate.
	* features/rs6000/powerpc-vsx32.c: Regenerate.
	* features/rs6000/powerpc-vsx32l.c: Regenerate.
	* features/rs6000/powerpc-vsx64.c: Regenerate.
	* features/rs6000/powerpc-vsx64l.c: Regenerate.
	* features/rs6000/rs6000.c: Regenerate.
	* features/rx.c: Regenerate.
	* features/s390-gs-linux64.c: Regenerate.
	* features/s390-linux32.c: Regenerate.
	* features/s390-linux32v1.c: Regenerate.
	* features/s390-linux32v2.c: Regenerate.
	* features/s390-linux64.c: Regenerate.
	* features/s390-linux64v1.c: Regenerate.
	* features/s390-linux64v2.c: Regenerate.
	* features/s390-te-linux64.c: Regenerate.
	* features/s390-tevx-linux64.c: Regenerate.
	* features/s390-vx-linux64.c: Regenerate.
	* features/s390x-gs-linux64.c: Regenerate.
	* features/s390x-linux64.c: Regenerate.
	* features/s390x-linux64v1.c: Regenerate.
	* features/s390x-linux64v2.c: Regenerate.
	* features/s390x-te-linux64.c: Regenerate.
	* features/s390x-tevx-linux64.c: Regenerate.
	* features/s390x-vx-linux64.c: Regenerate.
	* mips-tdep.c (_initialize_mips_tdep): Release unique_ptr returned
	from allocate_target_description.
	* target-descriptions.c (allocate_target_description): Update
	return type.
	(print_c_tdesc::visit_pre): Release unique_ptr returned from
	allocate_target_description.

gdbserver/ChangeLog:

	* linux-low.cc (linux_process_target::handle_extended_wait):
	Release the unique_ptr returned from allocate_target_description.
	* linux-riscv-low.cc (riscv_target::low_arch_setup): Likewise.
	* linux-x86-low.cc (tdesc_amd64_linux_no_xml): Change type.
	(tdesc_i386_linux_no_xml): Change type.
	(x86_linux_read_description): Borrow pointer from unique_ptr
	object.
	(x86_target::get_ipa_tdesc_idx): Likewise.
	(initialize_low_arch): Likewise.
	* tdesc.cc (allocate_target_description): Update return type.

gdbsupport/ChangeLog:

	* tdesc.h (allocate_target_description): Update return type.
 2020-10-08 10:14:14 +01:00