This patch is a preparation for the next patches implementing MTE. It just adds
a HWCAP2 constant for MTE, creates a new generic arch/aarch64-mte-linux.h file
and includes that file in the source files that will use it.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* Makefile.in (HFILES_NO_SRCDIR): Add arch/aarch64-mte-linux.h.
* aarch64-linux-nat.c: Include arch/aarch64-mte-linux.h.
* aarch64-linux-tdep.c: Likewise
* arch/aarch64-mte-linux.h: New file.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-low.cc: Include arch/aarch64-mte-linux.h.
Add some unit testing to exercise the functions handling the qMemTags and
QMemTags packets as well as feature support.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* server.cc (test_memory_tagging_functions): New function.
(captured_main): Register test_memory_tagging_functions.
This patch adds the generic remote bits to gdbserver so it can check for memory
tagging support and handle fetch tags and store tags requests.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* remote-utils.cc (decode_m_packet_params): Renamed from ...
(decode_m_packet): ... this, which now calls decode_m_packet_params.
Make char * param/return const char *.
(decode_M_packet): Use decode_m_packet_params and make char * param
const char *.
* remote-utils.h (decode_m_packet_params): New prototype.
(decode_m_packet): Constify char pointers.
(decode_M_packet): Likewise.
* server.cc (create_fetch_memtags_reply)
(parse_store_memtags_request): New
functions.
(handle_general_set): Handle the QMemTags packet.
(parse_fetch_memtags_request): New function.
(handle_query): Handle the qMemTags packet and advertise memory
tagging support.
(captured_main): Initialize memory tagging flag.
* server.h (struct client_state): Initialize memory tagging flag.
* target.cc (process_stratum_target::supports_memory_tagging)
(process_stratum_target::fetch_memtags)
(process_stratum_target::store_memtags): New methods.
* target.h: Include gdbsupport/byte-vector.h.
(class process_stratum_target) <supports_memory_tagging>
<fetch_memtags, store_memtags>: New class virtual methods.
(target_supports_memory_tagging): Define.
The 'all_dlls' list is global. This would cause the complete dll list
to be reported for individual processes. Move the list into the
process_info struct.
Currently the dll list is used only by the win32-low target, which
does not support the multi-process feature. Therefore, it practically
does not matter whether the list is global or per-process. However,
there may be targets that are outside the binutils-gdb repo (e.g. we,
at Intel, have such a target) that have multi-process and use the dll
list. So, it makes sense to do the right thing.
gdbserver/ChangeLog:
2021-03-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* inferiors.h (struct process_info) <all_dlls, dlls_changed>: New
fields.
* dll.h (loaded_dll)
(unloaded_dll): Declare an overloaded version that takes a proc
parameter.
* dll.cc (loaded_dll)
(unloaded_dll): Implement the overloaded versions.
(clear_dlls): Clear all process' dll lists.
(all_dlls, dlls_changed): Remove the global variables.
* remote-utils.cc (prepare_resume_reply): Update to consider a dll
list per proc.
* server.cc (handle_qxfer_libraries): Ditto.
(handle_v_attach): Ditto.
(captured_main): Ditto.
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
I've been using gdbreplay to help debug an intermittent failure, and I
wanted it to be a little simpler to use. This patch adds support for
"-" as the "address" argument. With this patch you can do:
(gdb) target remote | gdbreplay logfile -
... and not have to start gdbreplay in a separate shell.
2021-02-12 Tom Tromey <tromey@adacore.com>
* gdbreplay.cc (remote_desc): Remove.
(remote_desc_in, remote_desc_out): New globals.
(remote_close): Update.
(remote_open): Handle "-".
(remote_open): Update.
(logchar): Log to stderr.
(expect, play): Update.
This fixes PR27184, a failure to compile gdb due to
cdefs.h being out of sync with glibc on ppc64le targets
which are compiled with -mabi=ieeelongdouble and glibc
2.32.
Likewise, update usage of _GL_ATTRIBUTE_FORMAT_PRINTF to
_GL_ATTRIBUTE_FORMAT_PRINTF_STANDARD.
Likewise, disable newly added rpl_free gnulib api in
gdbserver support libraries.
Likewise, undefine read/write macros before redefining them
on mingw targets.
Likewise, wrap C++ usage of free with GNULIB_NAMESPACE namespace
as needed.
Change-Id: I86517613c0d8ac8f5ea45bbc4ebe2b54a3aef29f
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.
A following patch will add a testcase that has two processes with
threads stepping over a breakpoint continuously, and then detaches
from one of the processes while threads are running. The other
process continues stepping over its breakpoint. And then the testcase
sends a SIGUSR1, expecting that GDB reports it. That would sometimes
hang against gdbserver, due to the bugs fixed here. Both bugs are
related, in that they're about remote protocol asynchronous Stop
notifications. There's a bug in GDB, and another in GDBserver.
The GDB bug:
- when we detach from a process, the remote target discards any
pending RSP notification related to that process, including the
in-flight, yet-unacked notification. Discarding the in-flight
notification is the problem. Until the in-flight notification is
acked with a vStopped packet, the server won't send another %Stop
notification. As a result, the debug session gets messed up. In
the new testcase's case, GDB would hang inside stop_all_threads,
waiting for a stop for one of the process'es threads, which never
arrived -- its stop reply was permanently stuck in the stop reply
queue, waiting for a vStopped packet that never arrived.
In summary:
1. GDBserver sends stop notification about thread X, the remote
target receives it and stores it
2. At the same time, GDB detaches thread X's inferior
3. The remote target discards the received stop notification
4. GDBserver waits forever for the ack
The GDBserver bug:
GDBserver has the opposite bug. It also discards notifications for
the process being detached. If that discards the head of the
notification queue, when gdb sends an ack, it ends up acking the
_next_ notification. Meaning, gdb loses one notification. In the
testcase, this results in a similar hang in stop_all_threads.
So we have two very similar bugs in GDB and GDBserver, both resulting
in a similar symptom. That's why I'm fixing them both at the same
time.
gdb/ChangeLog:
* remote.c (remote_notif_stop_ack): Don't error out on
TARGET_WAITKIND_IGNORE; instead, just ignore the notification.
(remote_target::discard_pending_stop_replies): Don't delete
in-flight notification; instead, clear its contents.
gdbserver/ChangeLog:
* server.cc (discard_queued_stop_replies): Don't ever discard the
notification at the head of the list.
Consider a minimal test-case test.c:
...
int main (void) { return 0; }
...
compiled with -m32:
...
$ gcc test.c -m32
...
When running the exec using gdbserver on openSUSE Factory (currently running a
linux kernel version 5.10.5):
...
$ gdbserver localhost:12345 a.out
...
to which we connect in a gdb session, we run into a segfault in the inferior:
...
$ gdb -batch -q -ex "target remote localhost:12345" -ex continue
Program received signal SIGSEGV, Segmentation fault.
0xf7dd8bd2 in init_cacheinfo () at ../sysdeps/x86/cacheinfo.c:761
...
The segfault is caused by gdbserver overwriting $gs_base with 0 using
PTRACE_SETREGS. After it is overwritten, the next use of $gs in the inferior
will trigger the segfault.
Before linux kernel version 5.9, the value used by PTRACE_SETREGS for $gs_base
was ignored, but starting version 5.9, the linux kernel has support for
intel architecture extension FSGSBASE, which allows users to modify $gs_base,
and consequently PTRACE_SETREGS can no longer ignore the $gs_base value.
The overwrite of $gs_base with 0 is done by a memset in x86_fill_gregset,
which was added in commit 9e0aa64f55 "Fix gdbserver qGetTLSAddr for
x86_64 -m32". The memset intends to zero-extend 32-bit registers that are
tracked in the regcache to 64-bit when writing them into the PTRACE_SETREGS
data argument. But in addition, it overwrites other registers that are
not tracked in the regcache, such as $gs_base.
Fix the segfault by redoing the fix from commit 9e0aa64f55 in minimal form.
Tested on x86_64-linux:
- openSUSE Leap 15.2 (using kernel version 5.3.18):
- native
- gdbserver -m32
- -m32
- openSUSE Factory (using kernel version 5.10.5):
- native
- m32
gdbserver/ChangeLog:
2021-01-20 Tom de Vries <tdevries@suse.de>
* linux-x86-low.cc (collect_register_i386): New function.
(x86_fill_gregset): Remove memset. Use collect_register_i386.
When doing a gdbserver build with CFLAGS/CXXFLAGS/LDFLAGS=-fsanitize=address
we run into:
...
ld: ../libiberty/libiberty.a(safe-ctype.o):
relocation R_X86_64_32 against `.data' can not be used when making a
shared object; recompile with -fPIC
collect2: error: ld returned 1 exit status
make[1]: *** [libinproctrace.so] Error 1
...
This started with commit 9664849417 "gdbsupport: make use of safe-ctype
functions from libiberty", which introduced a dependency of libinproctrace.so
on libiberty.
Fix this in gdbserver/Makefile.in by using a setup similar to what is done in
gcc-repo/src/libcc1/Makefile.am, such that ../libiberty/noasan/libiberty.a is
used instead.
Build on x86_64-linux, both with and without -fsanitize=address.
gdbserver/ChangeLog:
2021-01-07 Tom de Vries <tdevries@suse.de>
* Makefile.in (LIBIBERTY_NORMAL, LIBIBERTY_NOASAN, LIBIBERTY_PIC):
(LIBIBERTY_FOR_SHLIB): New var.
(LIBIBERTY): Set using $(LIBIBERTY_NORMAL).
(IPA_LIB): Use LIBIBERTY_FOR_SHLIB instead of LIBIBERTY in target rule.
I spent a lot of time reading infrun debug logs recently, and I think
they could be made much more readable by being indented, to clearly see
what operation is done as part of what other operation. In the current
format, there are no visual cues to tell where things start and end,
it's just a big flat list. It's also difficult to understand what
caused a given operation (e.g. a call to resume_1) to be done.
To help with this, I propose to add the new scoped_debug_start_end
structure, along with a bunch of macros to make it convenient to use.
The idea of scoped_debug_start_end is simply to print a start and end
message at construction and destruction. It also increments/decrements
a depth counter in order to make debug statements printed during this
range use some indentation. Some care is taken to handle the fact that
debug can be turned on or off in the middle of such a range. For
example, a "set debug foo 1" command in a breakpoint command, or a
superior GDB manually changing the debug_foo variable.
Two macros are added in gdbsupport/common-debug.h, which are helpers to
define module-specific macros:
- scoped_debug_start_end: takes a message that is printed both at
construction / destruction, with "start: " and "end: " prefixes.
- scoped_debug_enter_exit: prints hard-coded "enter" and "exit"
messages, to denote the entry and exit of a function.
I added some examples in the infrun module to give an idea of how it can
be used and what the result looks like. The macros are in capital
letters (INFRUN_SCOPED_DEBUG_START_END and
INFRUN_SCOPED_DEBUG_ENTER_EXIT) to mimic the existing SCOPE_EXIT, but
that can be changed if you prefer something else.
Here's an excerpt of the debug
statements printed when doing "continue", where a displaced step is
started:
[infrun] proceed: enter
[infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
[infrun] global_thread_step_over_chain_enqueue: enqueueing thread Thread 0x7ffff75a5640 (LWP 2289301) in global step over chain
[infrun] start_step_over: enter
[infrun] start_step_over: stealing global queue of threads to step, length = 1
[infrun] start_step_over: resuming [Thread 0x7ffff75a5640 (LWP 2289301)] for step-over
[infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [Thread 0x7ffff75a5640 (LWP 2289301)] at 0x5555555551bd
[displaced] displaced_step_prepare_throw: displaced-stepping Thread 0x7ffff75a5640 (LWP 2289301) now
[displaced] prepare: selected buffer at 0x5555555550c2
[displaced] prepare: saved 0x5555555550c2: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50
[displaced] amd64_displaced_step_copy_insn: copy 0x5555555551bd->0x5555555550c2: c7 45 fc 00 00 00 00 eb 13 8b 05 d4 2e 00 00 83
[displaced] displaced_step_prepare_throw: prepared successfully thread=Thread 0x7ffff75a5640 (LWP 2289301), original_pc=0x5555555551bd, displaced_pc=0x5555555550c2
[displaced] resume_1: run 0x5555555550c2: c7 45 fc 00
[infrun] infrun_async: enable=1
[infrun] prepare_to_wait: prepare_to_wait
[infrun] start_step_over: [Thread 0x7ffff75a5640 (LWP 2289301)] was resumed.
[infrun] operator(): step-over queue now empty
[infrun] start_step_over: exit
[infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop
[infrun] proceed: resuming Thread 0x7ffff7da7740 (LWP 2289296)
[infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [Thread 0x7ffff7da7740 (LWP 2289296)] at 0x7ffff7f7d9b7
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: resuming Thread 0x7ffff7da6640 (LWP 2289300)
[infrun] resume_1: thread Thread 0x7ffff7da6640 (LWP 2289300) has pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP (currently_stepping=0).
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: [Thread 0x7ffff75a5640 (LWP 2289301)] resumed
[infrun] proceed: resuming Thread 0x7ffff6da4640 (LWP 2289302)
[infrun] resume_1: thread Thread 0x7ffff6da4640 (LWP 2289302) has pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP (currently_stepping=0).
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop
[infrun] proceed: exit
We can easily see where the call to `proceed` starts and end. We can
also see why there are a bunch of resume_1 calls, it's because we are
resuming threads, emulating all-stop on top of a non-stop target.
We also see that debug statements nest well with other modules that have
been migrated to use the "new" debug statement helpers (because they all
use debug_prefixed_vprintf in the end. I think this is desirable, for
example we could see the debug statements about reading the DWARF info
of a library nested under the debug statements about loading that
library.
Of course, modules that haven't been migrated to use the "new" helpers
will still print without indentations. This will be one good reason to
migrate them.
I think the runtime cost (when debug statements are disabled) of this is
reasonable, given the improvement in readability. There is the cost of
the conditionals (like standard debug statements), one more condition
(if (m_must_decrement_print_depth)) and the cost of constructing a stack
object, which means copying a fews pointers.
Adding the print in fetch_inferior_event breaks some tests that use "set
debug infrun", because it prints a debug statement after the prompt. I
adapted these tests to cope with it, by using the "-prompt" switch of
gdb_test_multiple to as if this debug statement is part of the expected
prompt. It's unfortunate that we have to do this, but I think the debug
print is useful, and I don't want a few tests to get in the way of
adding good debug output.
gdbsupport/ChangeLog:
* common-debug.h (debug_print_depth): New.
(struct scoped_debug_start_end): New.
(scoped_debug_start_end): New.
(scoped_debug_enter_exit): New.
* common-debug.cc (debug_prefixed_vprintf): Print indentation.
gdb/ChangeLog:
* debug.c (debug_print_depth): New.
* infrun.h (INFRUN_SCOPED_DEBUG_START_END): New.
(INFRUN_SCOPED_DEBUG_ENTER_EXIT): New.
* infrun.c (start_step_over): Use
INFRUN_SCOPED_DEBUG_ENTER_EXIT.
(proceed): Use INFRUN_SCOPED_DEBUG_ENTER_EXIT and
INFRUN_SCOPED_DEBUG_START_END.
(fetch_inferior_event): Use INFRUN_SCOPED_DEBUG_ENTER_EXIT.
gdbserver/ChangeLog:
* debug.cc (debug_print_depth): New.
gdb/testsuite/ChangeLog:
* gdb.base/ui-redirect.exp: Expect infrun debug print after
prompt.
* gdb.threads/ia64-sigill.exp: Likewise.
* gdb.threads/watchthreads-reorder.exp: Likewise.
Change-Id: I7c3805e6487807aa63a1bae318876a0c69dce949
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.
When inserting hw watchpoints, we take care of masking off the top byte
of the address (and sign-extending it if needed). This guarantees we won't
pass tagged addresses to the kernel via ptrace.
However, from the kernel documentation on tagged pointers...
"Non-zero tags are not preserved when delivering signals. This means that
signal handlers in applications making use of tags cannot rely on the tag
information for user virtual addresses being maintained for fields inside
siginfo_t.
One exception to this rule is for signals raised in response to watchpoint
debug exceptions, where the tag information will be preserved."
So the stopped data address after a hw watchpoint hit can be potentially
tagged, and we don't handle this in GDB at the moment. This results in
GDB missing a hw watchpoint hit and attempting to step over an unsteppable
hw watchpoint, causing it to spin endlessly.
The following patch fixes this by adjusting the stopped data address and adds
some tests to expose the problem.
gdb/ChangeLog:
2020-12-16 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-nat.c
(aarch64_linux_nat_target::stopped_data_address): Handle the TBI.
gdbserver/ChangeLog:
2020-12-16 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-low.cc (address_significant): New function.
(aarch64_target::low_stopped_data_address): Handle the TBI.
gdb/testsuite/ChangeLog:
2020-12-16 Luis Machado <luis.machado@linaro.org>
* gdb.arch/aarch64-tagged-pointer.c (main): Add a few more
pointer-based memory accesses.
* gdb.arch/aarch64-tagged-pointer.exp: Exercise additional
hw watchpoint cases.
Make use of the safe-ctype replacements for the standard ctype
character checking functions in gdbsupport/common-utils.cc. The
gdbsupport library is included into both gdb and gdbserver, and on the
gdbserver side there are two targets, gdbserver itself, and also
libinproctrace.so.
libiberty was already being included in the gdbserver link command,
but was missing from the libinproctrace.so link. As a result, after
changing gdbsupport/common-utils.cc to depend on libiberty,
libinproctrace.so would no longer link until I modified its link line.
gdbserver/ChangeLog:
* Makefile.in (IPA_LIB): Include libiberty library.
gdbsupport/ChangeLog:
* gdbsupport/common-utils.cc: Change 'ctype.h' include to
'safe-ctype.h'.
(extract_string_maybe_quoted): Use safe-ctype function versions.
(is_digit_in_base): Likewise.
(digit_to_int): Likewise.
(strtoulst): Likewise.
(skip_spaces): Likewise.
(skip_to_space): Likewise.
The help text for the --disable-packet option was missing one of the
possible values.
As this option is for maintainers only it is explicitly not documented
in gdb/doc/gdb.texinfo, so no update is needed there.
gdbserver/ChangeLog:
* server.cc (gdbserver_usage): Add missing option to usage text.
(gdbserver_show_disableable): Likewise.
... with AC_COMPILE_IFELSE and AC_LANG_PROGRAM.
All changes in the generated configure file are insignificant
whitespace changes.
gdbserver/ChangeLog:
* acinclude.m4: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE +
AC_LANG_PROGRAM.
* configure: Re-generate.
Change-Id: Idab8b5e1a984046b5283940c02e5a22da2291d58
For some reason, autoupdate isn't able to grok ptrace.m4:
$ autoupdate ptrace.m4
/usr/bin/m4:/tmp/auYjuodw/input.m4:171: ERROR: end of file in string
autoupdate: /usr/bin/m4 failed with exit status: 1
Honestly, I'm unable to grok it either. This patch re-indents it in a
way that I think is easier to read. With this patch applied, autoupdate
becomes able to parse ptrace.m4, but I chose to keep this re-indent in a
patch of its own.
All the changes in generated configure files consist of insignificant
whitespace changes.
gdb/ChangeLog:
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
* ptrace.m4: Re-indent.
Change-Id: Ie2afab09fecc8b6d0cccccb47ac9756f3843881e
Run autoupdate on gdbserver/configure.ac and then tweak it to use easier
to read indentation. This removes a few warnings when running
`autoreconf -vf -Wall`.
* Replace AC_INIT with AC_INIT and no arguments plus AC_CONFIG_SRCDIR.
* Replace AC_GNU_SOURCE with AC_USE_SYSTEM_EXTENSIONS.
* Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE.
* Replace AC_TRY_LINK with AC_LINK_IFELSE.
autoupdate gets it right, except this one here:
--- a/gdbserver/configure.ac
+++ b/gdbserver/configure.ac
@@ -304,7 +304,7 @@ if test "$srv_linux_thread_db" = "yes"; then
AC_LINK_IFELSE([AC_LANG_PROGRAM([[]], [[]])],[found="-Wl,--dynamic-list"
RDYNAMIC='-Wl,--dynamic-list=$(srcdir)/proc-service.list'],[RDYNAMIC="-rdynamic"
LDFLAGS="$old_LDFLAGS $RDYNAMIC"
- AC_TRY_LINK([], [],
+ _au_m4_changequote([,])AC_TRY_LINK([], [],
[found="-rdynamic"],
[found="no"
RDYNAMIC=""])])
... which I had to convert manually.
The changes in the generated configure file only contain insignificant
whitespace changes, so that gives confidence that the conversion is
correct.
gdbserver/ChangeLog:
* configure.ac: Modernize.
* configure: Re-generate.
Change-Id: Ia769aaec2aafac595504f477da955e91dffa4d8f
`autoreconf -Wall` notes that AC_CANONICAL_SYSTEM is obsolete:
configure.ac:36: warning: The macro `AC_CANONICAL_SYSTEM' is obsolete.
Replace it by AC_CANONICAL_BUILD, AC_CANONICAL_HOST and
AC_CANONICAL_TARGET in configure.ac files in gdb, gdbserver and
gdbsupport. All three macros may not be needed everywhere, but it is
hard to completely audit the configure files to see which are required,
so I think it's better (and that there's no downside) to just call all
three.
gdb/ChangeLog:
* configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of
AC_CANONICAL_SYSTEM.
* configure: Re-generate.
gdbserver/ChangeLog:
* configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of
AC_CANONICAL_SYSTEM.
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of
AC_CANONICAL_SYSTEM.
* configure: Re-generate.
Change-Id: Ifd0e21f1e478634e768b5de1b8ee06a7f690d863
This eliminates the need to specify the return type when using
handle_eintr. We let the compiler deduce it for us.
Also, use lowercase for function parameter names. Uppercase should
only be used on template parameters.
gdb/ChangeLog:
* nat/linux-waitpid.c: Include "gdbsupport/eintr.h".
(my_waitpid): Use gdb::handle_eintr.
gdbserver/ChangeLog:
* netbsd-low.cc (netbsd_waitpid, netbsd_process_target::kill)
(netbsd_qxfer_libraries_svr4): Use gdb::handle_eintr without
explicit type.
gdbsupport/ChangeLog:
* eintr.h (handle_eintr): Replace Ret template parameter with
ErrorValType. Use it as type of the failure value. Deduce the
function's return type using decltype. Use lowercase for function
parameter names.
ptrace.m4, providing the GDB_AC_PTRACE autoconf macro, is used by gdb,
gdbserver and gdbsupport. I think it would make sense to move it to
gdbsupport.
gdb/ChangeLog:
* acinclude.m4: Update ptrace.m4 path.
* ptrace.m4: Moved to gdbsupport.
gdbserver/ChangeLog:
* acinclude.m4: Update ptrace.m4 path.
gdbsupport/ChangeLog:
* Makefile.in: Re-generate.
* acinclude.m4: Update ptrace.m4 path.
* ptrace.m4: Move here.
Change-Id: I849c149fd5dd8c3b2b0af38654fb353e3727871b
I get this diff when I re-generate the configure script in gdbserver,
probably leftovers from e911c6663b ("Require kinfo_get_file and
kinfo_get_vmmap for FreeBSD hosts").
gdbserver/ChangeLog:
* config.in: Re-generate.
* configure: Re-generate.
Change-Id: Id19a72ea9f3e7c7b4fdb0f319c9c0bbad0e39aeb
While trying to build on Cygwin (gcc 10.2.0), I got:
CXX server.o
/home/Baube/src/binutils-gdb/gdbserver/server.cc: In function 'void handle_general_set(char*)':
/home/Baube/src/binutils-gdb/gdbserver/server.cc:832:12: error: 'sprintf' argument 3 overlaps destination object 'own_buf' [-Werror=restrict]
832 | sprintf (own_buf, "E.Unknown thread-events mode requested: %s\n",
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
833 | mode);
| ~~~~~
/home/Baube/src/binutils-gdb/gdbserver/server.cc:553:27: note: destination object referenced by 'restrict'-qualified argument 1 was declared here
553 | handle_general_set (char *own_buf)
| ~~~~~~^~~~~~~
There is indeed a problem: mode points somewhere into own_buf. And by
the time mode gets formatted as a %s, whatever it points to has been
overwritten. I hacked gdbserver to coerce it into that error path, and
this is the resulting message:
(gdb) p own_buf
$1 = 0x629000000200 "E.Unknown thread-events mode requested: ad-events mode requested: 00;10:9020fdf7ff7f0000;thread:p49388.49388;core:e;\n"
Fix it by formatting the error string in an std::string first.
gdbserver/ChangeLog:
* server.cc (handle_general_set): Don't use sprintf with
argument overlapping buffer.
Change-Id: I4fdf05c0117f63739413dd67ddae7bd6ee414824
PR gdb/26742 points out some undefined behavior in gdbserver. The bug
is that remove_thread does:
free_one_thread (thread);
if (current_thread == thread)
current_thread = NULL;
However, the equality check is undefined, because "thread" has already
been freed.
This patch fixes the bug by moving the check earlier.
Tested on x86-64 Fedora 32.
2020-10-20 Tom Tromey <tromey@adacore.com>
PR gdb/26742:
* inferiors.cc (remove_thread): Clear current_thread before
freeing the thread.
Currently it does not add any value.
The netbsd_tdesc local variable is no longer needed. Remove it.
The tdesc value is set by the low target now.
gdbserver/ChangeLog:
* netbsd-low.cc (netbsd_tdesc): Remove.
(netbsd_add_process): Likewise.
(netbsd_process_target::create_inferior): Update.
After commit:
commit 51a948fdf0
Date: Mon Jul 20 14:18:04 2020 +0100
gdb: Have allocate_target_description return a unique_ptr
There were a few places where we could (should?) have delayed
releasing the target_desc_up until a little later. This commit
catches these cases.
In the case of ARC, the target_desc_up is now exposed right out to
gdbserver, which means making a small change there too.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* arch/aarch32.c (aarch32_create_target_description): Release the
target_desc_up as late as possible.
* arch/aarch64.c (aarch64_create_target_description): Likewise.
* arch/amd64.c (amd64_create_target_description): Likewise.
* arch/arc.c (arc_create_target_description): Return a
target_desc_up, don't release it.
* arch/arc.h (arc_create_target_description): Update declaration.
(arc_lookup_target_description): Move target_desc_up into the
cache, and return a borrowed pointer.
* arch/arm.c (arm_create_target_description): Release the
target_desc_up as late as possible.
* arch/i386.c (i386_create_target_description): Likewise.
* arch/riscv.h (riscv_create_target_description): Update
declaration to match definition.
* arch/tic6x.c (tic6x_create_target_description): Release the
target_desc_up as late as possible.
gdbserver/ChangeLog:
* linux-arc-low.cc (arc_linux_read_description): Release the
unique_ptr returned from arc_create_target_description.
An issue was reported here related to building GDB on MinGW:
https://sourceware.org/pipermail/gdb/2020-September/048927.html
It was suggested here:
https://sourceware.org/pipermail/gdb/2020-September/048931.html
that the solution might be to make use of $(LIB_GETRANDOM), a variable
defined in the gnulib makefile, when linking GDB.
In fact I think the issue is bigger than just LIB_GETRANDOM. When
using the script binutils-gdb/gnulib/update-gnulib.sh to reimport
gnulib there is a lot of output from gnulib's gnulib-tool. Part of
that output is this:
You may need to use the following makefile variables when linking.
Use them in <program>_LDADD when linking a program, or
in <library>_a_LDFLAGS or <library>_la_LDFLAGS when linking a library.
$(FREXPL_LIBM)
$(FREXP_LIBM)
$(INET_NTOP_LIB)
$(LIBTHREAD)
$(LIB_GETLOGIN)
$(LIB_GETRANDOM)
$(LIB_HARD_LOCALE)
$(LIB_MBRTOWC)
$(LIB_SETLOCALE_NULL)
$(LTLIBINTL) when linking with libtool, $(LIBINTL) otherwise
What I think this is telling us is that we should be including the
value of all these variables on the link line for gdb and gdbserver.
The problem though is that these variables are define in gnulib's
makefile, but are not (necessarily) defined in GDB's makefile.
One solution would be to recreate the checks that gnulib performs in
order to recreate these variables in both gdb's and gdbserver's
makefile. Though this shouldn't be too hard, most (if not all) of
these checks are in the form macros defined in m4 files in the gnulib
tree, so we could just reference these as needed. However, in this
commit I propose a different solution.
Currently, in the top level makefile, we give gdb and gdbserver a
dependency on gnulib. Once gnulib has finished building gdb and
gdbserver can start, these projects then have a hard coded (relative)
path to the compiled gnulib library in their makefiles.
In this commit I extend the gnulib configure script to install a new
makefile fragment in the gnulib build directory. This new file will
have the usual variable substitutions applied to it, and so can
include the complete list (see above) of all the extra libraries that
are needed when linking against gnulib.
In fact the new makefile fragment defines three variables, these are:
LIBGNU: The path to the archive containing gnulib. Can be used as a
dependency as when this file changes gdb/gdbserver should be
relinked.
LIBGNU_EXTRA_LIBS: A list of linker -l.... flags that should be
included in the link line of gdb/gdbserver. These are
libraries that $(LIBGNU) depends on. This list is taken from
the output of gnulib-tool, which is run by our
gnulib/update-gnulib.sh script.
INCGNU: A list of -I.... include paths that should be passed to the
compiler, these are where the gnulib headers can be found.
Now both gdb and gdbserver can include the makefile fragment and make
use of these variables.
The makefile fragment relies on the variable GNULIB_BUILDDIR being
defined. This is checked for in the fragment, and was already defined
in the makefiles of gdb and gdbserver.
gdb/ChangeLog:
* Makefile.in: Include Makefile.gnulib.inc. Don't define LIBGNU
or INCGNU. Make use of LIBGNU_EXTRA_LIBS when linking.
gdbserver/ChangeLog:
* Makefile.in: Include Makefile.gnulib.inc. Don't define LIBGNU
or INCGNU. Make use of LIBGNU_EXTRA_LIBS when linking.
gnulib/ChangeLog:
* Makefile.gnulib.inc.in: New file.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Install the new file.
handle_search_memory had some code after a call to error. This code
is dead, and this patch removes it.
gdbserver/ChangeLog
2020-10-07 Tom Tromey <tromey@adacore.com>
* server.cc (handle_search_memory): Remove dead code.
This replaces gdbserver's memory-searching function with
simple_search_memory.
gdbserver/ChangeLog
2020-10-07 Tom Tromey <tromey@adacore.com>
* server.cc (handle_search_memory_1): Remove.
(handle_search_memory): Use simple_search_memory.
GDB currently doesn't build cleanly with clang (a -Wdeprecated-copy-dtor
error). I configured my clang-based GDB build with
CXXFLAGS="-Wno-error=deprecated-copy-dtor", so I can use it despite that
problem. However, I found that it had no effect. This is because my
-Wno-error=Wdeprecated-copy-dtor switch is followed by -Werror in the
command line, which switches back all warnings to be errors.
If we want the user-supplied C(XX)FLAGS to be able to override flags
added by our configure script, the user-supplied C(XX)FLAGS should
appear after the configure-supplied flags.
This patch moves the user-supplied CXXFLAGS at the very end of the
compilation command line, which fixes the problem described above. This
means moving it out of INTERNAL_CFLAGS and inlining it in the users of
INTERNAL_CFLAGS.
I observed the problem when building GDB, but the same problem could
happen with GDBserver, so the change is done there too.
In GDBserver, INTERNAL_CFLAGS is passed when linking
gdb/ChangeLog:
* Makefile.in (COMPILE): Add CXXFLAGS.
(INTERNAL_CFLAGS_BASE): Remove CXXFLAGS.
(check-headers): Add CXXFLAGS.
gdbserver/ChangeLog:
* Makefile.in (COMPILE): Add CXXFLAGS.
(INTERNAL_CFLAGS_BASE): Remove CXXFLAGS.
(gdbserver$(EXEEXT)): Add CXXFLAGS.
(gdbreplay$(EXEEXT)): Add CXXFLAGS.
($(IPA_LIB)): Add CXXFLAGS.
(IPAGENT_COMPILE): Add CXXFLAGS.
Change-Id: I00e054506695e0e9536095c6d14827e48abd8f69
The support is on par with NetBSD/amd64, thus GPR works,
single step and software breakpoint are operational, and the
SVR4 r_debug integration is functional.
gdbserver/ChangeLog:
* netbsd-aarch64-low.cc: Add.
* Makefile.in (SFILES): Register "netbsd-aarch64-low.c".
* configure.srv: Add aarch64*-*-netbsd*.
Becausae of a copy/paste, I've put myself as the author of the
following patch which was not true:
6d2d7c5668 gdbserver: Add GNU/Linux support for ARC
This change will place the correct date and author in the ChangeLog.
This gdbserver implementation supports ARC ABI v3 and v4 (older ARC ABI
versions are not supported by other modern GNU tools or Linux itself).
Gdbserver supports inspection of ARC HS registers R30, R58 and R59 - feature
that has been added to Linux 4.12. Whether gdbserver build will actually
support this feature depends on the version of Linux headers used to build
the server.
v2 [1]:
- Use "this->read_memory ()" instead of "the_target->read_memory ()".
- Remove the unnecessary "arch-arc.o:" target from the "Makefile.in".
- Got rid of "ntohs()" function and added lots of comments about
endianness.
- Clarify why "pc" value is read from and saved to different fields
in user regs struct.
- In function "is_reg_name_available_p()", use a range-based iterator
to loop over the registers.
- Removed mentioning of issue number that was not related to sourceware.
- A few typo's fixed.
[1] Remarks
https://sourceware.org/pipermail/gdb-patches/2020-September/171911.htmlhttps://sourceware.org/pipermail/gdb-patches/2020-September/171919.html
gdbserver/ChangeLog:
* configure.srv: Support ARC architecture.
* Makefile.in: Add linux-arc-low.cc and arch/arc.o.
* linux-arc-low.cc: New file.
Switch from target->read_memory to netbsd_nat::read_memory and
cleanup the code.
No functional change.
gdbserver/ChangeLog:
* netbsd-low.cc (get_dynamic, get_r_debug, read_one_ptr)
(netbsd_qxfer_libraries_svr4): Remove "target" argument and update.
(netbsd_process_target::qxfer_libraries_svr4): Update.
Instead of sharing the native-only code with all BSDs with slightly
different semantics of the kernels, share the NetBSD-only behavior beteen
the NetBSD native and gdbserver setup.
NetBSD does not differentiate the address space I and D in the
operations (contrary to OpenBSD). NetBSD handles EACCES that integrates
with NetBSD specific PaX MPROTECT error handling.
Add a verbose message in the native client that an operation could be
cancelled due to PaX MPROTECT setup.
gdb/ChangeLog:
* nat/netbsd-nat.c (write_memory, read_memory): Add.
* nat/netbsd-nat.h (write_memory, read_memory): Likewise.
* nbsd-nat.c (nbsd_nat_target::xfer_partial): Update.
gdbserver/ChangeLog:
* netbsd-low.cc (netbsd_process_target::read_memory)
(netbsd_process_target::write_memory): Update.
The support is on par with NetBSD/amd64, thus GPR works,
single step and software breakpoint are operational, and the
SVR4 r_debug integration is functional.
gdbserver/ChangeLog:
* netbsd-aarch64-low.cc: Add.
* Makefile.in (SFILES): Register "netbsd-aarch64-low.c".
* configure.srv: Add aarch64*-*-netbsd*.
The support is on par with NetBSD/amd64, thus GPR works,
single step and software breakpoint are operational, and the
SVR4 r_debug integration is functional.
gdbserver/ChangeLog:
* netbsd-aarch64-low.cc: Add.
* Makefile.in (SFILES): Register "netbsd-aarch64-low.c".
* configure.srv: Add aarch64*-*-netbsd*.
The register_data() function in gdbserver/regcache.cc has an
input argument called "fetch". This argument is not used by this
static function at all. Therefore, it is time to get rid of it.
gdbserver/ChangeLog:
* regcache.cc (register_data): Remove unused "fetch" argument.
Assign names to event loop file handlers. They will be used in debug
messages when file handlers are invoked.
In GDB, each UI used to get its own unique number, until commit
cbe256847e ("Remove ui::num"). Re-introduce this field, and use it to
make a unique name for the handler.
I'm not too sure what goes on in ser-base.c, all I know is that it's
what is used when debugging remotely. I've just named the main handler
"serial". It would be good to have unique names there too. For instance
when debugging with two different remote connections, we'd ideally want
the handlers to have unique names. I didn't do it in this patch though.
gdb/ChangeLog:
* async-event.c (initialize_async_signal_handlers): Pass name to
add_file_handler
* event-top.c (ui_register_input_event_handler): Likewise.
* linux-nat.c (linux_nat_target::async): Likewise.
* run-on-main-thread.c (_initialize_run_on_main_thread):
Likewise
* ser-base.c (reschedule): Likewise.
(ser_base_async): Likewise.
* tui/tui-io.c: Likewise.
* top.h (struct ui) <num>: New field.
* top.c (highest_ui_num): New variable.
(ui::ui): Initialize num.
gdbserver/ChangeLog:
* linux-low.cc (linux_process_target::async): Pass name to
add_file_handler.
* remote-utils.cc (handle_accept_event): Likewise.
(remote_open): Likewise.
gdbsupport/ChangeLog:
* event-loop.h (add_file_handler): Add "name" parameter.
* event-loop.cc (struct file_handler) <name>: New field.
(create_file_handler): Add "name" parameter, assign it to file
handler.
(add_file_handler): Add "name" parameter.
Change-Id: I9f1545f73888ebb6778eb653a618ca44d105f92c
The support is on part with NetBSD/amd64, thus GPR works,
single step and software breakpoint are operational, and the
SVR4 r_debug integration is functional.
gdbserver/ChangeLog:
* netbsd-i386-low.cc: Add.
* Makefile.in (SFILES): Register "netbsd-i386-low.c".
* configure.srv: Add i[34567]86-*-netbsd*.
Replace the pre-C++ construct of netbsd_target_ops, netbsd_regset_info
and netbsd_tdesc with C++ inheritance approach found in the Linux
gdbserver code. Add netbsd_amd64_target, that inherits from the
netbsd_process_target class and add proper singleton object for
the_netbsd_target, initialized from netbsd_amd64_target.
Call low_arch_setup () on post process creation, which sets machine
specific properties of the traced process.
Remove global singleton the_netbsd_target object from the generic
gdbserver code.
This refactoring introduces no functional change from the end-user
point of view.
gdbserver/ChangeLog:
* netbsd-amd64-low.cc (netbsd_x86_64_arch_setup): Remove.
(netbsd_target_regsets): Now const.
(the_low_target): Remove.
(class netbsd_amd64_target, the_netbsd_amd64_target)
(the_netbsd_target): Add.
* netbsd-low.cc (netbsd_process_target::post_create_inferior): Call
low_arch_setup ().
(netbsd_process_target::fetch_registers)
(netbsd_process_target::store_registers, initialize_low): Update.
(the_netbsd_target): Remove.
* netbsd-low.h (netbsd_target_regsets, netbsd_target_ops)
(the_low_target, netbsd_tdesc): Remove.
(netbsd_process_target::get_regs_info)
(netbsd_process_target::low_arch_setup): Add.
When a WOW64 process triggers a breakpoint exception in 64bit code (which
happens when a 64bit gdb calls DebugBreakProcess for a 32bit target),
gdb ignores the breakpoint (because Wow64GetThreadContext can only report
the pc of 32bit code, and there is not int3 at this location).
But if these 64bit breakpoint exceptions are handled as SIGINT, gdb
doesn't check for int3, and always stops the target.
gdb/ChangeLog:
2020-09-23 Hannes Domani <ssbssa@yahoo.de>
* nat/windows-nat.c (handle_exception): Handle 64bit breakpoints
in WOW64 processes as SIGINT.
* nat/windows-nat.h: Make wow64_process a shared variable.
* windows-nat.c: Remove static wow64_process variable.
gdbserver/ChangeLog:
2020-09-23 Hannes Domani <ssbssa@yahoo.de>
* win32-low.cc: Remove local wow64_process variable.
* win32-low.h: Remove local wow64_process variable.
My understanding is that it's mildly better to use a static const
array, as opposed to a "const char *", for a global string constant,
when possible. This makes sense to me because the pointer requires a
load from an address, whereas the array is just the address.
So, I searched for these in gdb and gdbserver. This patch fixes the
ones I found.
gdb/ChangeLog
2020-09-15 Tom Tromey <tromey@adacore.com>
* unittests/memory-map-selftests.c (valid_mem_map): Now array.
* ui-style.c (ansi_regex_text): Now array.
* rust-exp.y (number_regex_text): Now array.
* linespec.c (linespec_quote_characters): Now array.
* jit.c (jit_break_name, jit_descriptor_name, reader_init_fn_sym):
Now arrays.
gdbserver/ChangeLog
2020-09-15 Tom Tromey <tromey@adacore.com>
* linux-x86-low.cc (xmltarget_i386_linux_no_xml)
(xmltarget_amd64_linux_no_xml): Now arrays.
Many global arrays in gdb could be marked "const" but are not. This
patch changes some of them. (There may be other arrays that could
benefit from this treatment. I only examined arrays of strings.)
This lets the linker move some symbols to the readonly data section.
For example, previously:
0000000000000000 d _ZL18can_use_agent_enum
is now:
0000000000000030 r _ZL18can_use_agent_enum
2020-09-14 Tom Tromey <tromey@adacore.com>
* x86-tdep.h (x86_in_indirect_branch_thunk): Update.
* x86-tdep.c (x86_is_thunk_register_name)
(x86_in_indirect_branch_thunk): Update.
* sparc64-tdep.c (sparc64_fpu_register_names)
(sparc64_cp0_register_names, sparc64_register_names)
(sparc64_pseudo_register_names): Now const.
* sparc-tdep.h (struct gdbarch_tdep) <fpu_register_names,
cp0_registers_num>: Now const.
* sparc-tdep.c (sparc_core_register_names)
(sparc32_fpu_register_names, sparc32_cp0_register_names)
(sparc32_pseudo_register_names): Now const.
(validate_tdesc_registers): Update.
* rust-lang.c (rust_extensions): Now const.
* p-lang.c (p_extensions): Now const.
* objc-lang.c (objc_extensions): Now const.
* nto-tdep.c (nto_thread_state_str): Now const.
* moxie-tdep.c (moxie_register_names): Now const.
* mips-tdep.h (struct gdbarch_tdep) <mips_processor_reg_names>:
Now const.
* mips-tdep.c (mips_generic_reg_names, mips_tx39_reg_names)
(mips_linux_reg_names): Now const.
(mips_gdbarch_init): Update.
* microblaze-tdep.c (microblaze_register_names): Now const.
* m68k-tdep.c (m68k_register_names): Now const.
* m32r-tdep.c (m32r_register_names): Now const.
* ia64-tdep.c (ia64_register_names): Now const.
* i386-tdep.h (struct gdbarch_tdep) <register_names,
ymmh_register_names, ymm16h_regnum, mpx_register_names,
k_register_names, zmmh_register_names, xmm_avx512_register_names,
ymm_avx512_register_names, pkeys_register_names>: Now const.
* i386-tdep.c (i386_register_names, i386_zmm_names)
(i386_zmmh_names, i386_k_names, i386_ymm_names, i386_ymmh_names)
(i386_mpx_names, i386_pkeys_names, i386_bnd_names)
(i386_mmx_names, i386_byte_names, i386_word_names): Now const.
* f-lang.c (f_extensions): Now const.
* d-lang.c (d_extensions): Now const.
* csky-tdep.c (csky_register_names): Now const.
* charset.c (default_charset_names, charset_enum): Now const.
(_initialize_charset): Update.
* c-lang.c (c_extensions, cplus_extensions, asm_extensions): Now
const.
* bsd-uthread.c (bsd_uthread_solib_names): Now const.
(bsd_uthread_solib_loaded): Update.
(bsd_uthread_state): Now const.
* amd64-tdep.c (amd64_register_names, amd64_ymm_names)
(amd64_ymm_avx512_names, amd64_ymmh_names)
(amd64_ymmh_avx512_names, amd64_mpx_names, amd64_k_names)
(amd64_zmmh_names, amd64_zmm_names, amd64_xmm_avx512_names)
(amd64_pkeys_names, amd64_byte_names, amd64_word_names)
(amd64_dword_names): Now const.
* agent.c (can_use_agent_enum): Now const.
* ada-tasks.c (task_states, long_task_states): Now const.
* ada-lang.c (known_runtime_file_name_patterns)
(known_auxiliary_function_name_patterns, attribute_names)
(standard_exc, ada_extensions): Now const.
gdbserver/ChangeLog
2020-09-14 Tom Tromey <tromey@adacore.com>
* tracepoint.cc (eval_result_names): Now const.
* ax.cc (gdb_agent_op_names): Now const.
I found myself wanting to run a few specific selftests while developing.
I thought it would be nice to be able to provide multiple test names
when running `maintenant selftests`. The arguments to that command is
currently interpreted as a single filter (not split by spaces), it now
becomes a list a filters, split by spaces. A test is executed when it
matches at least one filter.
Here's an example of the result in GDB:
(gdb) maintenance selftest xml
Running selftest xml_escape_text.
Running selftest xml_escape_text_append.
Ran 2 unit tests, 0 failed
(gdb) maintenance selftest xml unord
Running selftest unordered_remove.
Running selftest xml_escape_text.
Running selftest xml_escape_text_append.
Ran 3 unit tests, 0 failed
(gdb) maintenance selftest xml unord foobar
Running selftest unordered_remove.
Running selftest xml_escape_text.
Running selftest xml_escape_text_append.
Ran 3 unit tests, 0 failed
Since the selftest machinery is also shared with gdbserver, I also
adapted gdbserver. It accepts a `--selftest` switch, which accepts an
optional filter argument. I made it so you can now pass `--selftest`
multiple time to add filters.
It's not so useful right now though: there's only a single selftest
right now in GDB and it's for an architecture I can't compile. So I
tested by adding dummy tests, here's an example of the result:
$ ./gdbserver --selftest=foo
Running selftest foo.
foo
Running selftest foobar.
foobar
Ran 2 unit tests, 0 failed
$ ./gdbserver --selftest=foo --selftest=bar
Running selftest bar.
bar
Running selftest foo.
foo
Running selftest foobar.
foobar
Ran 3 unit tests, 0 failed
gdbsupport/ChangeLog:
* selftest.h (run_tests): Change parameter to array_view.
* selftest.c (run_tests): Change parameter to array_view and use
it.
gdb/ChangeLog:
* maint.c (maintenance_selftest): Split args and pass array_view
to run_tests.
gdbserver/ChangeLog:
* server.cc (captured_main): Accept multiple `--selftest=`
options. Pass all `--selftest=` arguments to run_tests.
Change-Id: I422bd49f08ea8095ae174c5d66a2dd502a59613a
GDB currently doesn't build on 32-bit Solaris:
* On Solaris 11.4/x86:
In file included from /usr/include/sys/procfs.h:26,
from /vol/src/gnu/gdb/hg/master/dist/gdb/i386-sol2-nat.c:24:
/usr/include/sys/old_procfs.h:31:2: error: #error "Cannot use procfs in the large file compilation environment"
#error "Cannot use procfs in the large file compilation environment"
^~~~~
* On Solaris 11.3/x86 there are several more instances of this.
The interaction between procfs and large-file support historically has
been a royal mess on Solaris:
* There are two versions of the procfs interface:
** The old ioctl-based /proc, deprecated and not used any longer in
either gdb or binutils.
** The `new' (introduced in Solaris 2.6, 1997) structured /proc.
* There are two headers one can possibly include:
** <procfs.h> which only provides the structured /proc, definining
_STRUCTURED_PROC=1 and then including ...
** <sys/procfs.h> which defaults to _STRUCTURED_PROC=0, the ioctl-based
/proc, but provides structured /proc if _STRUCTURED_PROC == 1.
* procfs and the large-file environment didn't go well together:
** Until Solaris 11.3, <sys/procfs.h> would always #error in 32-bit
compilations when the large-file environment was active
(_FILE_OFFSET_BITS == 64).
** In both Solaris 11.4 and Illumos, this restriction was lifted for
structured /proc.
So one has to be careful always to define _STRUCTURED_PROC=1 when
testing for or using <sys/procfs.h> on Solaris. As the errors above
show, this isn't always the case in binutils-gdb right now.
Also one may need to disable large-file support for 32-bit compilations
on Solaris. config/largefile.m4 meant to do this by wrapping the
AC_SYS_LARGEFILE autoconf macro with appropriate checks, yielding
ACX_LARGEFILE. Unfortunately the macro doesn't always succeed because
it neglects the _STRUCTURED_PROC part.
To make things even worse, since GCC 9 g++ predefines
_FILE_OFFSET_BITS=64 on Solaris. So even if largefile.m4 deciced not to
enable large-file support, this has no effect, breaking the gdb build.
This patch addresses all this as follows:
* All tests for the <sys/procfs.h> header are made with
_STRUCTURED_PROC=1, the definition going into the various config.h
files instead of having to make them (and sometimes failing) in the
affected sources.
* To cope with the g++ predefine of _FILE_OFFSET_BITS=64,
-U_FILE_OFFSET_BITS is added to various *_CPPFLAGS variables. It had
been far easier to have just
#undef _FILE_OFFSET_BITS
in config.h, but unfortunately such a construct in config.in is
commented by config.status irrespective of indentation and whitespace
if large-file support is disabled. I found no way around this and
putting the #undef in several global headers for bfd, binutils, ld,
and gdb seemed way more invasive.
* Last, the applicability check in largefile.m4 was modified only to
disable largefile support if really needed. To do so, it checks if
<sys/procfs.h> compiles with _FILE_OFFSET_BITS=64 defined. If it
doesn't, the disabling only happens if gdb exists in-tree and isn't
disabled, otherwise (building binutils from a tarball), there's no
conflict.
What initially confused me was the check for $plugins here, which
originally caused the disabling not to take place. Since AC_PLUGINGS
does enable plugin support if <dlfcn.h> exists (which it does on
Solaris), the disabling never happened.
I could find no explanation why the linker plugin needs large-file
support but thought it would be enough if gld and GCC's lto-plugin
agreed on the _FILE_OFFSET_BITS value. Unfortunately, that's not
enough: lto-plugin uses the simple-object interface from libiberty,
which includes off_t arguments. So to fully disable large-file
support would mean also disabling it in libiberty and its users: gcc
and libstdc++-v3. This seems highly undesirable, so I decided to
disable the linker plugin instead if large-file support won't work.
The patch allows binutils+gdb to build on i386-pc-solaris2.11 (both
Solaris 11.3 and 11.4, using GCC 9.3.0 which is the worst case due to
predefined _FILE_OFFSET_BITS=64). Also regtested on
amd64-pc-solaris2.11 (again on Solaris 11.3 and 11.4),
x86_64-pc-linux-gnu and i686-pc-linux-gnu.
config:
* largefile.m4 (ACX_LARGEFILE) <sparc-*-solaris*|i?86-*-solaris*>:
Check for <sys/procfs.h> incompatilibity with large-file support
on Solaris.
Only disable large-file support and perhaps plugins if needed.
Set, substitute LARGEFILE_CPPFLAGS if so.
bfd:
* bfd.m4 (BFD_SYS_PROCFS_H): New macro.
(BFD_HAVE_SYS_PROCFS_TYPE): Require BFD_SYS_PROCFS_H.
Don't define _STRUCTURED_PROC.
(BFD_HAVE_SYS_PROCFS_TYPE_MEMBER): Likewise.
* elf.c [HAVE_SYS_PROCFS_H] (_STRUCTURED_PROC): Don't define.
* configure.ac: Use BFD_SYS_PROCFS_H to check for <sys/procfs.h>.
* configure, config.in: Regenerate.
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in, doc/Makefile.in: Regenerate.
binutils:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in, doc/Makefile.in: Regenerate.
* configure: Regenerate.
gas:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in, doc/Makefile.in: Regenerate.
* configure: Regenerate.
gdb:
* proc-api.c (_STRUCTURED_PROC): Don't define.
* proc-events.c: Likewise.
* proc-flags.c: Likewise.
* proc-why.c: Likewise.
* procfs.c: Likewise.
* Makefile.in (INTERNAL_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* configure, config.in: Regenerate.
gdbserver:
* configure, config.in: Regenerate.
gdbsupport:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* common.m4 (GDB_AC_COMMON): Use BFD_SYS_PROCFS_H to check for
<sys/procfs.h>.
* Makefile.in: Regenerate.
* configure, config.in: Regenerate.
gnulib:
* configure.ac: Run ACX_LARGEFILE before gl_EARLY.
* configure: Regenerate.
gprof:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in: Regenerate.
* configure: Regenerate.
ld:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in: Regenerate.
* configure: Regenerate.
The original configure-time tests in gdb/ and gdbserver/ failed to
detect that 'socklen_t' is defined in MinGW headers because the test
program included only sys/socket.h, which is absent in MinGW system
headers. However on MS-Windows this data type is declared in another
header, ws2tcpip.h. The modified test programs try using ws2tcpip.h
if sys/socket.h is unavailable.
Thanks to Joel Brobecker who helped me regenerate the configure
scripts and the config.in files.
gdb/ChangeLog:
2020-07-26 Eli Zaretskii <eliz@gnu.org>
* configure.ac (AC_CHECK_HEADERS): Check for sys/socket.h and
ws2tcpip.h. When checking whether socklen_t type is defined, use
ws2tcpip.h if it is available and sys/socket.h isn't.
* configure: Regenerate.
* config.in: Regenerate.
gdbserver/ChangeLog:
2020-07-26 Eli Zaretskii <eliz@gnu.org>
* configure.ac (AC_CHECK_HEADERS): Add ws2tcpip.h.
When checking whether socklen_t type is defined, use ws2tcpip.h if
it is available and sys/socket.h isn't.
* configure: Regenerate.
* config.in: Regenerate.
On some systems, the gdb.multi/multi-target.exp testcase occasionally
fails like so:
Running src/gdb/testsuite/gdb.multi/multi-target.exp ...
FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 1: info connections
FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 1: info inferiors
FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 2: info connections
FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 2: info inferiors
FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 3: inferior 3
... many more cascading fails.
The problem starts when the testcase runs an inferior against GDBserver:
(gdb) run
Starting program: build/gdb/testsuite/outputs/gdb.multi/multi-target/multi-target
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading /lib64/ld-2.31.so from remote target...
Reading /lib64/.debug/ld-2.31.so from remote target...
Reading /usr/lib/debug//lib64/ld-2.31.so from remote target...
Reading /usr/lib/debug/lib64//ld-2.31.so from remote target...
Reading target:/usr/lib/debug/lib64//ld-2.31.so from remote target...
Reading /lib/x86_64-linux-gnu/libpthread.so.0 from remote target...
Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target...
Reading /lib/x86_64-linux-gnu/libc-2.31.so from remote target...
Reading /lib/x86_64-linux-gnu/.debug/libc-2.31.so from remote target...
Reading /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so from remote target...
Reading /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so from remote target...
Remote connection closed
...
Note the "Remote connection closed" message. That means GDBserver
exited abruptly.
I traced it down to the fact that GDB fetches the thread list from
GDBserver while the main thread of the process is still running. On
my main system where I wrote the testcase, I have not observed the
failure because it is slow enough that the thread stops before
GDBserver fetches the thread list in the problem scenario which I'll
describe below.
With some --remote-debug logging from GDBserver side, we see the last
packets before the connection closes:
...
getpkt ("vCont;c"); [no ack sent]
putpkt ("$OK#9a"); [noack mode]
getpkt ("Tp10f9a.10f9a"); [no ack sent]
putpkt ("$OK#9a"); [noack mode]
getpkt ("Hgp0.0"); [no ack sent]
putpkt ("$OK#9a"); [noack mode]
getpkt ("qXfer:threads:read::0,1000"); [no ack sent]
Note the vCont;c , which sets the program running, and then a
qXfer:threads:read packet at the end.
The problem happens when the thread list refresh (qXfer:threads:read)
is sent just while the main thread is running and it still hasn't
initialized its libpthread id internally. In that state, the main
thread's lwp will remain with the thread_known flag clear. See in
find_one_thread:
/* If the new thread ID is zero, a final thread ID will be available
later. Do not enable thread debugging yet. */
if (ti.ti_tid == 0)
return 0;
Now, back in server.cc, to handle the qXfer:threads:read, we reach
handle_qxfer_threads -> handle_qxfer_threads_proper, and the latter
then calls handle_qxfer_threads_worker for each known thread. In
handle_qxfer_threads_worker, we call target_thread_handle. This ends
up in thread_db_thread_handle, here:
if (!lwp->thread_known && !find_one_thread (thread->id))
return false;
Since the thread ID isn't known yet, we call find_one_thread. This
calls into libthread_db.so, which accesses memory. Because the
current thread is running, that fails and we throw an error, here:
/* Get information about this thread. */
err = thread_db->td_ta_map_lwp2thr_p (thread_db->thread_agent, lwpid, &th);
if (err != TD_OK)
error ("Cannot get thread handle for LWP %d: %s",
lwpid, thread_db_err_str (err));
The current design is that whenever GDB-facing packets/requests need
to accesses memory, server.cc is supposed to prepare the target for
the access. See gdb_read_memory / gdb_write_memory. This preparation
means pausing threads if in non-stop mode (someday we could lift this
requirement, but we will still need to pause to access registers or do
other related ptrace accesses like PTRACE_GET_THREAD_AREA). Note that
the multi-target.exp testcase forces "maint set target-non-stop on".
So the fix here is to prepare the target to access memory when
handling qXfer:threads:read too.
gdbserver/ChangeLog:
* inferiors.cc (switch_to_process): New, moved here from
thread-db.cc, and made extern.
* inferiors.h (switch_to_process): Declare.
* server.cc: Include "gdbsupport/scoped_restore.h".
(handle_qxfer_threads_proper): Now returns bool. Prepare to
access memory around target calls.
(handle_qxfer_threads): Handle errors.
* thread-db.cc (switch_to_process): Moved to inferiors.cc.
I noticed that my IDE was confusing the two stopped_pids variables.
There is one in GDB and one in GDBserver. They should be static, make
them so.
gdb/ChangeLog:
* linux-nat.c (stopped_pids): Make static.
gdbserver/ChangeLog:
* linux-low.cc (stopped_pids): Make static.
Change-Id: If4a2bdcd45d32eb3a732d266a0f686a4e4c23672
It was pointed out on IRC that the RISC-V target allocates target
descriptions and stores them in a global map, and doesn't delete these
target descriptions when GDB shuts down.
This isn't a particular problem, the total number of target
descriptions we can create is very limited so creating these on demand
and holding them for the entire run on GDB seems reasonable.
However, not deleting these objects on GDB exit means extra warnings
are printed from tools like valgrind, and the address sanitiser,
making it harder to spot real issues. As it's reasonably easy to have
GDB correctly delete these objects on exit, lets just do that.
I started by noticing that we already have a target_desc_up type, a
wrapper around unique_ptr that calls a function that will correctly
delete target descriptions, so I want to use that, but....
...that type is declared in gdb/target-descriptions.h. If I try to
include that file in gdb/arch/riscv.c I run into a problem, that file
is compiled into both GDB and GDBServer.
OK, I could guard the include with #ifdef, but surely we can do
better.
So then I decided to move the target_desc_up type into
gdbsupport/tdesc.h, this is the interface file for generic code shared
between GDB and GDBserver (relating to target descriptions). The
actual implementation for the delete function still lives in
gdb/target-description.c, but now gdb/arch/riscv.c can see the
declaration. Problem solved....
... but, though RISC-V doesn't use it I've now exposed the
target_desc_up type to gdbserver, so in future someone _might_ start
using it, which is fine, except right now there's no definition of the
delete function - remember the delete I used is only defined in GDB
code.
No problem, I add an implementation of the delete operator into
gdbserver/tdesc.cc, and all is good..... except....
I start getting this error from GCC:
tdesc.cc:109:10: error: deleting object of polymorphic class type ‘target_desc’ which has non-virtual destructor might cause undefined behavior [-Werror=delete-non-virtual-dtor]
Which is caused because gdbserver's target_desc type inherits from
tdesc_element which has a virtual method, and so GCC worries that
target_desc might be used as a base class.
The solution is to declare gdbserver's target_desc class as final.
This is fine so long as we never intent to inherit from
target_desc (in gdbserver). But if we did then we'd want to make
target_desc's destructor virtual anyway, so the error above would be
resolved, and there wouldn't be an issue.
gdb/ChangeLog:
* arch/riscv.c (riscv_tdesc_cache): Change map type.
(riscv_lookup_target_description): Return pointer out of
unique_ptr.
* target-descriptions.c (allocate_target_description): Add
comment.
(target_desc_deleter::operator()): Likewise.
* target-descriptions.h (struct target_desc_deleter): Moved to
gdbsupport/tdesc.h.
(target_desc_up): Likewise.
gdbserver/ChangeLog:
* tdesc.cc (allocate_target_description): Add header comment.
(target_desc_deleter::operator()): New function.
* tdesc.h (struct target_desc): Declare as final.
gdbsupport/ChangeLog:
* tdesc.h (struct target_desc_deleter): Moved here
from gdb/target-descriptions.h, extend comment.
(target_desc_up): Likewise.
When building gdbserver with AddressSanitizer, I get this annoying
little leak when gdbserver exits:
==307817==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 14 byte(s) in 1 object(s) allocated from:
#0 0x7f7fd4256459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x563bef981b80 in xmalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:60
#2 0x563befb53301 in xstrdup /home/simark/src/binutils-gdb/libiberty/xstrdup.c:34
#3 0x563bef9d742b in handle_query /home/simark/src/binutils-gdb/gdbserver/server.cc:2286
#4 0x563bef9ed0b7 in process_serial_event /home/simark/src/binutils-gdb/gdbserver/server.cc:4061
#5 0x563bef9f1d9e in handle_serial_event(int, void*) /home/simark/src/binutils-gdb/gdbserver/server.cc:4402
#6 0x563befb0ec65 in handle_file_event /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:548
#7 0x563befb0f49f in gdb_wait_for_event /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:673
#8 0x563befb0d4a1 in gdb_do_one_event() /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:215
#9 0x563bef9e721a in start_event_loop /home/simark/src/binutils-gdb/gdbserver/server.cc:3484
#10 0x563bef9eb90a in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3875
#11 0x563bef9ec2c7 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:3961
#12 0x7f7fd3330001 in __libc_start_main (/usr/lib/libc.so.6+0x27001)
SUMMARY: AddressSanitizer: 14 byte(s) leaked in 1 allocation(s).
This is due to the handling of unknown qsupported features in
handle_query. The `qsupported` vector is built, containing all the
feature names received from GDB. As we iterate on them, when we
encounter unknown ones, we move them at the beginning of the vector, in
preparation of passing this vector of unknown features down to the
target (which may know about them).
When moving these unknown features to other slots in the vector, we
overwrite other pointers without freeing them, which therefore leak.
An easy fix would be to add a `free` when doing the move. However, I
think this is a good opportunity to sprinkle a bit of automatic memory
management in this code.
So, use a vector of std::string which owns all the entries. And use a
separate vector (that doesn't own the entries) for the unknown ones,
which is then passed to target_process_qsupported.
Given that the `c_str` method of std::string returns a `const char *`,
it follows that process_stratum_target::process_qsupported must accept a
`const char **` instead of a `char **`. And while at it, change the
pointer + size paramters to use an array_view instead.
gdbserver/ChangeLog:
* server.cc (handle_query): Use std::vector of
std::string for `qsupported` vector. Use separate
vector for unknowns.
* target.h (class process_stratum_target) <process_qsupported>:
Change parameters to array_view of const char *.
(target_process_qsupported): Remove `count` parameter.
* target.cc (process_stratum_target::process_qsupported): Change
parameters to array_view of const char *.
* linux-x86-low.cc (class x86_target) <process_qsupported>:
Likewise.
Change-Id: I97f133825faa6d7abbf83a58504eb0ba77462812
The file gdbserver/ax.h contains:
...
#ifdef IN_PROCESS_AGENT
#define debug_threads debug_agent
#endif
...
but does not declare debug_agent.
Fix this by adding an include of gdbsupport/agent.h.
[ If this fix would have been in place before commit 8118159c69 "[gdbserver] Fix
Wlto-type-mismatch for debug_agent", we would have simply run into this build
breaker with a regular, non-lto build:
...
src/gdbserver/ax.cc:28:5: error: conflicting declaration 'int debug_agent'
int debug_agent = 0;
^~~~~~~~~~~
In file included from src/gdbserver/ax.h:25:0,
from src/gdbserver/ax.cc:20:
src/gdbsupport/agent.h:47:13: note: previous declaration as 'bool debug_agent'
extern bool debug_agent;
^~~~~~~~~~~
... ]
Tested on x86_64-linux.
gdbserver/ChangeLog:
2020-06-29 Tom de Vries <tdevries@suse.de>
* ax.h: Include gdbsupport/debug_agent.h.
The gdbsupport directory contains a helper class print_xml_feature
that is shared between gdb and gdbserver. This class is used for
printing an XML representation of a target_desc object.
Currently this class doesn't have the ability to print the
<compatible> entities that can appear within a target description, I
guess no targets have needed that functionality yet.
The print_xml_feature classes API is based around operating on the
target_desc class, however, the sharing between gdb and gdbserver is
purely textural, we rely on their being a class called target_desc in
both gdb and gdbserver, but there is no shared implementation. We
then have a set of functions declared that operate on an object of
type target_desc, and again these functions have completely separate
implementations.
Currently then the gdb version of target_desc contains a vector of
bfd_arch_info pointers which represents the compatible entries from a
target description. The gdbserver version of target_desc has no such
information. Further, the gdbserver code doesn't seem to include the
bfd headers, and so doesn't know about the bfd types.
I was reluctant to include the bfd headers into gdbserver just so I
can reference the compatible information, which isn't (currently) even
needed in gdbserver.
So, the approach I take in this patch is to wrap the compatible
information into a new helper class. This class is declared in the
gdbsupport library, but implemented separately in both gdb and
gdbserver.
In gdbserver the class is empty. The compatible information within
the gdbserver is an empty list, of empty classes.
In gdb the class contains a pointer to the bfd_arch_info object.
With this in place we can now add support to print_xml_feature for
printing the compatible information if it is present. In the
gdbserver code this will never happen, as the gdbserver never has any
compatible information. But in gdb, this code will trigger when
appropriate.
gdb/ChangeLog:
* target-descriptions.c (class tdesc_compatible_info): New class.
(struct target_desc): Change type of compatible vector.
(tdesc_compatible_p): Update for change in type of
target_desc::compatible.
(tdesc_compatible_info_list): New function.
(tdesc_compatible_info_arch_name): New function.
(tdesc_add_compatible): Update for change in type of
target_desc::compatible.
(print_c_tdesc::visit_pre): Likewise.
gdbserver/ChangeLog:
* tdesc.cc (struct tdesc_compatible_info): New struct.
(tdesc_compatible_info_list): New function.
(tdesc_compatible_info_arch_name): New function.
gdbsupport/ChangeLog:
* tdesc.cc (print_xml_feature::visit_pre): Print compatible
information.
* tdesc.h (struct tdesc_compatible_info): Declare new struct.
(tdesc_compatible_info_up): New typedef.
(tdesc_compatible_info_list): Declare new function.
(tdesc_compatible_info_arch_name): Declare new function.
Use std::list to store pending signals instead of a manually-managed
linked list. This is a refactoring.
In the existing code, pending signals are kept in a manually-created
linked list with "prev" pointers. A new pending signal is thus
inserted to the beginning of the list. When consuming, GDB goes until
the end of the list, following the "prev" pointers, and processes the
final item. With this patch, a new item is added to the end of the
list and the item at the front of the list is consumed. In other
words, the list elements used to be stored in reverse order; with this
patch, they are stored in their order of arrival. This causes a change
in the debug messages that print the pending signals. Otherwise, no
behavioral change is expected.
gdbserver/ChangeLog:
2020-06-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Use std::list to stop pending signal instead of manually-created
linked list.
* linux-low.h: Include <list>.
(struct pending_signal): Move here from linux-low.cc.
(struct lwp_info) <pending_signals>
<pending_signals_to_report>: Update the type.
* linux-low.cc (struct pending_signals): Remove.
(linux_process_target::delete_lwp)
(linux_process_target::add_lwp)
(enqueue_one_deferred_signal)
(dequeue_one_deferred_signal)
(enqueue_pending_signal)
(linux_process_target::resume_one_lwp_throw)
(linux_process_target::thread_needs_step_over)
(linux_process_target::resume_one_thread)
(linux_process_target::proceed_one_lwp): Update the use of pending
signal list.
This patch removes the leftover regformats .dat files for the arm
architecture. There are no longer relevant, since the arm architecture
has been converted to use feature-based target-descriptions. These .dat
files are used by GDBserver ports that still use static target
descriptions.
These .dat files are generated from corresponding .xml files in the
features directory. And since the corresponding .xml files for these
arm .dat files don't exist anymore, it is impossible to re-generated
them. If you delete these .dat files and type "make" in the features
directory, you'll get:
make: *** No rule to make target '../regformats/arm/arm-with-iwmmxt.dat', needed by 'all'. Stop.
So it removes the entries in the `WHICH` variable of
gdb/features/Makefile.
Finally, it removes the rule in gdbserver/Makefile to generate .cc files
from `../gdb/regformats/arm/%.dat`.
gdb/ChangeLog:
* features/Makefile (WHICH): Remove arm files.
* regformats/arm/arm-with-iwmmxt.dat: Remove.
* regformats/arm/arm-with-neon.dat: Remove.
* regformats/arm/arm-with-vfpv2.dat: Remove.
* regformats/arm/arm-with-vfpv3.dat: Remove.
gdbserver/ChangeLog:
* Makefile.in (%-generated.cc: ../gdb/regformats/arm/%.dat):
Remove.
Change-Id: I3b7d989c50e2cb92235c1f7c7071a26839d84c78
This port has been unmaintained for years and the upstream Linux kernel
does not support this architecture anymore, remove it.
gdbserver/ChangeLog:
* Makefile.in (SFILES): linux-tile-low.cc.
* configure.srv: Remove tilegx case.
* linux-tile-low.cc: Remove.
Change-Id: I1c2910d04ddbd6013e5d228047106b41d80f9477
This port has been unmaintained for years and the upstream Linux kernel
does not support this architecture anymore, remove it.
gdbserver/ChangeLog:
* Makefile.in (SFILES): Remove linux-m32r-low.cc.
* configure.srv: Remove m32r case.
* linux-m32r-low.cc: Remove.
Change-Id: I5617b2b1fd92aeec19b38e0e3c0b78adaafdb35b
This port has been unmaintained for years and the upstream Linux kernel
does not support this architecture anymore, remove it.
gdbserver/ChangeLog:
* Makefile.in (SFILES): Remove linux-cris-low.c.
* configure.srv: Remove cris cases.
* linux-cris-low.cc, linux-crisv32-low.cc: Remove.
Change-Id: Ib3ff436b03373548215f15540a47f39cbec5f512
This port has been unmaintained for years and the upstream Linux kernel
does not support this architecture anymore, remove it.
gdbserver/ChangeLog:
* Makefile.in (SFILES): Remove linux-bfin-low.c.
* configure.srv: Remove bfin case.
* linux-bfin-low.cc: Remove.
* linux-low.cc: Remove BFIN-conditional code.
Change-Id: I846310d15e6386118ec7eabb1b87e647174560fb
This port has been unmaintained for years, remove it.
gdbserver/ChangeLog:
* configure: Re-generate.
* configure.ac: Remove srv_qnx test.
* configure.srv: Remove nto case.
* nto-low.cc, nto-low.h, nto-x86-low.cc: Remove.
* remote-utils.c: Remove __QNX__-guarded code.
Change-Id: I8a1ad9c740a69352da1f6993778dbf951eebb22f
This port has been unmaintained for years, remove it.
gdbserver/ChangeLog:
* configure: Re-generate.
* configure.ac: Remove srv_lynxos test.
* configure.srv: Remove lynxos cases.
* lynx-i386-low.cc, lynx-low.cc, lynx-low.h, lynx-ppc-low.c:
Remove.
Change-Id: I239d1cf1fc7b4c7a174251bc7981707eaba7d972
Fix a few outdated or incoherent things in the README:
- Don't mention remote.c nor *-stub.c files as references for the remote
protocol. remote.c is in GDB, not GDBserver, and *-stub.c files don't
exist today. Add a link to the documentation instead.
- In the "server (target) side" section, use `:2345` instead of
`host:2345`. It currently says that using `host:2345` means we would
expect a connection from `host`. That's not what I would expect by
passing a host part here. If I passed `11.22.33.44:2345` as the listen
address, I would expect it to instruct gdbserver to listen only on that
(11.22.33.44) network interface, not to expect a connection from host
`11.22.33.44`. So, remove that part of the sentence.
- Remove the list of supported target, refer to configure.srv instead.
Keeping a list here is bound to lose sync with reality.
- In the cross-compile instructions, I don't think it's necessary to mention
"In a Bourne shell".
- In the cross-compile instructions, I don't know what passing
`your-target-name` to configure does, I don't think it's valid. Use
`make all-gdbserver` as in the instructions just above.
gdbserver/ChangeLog:
* README: Fix a few outdated or incoherent things.
Change-Id: I79349e25bc1bc53447855e0dea6cc7b9630f4553
When building gdb including gdbserver with CFLAGS/CXXFLAGS -O2 -g -flto=auto,
I run into:
...
src/gdbserver/../gdbsupport/agent.h:47:13: error: type of 'debug_agent' \
does not match original declaration [-Werror=lto-type-mismatch]
extern bool debug_agent;
^
src/gdbserver/ax.cc:28:5: note: type 'int' should match type 'bool'
int debug_agent = 0;
^
src/gdbserver/ax.cc:28:5: note: 'debug_agent' was previously declared here
src/gdbserver/ax.cc:28:5: note: code may be misoptimized unless \
-fno-strict-aliasing is used
...
Fix this by changing the type of debug_agent in ax.cc from int to bool.
Tested on x86_64-linux.
Only the process handle returned by OpenProcess or CreateProcess needs to
be closed, the one provided by WaitForDebugEvent is closed automatically.
gdbserver/ChangeLog:
2020-05-27 Hannes Domani <ssbssa@yahoo.de>
* win32-low.cc (do_initial_child_stuff): Set open_process_used.
(win32_clear_inferiors): Use open_process_used.
(get_child_debug_event): Likewise.
Use the construct_inferior_arguments function instead of
stringify_argv to construct a string from the program
arguments in those places where that one is then passed
to fork_inferior (linux-low, lyn-low), since
construct_inferior_arguments properly takes care of
special characters, while stringify_argv does not.
Using construct_inferior_arguments seems "natural", since its
documentation also mentions that it "does the
same shell processing as fork_inferior".
Since construct_inferior_args has been extended to do
proper quoting for Windows shells in commit
5d60742e2d
("Fix quoting of special characters for the MinGW build.",
2012-06-12), use it for the Windows case as well.
(I could not test that case myself, though.)
Adapt handling of empty args in function 'handle_v_run'
in gdbserver/server.cc to just insert an empty string
for an empty arg, since that one is now properly handled
in 'construct_inferior_arguments' already (and inserting
a "''" string in 'handle_v_run' would otherwise
cause that one to be treated as a string literally
containing two quote characters, which
'construct_inferior_args' would preserve by adding
extra escaping).
This makes gdbserver properly handle program args containing special
characters (like spaces), e.g. (example from PR25893)
$ gdbserver localhost:50505 myprogram "hello world"
now properly handles "hello world" as a single arg, not two separate
ones ("hello", "world").
gdbserver/ChangeLog:
PR gdbserver/25893
* linux-low.cc (linux_process_target::create_inferior),
lynx-low.cc (lynx_process_target::create_inferior),
win32-low.cc (win32_process_target::create_inferior): Use
construct_inferior_arguments instead of stringify_argv
to get string representation which properly escapes
special characters.
* server.cc (handle_v_run): Just pass empty program arg
as such, since any further processing is now handled via
construct_inferior_arguments.
Change-Id: Ibf963fcd51415c948840fb463289516b3479b0c3
According to [1], the fifth parameter
to the 'spawnp' function is 'char * const argv[]',
so just pass the args contained in the vector as
an array right away, rather than converting that
to a C string first and passing that one.
With commit 2090129c36
("Share fork_inferior et al with gdbserver",
2016-12-22) the type had changed from 'char **'
to 'char *', but I can't see an apparent reason for
that, and 'nto_procfs_target::create_inferior'
(in gdb/nto-procfs.c) also passes a 'char **' to
'spawnp' instead.
I do not know much about that target and cannot actually
test this, however.
The main motivation to look at this was identifying
and replacing the remaining uses of the 'stringify_argv'
function which does not properly do escaping.
[1] http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.lib_ref/topic/s/spawnp.html
gdbserver/ChangeLog:
* nto-low.cc (nto_process_target::create_inferior): Pass
argv to spawnp function as char **.
Change-Id: Ic46fe745c2aa1118114240d149d4156032f84344
The vector holding the program args is passed as a parameter
to target_create_inferior, which then passes it to
stringify_argv for all platforms, where any NULL entry in
the vector is ignored, so there seems to be no reason
to actually add one after all.
(Since the intention is to replace uses of stringify_argv with
construct_inferior_arguments in a follow-up commit and that
function doesn't currently handle such NULL arguments, it
would otherwise have to be extended.)
gdbserver/ChangeLog:
* server.cc (captured_main), (handle_v_run): No longer
insert extra NULL element to args vector.
Change-Id: Ia2ef6d36814a6b11ce8b0d6e3b33248a7945e825
This patch avoids depending on the current locale when parsing &
comparing symbol names, by using libiberty's safe-ctype.h uppercase
TOLOWER, ISXDIGIT, etc. macros instead of the standard ctype.h
tolower, isxdigit, etc. macros/functions.
This commit:
commit b1b60145ae
Author: Pedro Alves <palves@redhat.com>
AuthorDate: Tue May 22 17:35:38 2018 +0100
Support UTF-8 identifiers in C/C++ expressions (PR gdb/22973)
did something similar, except in the expression parser.
This can improve GDB's symbol loading performance significantly.
Currently strcmp_iw_ordered can show up high on profiles (called from
sort_pst_symbols -> std::sort) because of the isspace and tolower
functions. Hannes mentions seeing it as high as in ~24% of the
profiling samples on Windows
(https://sourceware.org/pipermail/gdb-patches/2020-May/168858.html).
I tested GDB's performance (built with "-g -O2") loading a "-g -O0"
build of gdb.
I ran GDB 10 times like:
/bin/time -f %e \
./gdb/gdb --data-directory ./gdb/data-directory -nx \
-batch /tmp/gdb-g-O0
Then I computed the mean time.
The baseline mean time was
gdb 2.515
This patch brings the number down to
gdb 2.096
Which is an around 16% improvement.
gdb/ChangeLog:
2020-05-23 Pedro Alves <palves@redhat.com>
* utils.c: Include "gdbsupport/gdb-safe-ctype.h".
(parse_escape): Use ISDIGIT instead of isdigit.
(puts_debug): Use gdb_isprint instead of isprint.
(fprintf_symbol_filtered): Use ISALNUM instead of isalnum.
(cp_skip_operator_token, skip_ws, strncmp_iw_with_mode): Use
ISSPACE instead of isspace.
(strncmp_iw_with_mode): Use TOLOWER instead of tolower and ISSPACE
instead of isspace.
(strcmp_iw_ordered): Use ISSPACE instead of isspace.
(string_to_core_addr): Use TOLOWER instead of tolower, ISXDIGIT
instead of isxdigit and ISDIGIT instead of isdigit.
gdbsupport/ChangeLog:
2020-05-23 Pedro Alves <palves@redhat.com>
* gdb-safe-ctype.h: New.
During the gdbserver c++'ification refactoring, I apparently made a
typo that broke build in ia64 targets.
gdbserver/ChangeLog:
2020-05-16 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* linux-ia64-low.cc (ia64_target::sw_breakpoint_from_kind):
Fix incorrect 'gdb_assert_no_reached' to 'gdb_assert_not_reached'.
(ia64_target::low_breakpoint_at): Ditto.
When trying to use hardware breakpoints with gdbserver you get this error:
(gdb) hbreak main
Hardware assisted breakpoint 2 at 0x40162d: file gdb-9493.c, line 5.
(gdb) c
Continuing.
Warning:
Cannot insert hardware breakpoint 2.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
It turns out the respective types just needed to be added to the
appropriate callback functions, because x86_dr_(insert|remove)_watchpoint
already handles them.
gdbserver/ChangeLog:
2020-05-15 Hannes Domani <ssbssa@yahoo.de>
* win32-i386-low.cc (i386_supports_z_point_type): Handle
Z_PACKET_HW_BP z_type.
(i386_insert_point): Handle raw_bkpt_type type.
(i386_remove_point): Likewise.
I recently stumbled on this code mentioning Linux kernel 2.6.25, and
thought it could be time for some spring cleaning (newer GDBs probably
don't need to supports 12-year old kernels). I then found that the
"legacy" case is probably broken anyway, which gives an even better
motivation for its removal.
In short, this patch removes the configure checks that check if
user_regs_struct contains the fs_base/gs_base fields and adjusts all
uses of the HAVE_STRUCT_USER_REGS_STRUCT_{FS,GS}_BASE macros. The
longer explanation/rationale follows.
Apparently, Linux kernels since 2.6.25 (that's from 2008) have been
reliably providing fs_base and gs_base as part of user_regs_struct.
Commit df5d438e33d7 in the Linux kernel [1] seems related. This means
that we can get these values by reading registers with PTRACE_GETREGS.
Previously, these values were obtained using a separate
PTRACE_ARCH_PRCTL ptrace call.
First, I'm not even sure the configure check was really right in the
first place.
The user_regs_struct used by GDB comes from
/usr/include/x86_64-linux-gnu/sys/user.h (or equivalent on other
distros) and is provided by glibc. glibc has had the fs_base/gs_base
fields in there for a very long time, at least since this commit from
2001 [2]. The Linux kernel also has its version of user_regs_struct,
which I think was exported to user-space at some point. It included the
fs_base/gs_base fields since at least this 2002 commit [3]. In any
case, my conclusion is that the fields were there long before the
aforementioned Linux kernel commit. The kernel commit didn't add these
fields, it only made sure that they have reliable values when obtained
with PTRACE_GETREGS.
So, checking for the presence of the fs_base/gs_base fields in struct
user_regs_struct doesn't sound like a good way of knowing if we can
reliably get the fs_base/gs_base values from PTRACE_GETREGS. My guess
is that if we were using that strategy on a < 2.6.25 kernel, things
would not work correctly:
- configure would find that the user_regs_struct has the fs_base/gs_base
fields (which are probided by glibc anyway)
- we would be reading the fs_base/gs_base values using PTRACE_GETREGS,
for which the kernel would provide unreliable values
Second, I have tried to see how things worked by forcing GDB to not use
fs_base/gs_base from PTRACE_GETREGS (forcing it to use the "legacy"
code, by configuring with
ac_cv_member_struct_user_regs_struct_gs_base=no ac_cv_member_struct_user_regs_struct_fs_base=no
Doing so breaks writing registers back to the inferior. For example,
calling an inferior functions gives an internal error:
(gdb) p malloc(10)
/home/smarchi/src/binutils-gdb/gdb/i387-tdep.c:1408: internal-error: invalid i387 regnum 152
The relevant last frames where this error happens are:
#8 0x0000563123d262fc in internal_error (file=0x563123e93fd8 "/home/smarchi/src/binutils-gdb/gdb/i387-tdep.c", line=1408, fmt=0x563123e94482 "invalid i387 regnum %d") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55
#9 0x0000563123047d0d in i387_collect_xsave (regcache=0x5631269453f0, regnum=152, xsave=0x7ffd38402a20, gcore=0) at /home/smarchi/src/binutils-gdb/gdb/i387-tdep.c:1408
#10 0x0000563122c69e8a in amd64_collect_xsave (regcache=0x5631269453f0, regnum=152, xsave=0x7ffd38402a20, gcore=0) at /home/smarchi/src/binutils-gdb/gdb/amd64-tdep.c:3448
#11 0x0000563122c5e94c in amd64_linux_nat_target::store_registers (this=0x56312515fd10 <the_amd64_linux_nat_target>, regcache=0x5631269453f0, regnum=152) at /home/smarchi/src/binutils-gdb/gdb/amd64-linux-nat.c:335
#12 0x00005631234c8c80 in target_store_registers (regcache=0x5631269453f0, regno=152) at /home/smarchi/src/binutils-gdb/gdb/target.c:3485
#13 0x00005631232e8df7 in regcache::raw_write (this=0x5631269453f0, regnum=152, buf=0x56312759e468 "@\225\372\367\377\177") at /home/smarchi/src/binutils-gdb/gdb/regcache.c:765
#14 0x00005631232e8f0c in regcache::cooked_write (this=0x5631269453f0, regnum=152, buf=0x56312759e468 "@\225\372\367\377\177") at /home/smarchi/src/binutils-gdb/gdb/regcache.c:778
#15 0x00005631232e75ec in regcache::restore (this=0x5631269453f0, src=0x5631275eb130) at /home/smarchi/src/binutils-gdb/gdb/regcache.c:283
#16 0x0000563123083fc4 in infcall_suspend_state::restore (this=0x5631273ed930, gdbarch=0x56312718cf20, tp=0x5631270bca90, regcache=0x5631269453f0) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:9103
#17 0x0000563123081eed in restore_infcall_suspend_state (inf_state=0x5631273ed930) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:9151
The problem seems to be that amd64_linux_nat_target::store_registers
calls amd64_native_gregset_supplies_p to know whether gregset provides
fs_base. When !HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE,
amd64_native_gregset_supplies_p returns false. store_registers
therefore assumes that it must be an "xstate" register. This is of
course wrong, and that leads to the failed assertion when
i387_collect_xsave doesn't recognize the register.
amd64_linux_nat_target::store_registers could probably be fixed to
handle this case, but I don't think it's worth it, given that it would
only be to support very old kernels.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df5d438e33d7fc914ba9b6e0d6b019a8966c5fcc
[2] https://sourceware.org/git/?p=glibc.git;a=commit;h=c9cf6ddeebb7bb
[3] https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=88e4bc32686ebd0b1111a94f93eba2d334241f68
gdb/ChangeLog:
* configure.ac: Remove check for fs_base/gs_base in
user_regs_struct.
* configure: Re-generate.
* config.in: Re-generate.
* amd64-nat.c (amd64_native_gregset_reg_offset): Adjust.
* amd64-linux-nat.c (amd64_linux_nat_target::fetch_registers,
amd64_linux_nat_target::store_registers, ps_get_thread_area, ): Adjust.
gdbserver/ChangeLog:
* configure.ac: Remove check for fs_base/gs_base in
user_regs_struct.
* configure: Re-generate.
* config.in: Re-generate.
* linux-x86-low.cc (x86_64_regmap, x86_fill_gregset,
x86_store_gregset): Adjust.
If the search area is bigger than SEARCH_CHUNK_SIZE (16000), then you get
an error in gdbserver:
gdb: (gdb) find /w 0x3c43f0,+20000,0x04030201
gdb: Pattern not found.
gdbserver: Unable to access 3997 bytes of target memory at 0x3c8273, halting search.
The return value of any additional gdb_read_memory calls were compared with the
wrong value, this fixes it.
gdbserver/ChangeLog:
2020-04-22 Hannes Domani <ssbssa@yahoo.de>
* server.cc (handle_search_memory_1): Fix gdb_read_memory return value
comparison.
Simon pointed out that the windows-nat sharing series broke the Cygwin
build. This patch fixes the problem, by moving the Cygwin-specific
code to a new handler function. This approach is taken because this
code calls find_pc_partial_function, which isn't available in
gdbserver.
gdb/ChangeLog
2020-04-16 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat::handle_access_violation): New
function.
* nat/windows-nat.h (handle_access_violation): Declare.
* nat/windows-nat.c (handle_exception): Move Cygwin code to
windows-nat.c. Call handle_access_violation.
gdbserver/ChangeLog
2020-04-16 Tom Tromey <tromey@adacore.com>
* win32-low.cc (windows_nat::handle_access_violation): New
function.
When compiling on Cygwin, we get:
CXX win32-low.o
/home/smarchi/src/binutils-gdb/gdbserver/win32-low.cc: In function ‘int get_child_debug_event(DWORD*, target_waitstatus*)’:
/home/smarchi/src/binutils-gdb/gdbserver/win32-low.cc:1459:17: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long int’ [-Werror=format=]
1459 | OUTMSG2 (("get_windows_debug_event - "
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
1460 | "unexpected stop in 0x%x (expecting 0x%x)\n",
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1461 | ptid.lwp (), desired_stop_thread_id));
| ~~~~~~~~~~~
| |
| long int
/home/smarchi/src/binutils-gdb/gdbserver/win32-low.cc:52:11: note: in definition of macro ‘OUTMSG2’
52 | printf X; \
| ^
/home/smarchi/src/binutils-gdb/gdbserver/win32-low.cc:1460:26: note: format string is defined here
1460 | "unexpected stop in 0x%x (expecting 0x%x)\n",
| ~^
| |
| unsigned int
| %lx
`ptid.lwp ()` is a `long` value, so it indeed needs the `l` size modifier.
gdbserver/ChangeLog:
* win32-low.cc (get_child_debug_event): Fix format string warning.
event-loop.c requires the client to provide some functions. This
patch implements these functions for gdbserver.
gdbserver/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* server.c (invoke_async_signal_handlers)
(check_async_event_handlers, flush_streams, gdb_select): New
functions.
gdb_select.h and the event loop require some configure checks, so this
moves the needed checks to common.m4 and updates the configure
scripts.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* configure.ac: Remove checks that are now in GDB_AC_COMMON.
gdbserver/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* config.in: Rebuild.
gdbsupport/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* config.in, configure: Rebuild.
* common.m4 (GDB_AC_COMMON): Check for poll.h, sys/poll.h,
sys/select.h, and poll.
This changes gdbserver to also handle pending stops, the same way that
gdb does. This is PR gdb/22992.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
PR gdb/22992
* win32-low.c (child_continue): Call matching_pending_stop.
(get_child_debug_event): Call fetch_pending_stop. Push pending
stop when needed.
This changes the Windows gdbserver port to implement the
stopped_by_sw_breakpoint target method. This is needed to support
pending stops.
This is a separate patch now, because Pedro suggested splitting it out
for simpler bisecting, in the case that it introduces a bug.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.h (win32_process_target::stopped_by_sw_breakpoint)
(win32_process_target::supports_stopped_by_sw_breakpoint):
Declare.
* win32-low.c (win32_supports_z_point_type): Always handle
Z_PACKET_SW_BP.
(win32_insert_point): Call insert_memory_breakpoint when needed.
(win32_remove_point): Call remove_memory_breakpoint when needed.
(win32_process_target::stopped_by_sw_breakpoint)
(win32_process_target::supports_stopped_by_sw_breakpoint): New
methods.
(win32_target_ops): Update.
(maybe_adjust_pc): New function.
(win32_wait): Call maybe_adjust_pc.
This adds a decr_pc_after_break member to win32_target_ops and updates
the two Windows targets to set it.
Note that I can't test the win32-arm-low.c change.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.h (struct win32_target_ops) <decr_pc_after_break>: New
field.
* win32-i386-low.c (the_low_target): Update.
* win32-arm-low.c (the_low_target): Update.
This changes win32-low.c to implement the read_pc and write_pc
methods. A subsequent patch will need these.
Note that I have no way to test, or even compile, the win32-arm-low.c
change.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.h (win32_process_target::read_pc)
(win32_process_target::write_pc): Declare.
* win32-low.c (win32_process_target::read_pc)
(win32_process_target::write_pc): New methods.
* win32-i386-low.c (i386_win32_get_pc, i386_win32_set_pc): New
functions.
(the_low_target): Update.
* win32-arm-low.c (arm_win32_get_pc, arm_win32_set_pc): New
functions.
(the_low_target): Update.
This moves the wait_for_debug_event helper function to
nat/windows-nat.c, and changes gdbserver to use it.
wait_for_debug_event is a wrapper for WaitForDebugEvent that also sets
last_wait_event when appropriate. This is needed to properly handle
queued stops.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (wait_for_debug_event): Move to
nat/windows-nat.c.
* nat/windows-nat.h (wait_for_debug_event): Declare.
* nat/windows-nat.c (wait_for_debug_event): Move from
windows-nat.c. No longer static.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (win32_kill, get_child_debug_event): Use
wait_for_debug_event.
This adds a couple of functions to nat/windows-nat.c and changes gdb
and gdbserver to use them. One function checks the list of pending
stops for a match (not yet used by gdbserver, but will be in a
subsequent patch); and the other is a wrapper for ContinueDebugEvent
that always uses the last "real" stop event.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_continue): Use matching_pending_stop and
continue_last_debug_event.
* nat/windows-nat.h (matching_pending_stop)
(continue_last_debug_event): Declare.
* nat/windows-nat.c (DEBUG_EVENTS): New define.
(matching_pending_stop, continue_last_debug_event): New
functions.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (child_continue): Call continue_last_debug_event.
Both gdb and gdbserver have a "handle_exception" function, the bulk of
which is shared between the two implementations. This patch arranges
for the entire thing to be moved into nat/windows-nat.c, with the
differences handled by callbacks. This patch introduces one more
callback to make this possible.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (MS_VC_EXCEPTION): Move to nat/windows-nat.c.
(handle_exception_result): Move to nat/windows-nat.h.
(DEBUG_EXCEPTION_SIMPLE): Remove.
(windows_nat::handle_ms_vc_exception): New function.
(handle_exception): Move to nat/windows-nat.c.
(get_windows_debug_event): Update.
(STATUS_WX86_BREAKPOINT, STATUS_WX86_SINGLE_STEP): Move to
nat/windows-nat.c.
* nat/windows-nat.h (handle_ms_vc_exception): Declare.
(handle_exception_result): Move from windows-nat.c.
(handle_exception): Declare.
* nat/windows-nat.c (MS_VC_EXCEPTION, handle_exception)
(STATUS_WX86_SINGLE_STEP, STATUS_WX86_BREAKPOINT): Move from
windows-nat.c.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (handle_exception): Remove.
(windows_nat::handle_ms_vc_exception): New function.
(get_child_debug_event): Add "continue_status" parameter.
Update.
(win32_wait): Update.
This changes nat/windows-nat.h to declare handle_load_dll and
handle_unload_dll. The embedding application is required to implement
these -- while the actual code was difficult to share due to some
other differences between the two programs, sharing the declaration
lets a subsequent patch share more code that uses these as callbacks.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat::handle_load_dll)
(windows_nat::handle_unload_dll): Rename. No longer static.
* nat/windows-nat.h (handle_load_dll, handle_unload_dll):
Declare.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (windows_nat::handle_load_dll): Rename from
handle_load_dll. No longer static.
(windows_nat::handle_unload_dll): Rename from handle_unload_dll.
No longer static.
This changes gdbserver's implementation of handle_output_debug_string
to have the same calling convention as that of gdb. This allows for
sharing some more code in a subsequent patch.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat::handle_output_debug_string):
Rename. No longer static.
* nat/windows-nat.h (handle_output_debug_string): Declare.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (handle_output_debug_string): Add parameter. Change
return type.
(win32_kill, get_child_debug_event): Update.
This moves get_image_name to nat/windows-nat.c so that it can be
shared between gdb and gdbserver.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (get_image_name): Move to nat/windows-nat.c.
(handle_load_dll): Update.
* nat/windows-nat.c (get_image_name): Move from windows-nat.c.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (get_image_name): Remove.
(handle_load_dll): Update.
This changes gdb and gdbserver to use the same calling convention for
the "thread_rec" helper function. Fully merging these is difficult
due to differences in how threads are managed by the enclosing
applications; but sharing a declaration makes it possible for future
shared code to call this method.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (enum thread_disposition_type): Move to
nat/windows-nat.h.
(windows_nat::thread_rec): Rename from thread_rec. No longer
static.
(windows_add_thread, windows_nat_target::fetch_registers)
(windows_nat_target::store_registers, handle_exception)
(windows_nat_target::resume, get_windows_debug_event)
(windows_nat_target::get_tib_address)
(windows_nat_target::thread_name)
(windows_nat_target::thread_alive): Update.
* nat/windows-nat.h (enum thread_disposition_type): Move from
windows-nat.c.
(thread_rec): Declare.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (windows_nat::thread_rec): Rename from thread_rec.
No longer static. Change parameters.
(child_add_thread, child_fetch_inferior_registers)
(child_store_inferior_registers, win32_resume)
(win32_get_tib_address): Update.
This adds "suspend" and "resume" methods to windows_thread_info, and
changes gdb and gdbserver to share this code.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (thread_rec): Use windows_thread_info::suspend.
(windows_continue): Use windows_continue::resume.
* nat/windows-nat.h (struct windows_thread_info) <suspend,
resume>: Declare new methods.
* nat/windows-nat.c: New file.
* configure.nat (NATDEPFILES): Add nat/windows-nat.o when needed.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (win32_require_context, suspend_one_thread): Use
windows_thread_info::suspend.
(continue_one_thread): Use windows_thread_info::resume.
* configure.srv (srv_tgtobj): Add windows-nat.o when needed.
This changes a couple of fields of windows_thread_info to have type
"bool". It also updates the comment of another field, to clarify the
possible values it can hold.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (thread_rec)
(windows_nat_target::fetch_registers): Update.
* nat/windows-nat.h (struct windows_thread_info) <suspended>:
Update comment.
<debug_registers_changed, reload_context>: Now bool.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-i386-low.c (update_debug_registers)
(i386_prepare_to_resume, i386_thread_added): Update.
This adds a constructor, destructor, and member initializers to
windows_thread_info, and changes gdb and gdbserver to use new and
delete.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_add_thread): Use new.
(windows_init_thread_list, windows_delete_thread): Use delete.
(get_windows_debug_event): Update.
* nat/windows-nat.h (struct windows_thread_info): Add constructor,
destructor, and initializers.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (child_add_thread): Use new.
(delete_thread_info): Use delete.
This introduces a new file, nat/windows-nat.h, which holds the
definition of windows_thread_info. This is now shared between gdb and
gdbserver.
Note that the two implementations different slightly. gdb had a
couple of fields ("name" and "reload_context") that gdbserver did not;
while gdbserver had one field ("base_context") that gdb did not, plus
better comments. The new file preserves all the fields, and the
comments.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (struct windows_thread_info): Remove.
* nat/windows-nat.h: New file.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.h (struct windows_thread_info): Remove.
gdbserver/ChangeLog:
2020-04-02 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Remove the 'get_ipa_tdesc_idx' linux target op and let a concrete
linux target define the op by overriding the declaration in
process_stratum_target.
* linux-low.h (struct linux_target_ops): Remove the op.
(class linux_process_target) <get_ipa_tdesc_idx>: Remove.
* linux-low.cc (linux_process_target::get_ipa_tdesc_idx): Remove.
* linux-x86-low.cc (class x86_target) <get_ipa_tdesc_idx>: Declare.
(x86_get_ipa_tdesc_idx): Turn into...
(x86_target::get_ipa_tdesc_idx): ...this.
(the_low_target): Remove the op field.
* linux-ppc-low.cc (class ppc_target) <get_ipa_tdesc_idx>: Declare.
(ppc_get_ipa_tdesc_idx): Turn into...
(ppc_target::get_ipa_tdesc_idx): ...this.
(the_low_target): Remove the op field.
* linux-s390-low.cc (class s390_target) <get_ipa_tdesc_idx>: Declare.
(s390_get_ipa_tdesc_idx): Turn into...
(s390_target::get_ipa_tdesc_idx): ...this.
(the_low_target): Remove the op field.
All the linux low targets except arm define the
'supports_hardware_single_step' op to return true. Hence, we override
the method to return true in linux_process_target, and remove the
definitions in all the linux low targets but arm.
gdbserver/ChangeLog:
2020-04-02 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Remove the 'supports_hardware_single_step' linux target op and
override the process_stratum_target's op definition in
linux_process_target to return true.
* linux-low.h (struct linux_target_ops): Remove the op.
(class linux_process_target) <finish_step_over>
<maybe_hw_step>: Declare.
* linux-low.cc (can_hardware_single_step): Remove.
(maybe_hw_step): Turn into...
(linux_process_target::maybe_hw_step): ...this.
(finish_step_over): Turn into...
(linux_process_target::finish_step_over): ...this.
(linux_process_target::supports_hardware_single_step): Update
to return true.
Update the callers below.
(linux_process_target::single_step)
(linux_process_target::resume_one_lwp_throw)
* linux-arm-low.cc (class arm_target)
<supports_hardware_single_step>: Declare.
(arm_supports_hardware_single_step): Turn into...
(arm_target::supports_hardware_single_step): ...this.
(the_low_target): Remove the op field.
* linux-x86-low.cc (x86_supports_hardware_single_step): Remove.
(the_low_target): Remove the op field.
* linux-aarch64-low.cc (aarch64_supports_hardware_single_step):
Remove.
(the_low_target): Remove the op field.
* linux-bfin-low.cc (bfin_supports_hardware_single_step): Remove.
(the_low_target): Remove the op field.
* linux-crisv32-low.cc (cris_supports_hardware_single_step): Remove.
(the_low_target): Remove the op field.
* linux-m32r-low.cc (m32r_supports_hardware_single_step): Remove.
(the_low_target): Remove the op field.
* linux-m68k-low.cc (m68k_supports_hardware_single_step): Remove.
(the_low_target): Remove the op field.
* linux-ppc-low.cc (ppc_supports_hardware_single_step): Remove.
(the_low_target): Remove the op field.
* linux-s390-low.cc (s390_supports_hardware_single_step): Remove.
(the_low_target): Remove the op field.
* linux-sh-low.cc (sh_supports_hardware_single_step): Remove.
(the_low_target): Remove the op field.
* linux-tic6x-low.cc (tic6x_supports_hardware_single_step): Remove.
(the_low_target): Remove the op field.
* linux-tile-low.cc (tile_supports_hardware_single_step): Remove.
(the_low_target): Remove the op field.
* linux-xtensa-low.cc (xtensa_supports_hardware_single_step):
Remove.
(the_low_target): Remove the op field.
gdbserver/ChangeLog:
2020-04-02 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Turn the 'arch_setup' linux target op into a method of
linux_process_target.
* linux-low.h (struct linux_target_ops) <arch_setup>: Delete.
(class linux_process_target) <arch_setup_thread>
<low_arch_setup>: New declarations.
* linux-low.cc (linux_arch_setup): Delete.
(linux_arch_setup_thread): Turn into...
(linux_process_target::arch_setup_thread): ... this.
Update the callers below.
(linux_process_target::handle_extended_wait)
(linux_process_target::post_create_inferior)
(linux_process_target::filter_event)
* linux-x86-low.cc (class x86_target) <low_arch_setup>: New
declaration.
(x86_linux_update_xmltarget): Turn into...
(x86_target::update_xmltarget): ...this.
(x86_linux_process_qsupported): Update the call to
x86_linux_update_xmltarget.
(x86_arch_setup): Turn into ...
(x86_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-aarch64-low.cc (class aarch64_target) <low_arch_setup>: New
declaration.
(aarch64_arch_setup): Turn into ...
(aarch64_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-arm-low.cc (class arm_target) <low_arch_setup>: New
declaration.
(arm_arch_setup): Turn into ...
(arm_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-bfin-low.cc (class bfin_target) <low_arch_setup>: New
declaration.
(bfin_arch_setup): Turn into ...
(bfin_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-cris-low.cc (class cris_target) <low_arch_setup>: New
declaration.
(cris_arch_setup): Turn into ...
(cris_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-crisv32-low.cc (class crisv32_target) <low_arch_setup>: New
declaration.
(crisv32_arch_setup): Turn into ...
(crisv32_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-ia64-low.cc (class ia64_target) <low_arch_setup>: New
declaration.
(ia64_arch_setup): Turn into ...
(ia64_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-m32r-low.cc (class m32r_target) <low_arch_setup>: New
declaration.
(m32r_arch_setup): Turn into ...
(m32r_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-m68k-low.cc (class m68k_target) <low_arch_setup>: New
declaration.
(m68k_arch_setup): Turn into ...
(m68k_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-mips-low.cc (class mips_target) <low_arch_setup>: New
declaration.
(mips_arch_setup): Turn into ...
(mips_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-nios2-low.cc (class nios2_target) <low_arch_setup>: New
declaration.
(nios2_arch_setup): Turn into ...
(nios2_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-ppc-low.cc (class ppc_target) <low_arch_setup>: New
declaration.
(ppc_arch_setup): Turn into ...
(ppc_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-riscv-low.cc (class riscv_target) <low_arch_setup>: New
declaration.
(riscv_arch_setup): Turn into ...
(riscv_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-s390-low.cc (class s390_target) <low_arch_setup>: New
declaration.
(s390_arch_setup): Turn into ...
(s390_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-sh-low.cc (class sh_target) <low_arch_setup>: New
declaration.
(sh_arch_setup): Turn into ...
(sh_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-sparc-low.cc (class sparc_target) <low_arch_setup>: New
declaration.
(sparc_arch_setup): Turn into ...
(sparc_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-tic6x-low.cc (class tic6x_target) <low_arch_setup>: New
declaration.
(tic6x_arch_setup): Turn into ...
(tic6x_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-tile-low.cc (class tile_target) <low_arch_setup>: New
declaration.
(tile_arch_setup): Turn into ...
(tile_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
* linux-xtensa-low.cc (class xtensa_target) <low_arch_setup>: New
declaration.
(xtensa_arch_setup): Turn into ...
(xtensa_target::low_arch_setup): ...this.
(the_low_target): Remove the op field.
This is the beginning of a series of patches that convert the linux
low targets into classes derived from linux_process_target. At the
end of the series we obtain a class hierarchy that looks like this:
process_stratum_target
^
|
|-- linux_process_target
^
|
|-- x86_target (defined in linux-x86-low)
|-- aarch64_target (defined in linux-aarch64-low)
|-- ppc_target (defined in linux-ppc-low)
|-- ...
In several cases, linux_process_target simply forwards a target op
request to a corresponding linux_target_ops function. For these
cases, the definition in linux_process_target will be removed and the
definition will be left to the deriving linux low target class; using
inheritance provides a nice and natural, object-oriented
simplification in these cases.
The series converts linux_target_ops into protected methods of
linux_process_target one by one. Throughout the series, based on the
needs, static functions defined in linux-low.cc are converted to
private methods of linux_process_target as well. This is done either
as separate patches or as integrated into a patch that convert a
particular linux_target_op into a method.
The series ends with the patch titled "gdbserver/linux-low: delete
'linux_target_ops' and 'the_low_target'".
Built and regression-tested on x86_64-linux. The following linux low
targets have been built (but not tested) via cross-compilation:
aarch64, arm, m68k, mips, ppc, riscv, s390, sh, sparc. The other
targets (bfin, cris, crisv32, ia64, m32r, nios2, tic6x, tile, xtensa)
were neither built nor tested.
gdbserver/ChangeLog:
2020-04-02 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* linux-low.h (the_linux_target): New extern declaration.
* linux-low.cc (initialize_low): Use 'the_linux_target' to set
'the_target'.
(the_linux_target): Remove.
* linux-x86-low.cc (class x86_target): New class.
(the_x86_target): New static object.
(the_linux_target): Define as pointer to the_x86_target.
* linux-aarch64-low.cc (class aarch64_target): New class.
(the_aarch64_target): New static object.
(the_linux_target): Define as pointer to the_aarch64_target.
* linux-arm-low.cc (class arm_target): New class.
(the_arm_target): New static object.
(the_linux_target): Define as pointer to the_arm_target.
* linux-bfin-low.cc (class bfin_target): New class.
(the_bfin_target): New static object.
(the_linux_target): Define as pointer to the_bfin_target.
* linux-cris-low.cc (class cris_target): New class.
(the_cris_target): New static object.
(the_linux_target): Define as pointer to the_cris_target.
* linux-crisv32-low.cc (class crisv32_target): New class.
(the_crisv32_target): New static object.
(the_linux_target): Define as pointer to the_crisv32_target.
* linux-ia64-low.cc (class ia64_target): New class.
(the_ia64_target): New static object.
(the_linux_target): Define as pointer to the_ia64_target.
* linux-m32r-low.cc (class m32r_target): New class.
(the_m32r_target): New static object.
(the_linux_target): Define as pointer to the_m32r_target.
* linux-m68k-low.cc (class m68k_target): New class.
(the_m68k_target): New static object.
(the_linux_target): Define as pointer to the_m68k_target.
* linux-mips-low.cc (class mips_target): New class.
(the_mips_target): New static object.
(the_linux_target): Define as pointer to the_mips_target.
* linux-nios2-low.cc (class nios2_target): New class.
(the_nios2_target): New static object.
(the_linux_target): Define as pointer to the_nios2_target.
* linux-ppc-low.cc (class ppc_target): New class.
(the_ppc_target): New static object.
(the_linux_target): Define as pointer to the_ppc_target.
* linux-riscv-low.cc (class riscv_target): New class.
(the_riscv_target): New static object.
(the_linux_target): Define as pointer to the_riscv_target.
* linux-s390-low.cc (class s390_target): New class.
(the_s390_target): New static object.
(the_linux_target): Define as pointer to the_s390_target.
* linux-sh-low.cc (class sh_target): New class.
(the_sh_target): New static object.
(the_linux_target): Define as pointer to the_sh_target.
* linux-sparc-low.cc (class sparc_target): New class.
(the_sparc_target): New static object.
(the_linux_target): Define as pointer to the_sparc_target.
* linux-tic6x-low.cc (class tic6x_target): New class.
(the_tic6x_target): New static object.
(the_linux_target): Define as pointer to the_tic6x_target.
* linux-tile-low.cc (class tile_target): New class.
(the_tile_target): New static object.
(the_linux_target): Define as pointer to the_tile_target.
* linux-xtensa-low.cc (class xtensa_target): New class.
(the_xtensa_target): New static object.
(the_linux_target): Define as pointer to the_xtensa_target.
The comment for the linux target op 'cannot_store_register' states the
following:
/* Returns 0 if we can store the register, 1 if we can not
store the register, and 2 if failure to store the register
is acceptable. */
There is only one low target, linux-ppc-low, that potentially returns
2. There are two places that call the 'cannot_store_register' target
op in linux-low.cc. None of these locations distinguish a '2' from a
'1'. Hence, to simplify the definition, make the function a predicate
that returns either 0 or 1. This is also consistent with the
companion function, 'cannot_fetch_register'.
gdbserver/ChangeLog:
2020-04-02 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* linux-low.h (struct linux_target_ops): Update the comment for
'cannot_store_register' to return 0 or 1.
* linux-ppc-low.cc (ppc_cannot_store_register): Return 1 instead
of 2.
I stumbled on this snippet in nat/gdb_ptrace.h:
/* Some systems, in particular DEC OSF/1, Digital Unix, Compaq Tru64
or whatever it's called these days, don't provide a prototype for
ptrace. Provide one to silence compiler warnings. */
#ifndef HAVE_DECL_PTRACE
extern PTRACE_TYPE_RET ptrace();
#endif
I believe this is unnecessary today and should be removed. First, the
comment only mentions OSes we don't support (and to be honest, I had
never even heard of).
But most importantly, in C++, a declaration with empty parenthesis
declares a function that accepts no arguments, unlike in C. So if this
declaration was really used, GDB wouldn't build, since all ptrace call
sites pass some arguments. Since we haven't heard anything about this
causing some build failures since we have transitioned to C++, I
conclude that it's not used.
This patch removes it as well as the corresponding configure check.
gdb/ChangeLog:
* ptrace.m4: Don't check for ptrace declaration.
* config.in: Re-generate.
* configure: Re-generate.
* nat/gdb_ptrace.h: Don't declare ptrace if HAVE_DECL_PTRACE is
not defined.
gdbserver/ChangeLog:
* config.in: Re-generate.
* configure: Re-generate.
gdbsupport/ChangeLog:
* config.in: Re-generate.
* configure: Re-generate.
This changes the gdbserver build to use the gdbsupport that was built
for gdb.
gdbserver and gdbreplay now must use WIN32APILIBS (aka -lws2_32).
Before this change, gdbserver did not define USE_WIN32API when
building gdbsupport, but now this is always done.
ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* Makefile.in: Rebuild.
* Makefile.def (gdbserver): Depend on gdbsupport.
gdbserver/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* configure.ac (GDBSERVER_DEPFILES): Remove srv_selftest_objs.
(WIN32APILIBS): New subst.
* Makefile.in (SFILES, OBS, TAGS, GDBREPLAY_OBS): Remove
gdbsupport files.
(gdbsupport/%.o): Remove target.
(GDBSUPPORT_BUILDDIR, GDBSUPPORT): New variables.
(gdbserver$(EXEEXT), gdbreplay$(EXEEXT)): Add GDBSUPPORT.
(WIN32APILIBS): New variable.
(gdbserver$(EXEEXT)): Add WIN32APILIBS.
(gdbreplay$(EXEEXT)): Likewise.
gdbserver uses gdb's alloc.c, and this in turn can include headers
from intl via gdbsupport/gdb_locale.h. This can cause build failures
in some situations, for example if you build gdb and gdbserver on
mingw.
This patch restores the gdbsupport dependency on intl, and changes
gdbserver to use ZW_GNU_GETTEXT_SISTER_DIR. This fixes this build
problem.
ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* Makefile.in: Rebuild.
* Makefile.def (gdbsupport): Depend on intl.
gdbserver/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* config.in, configure: Rebuild.
* configure.ac: Call ZW_GNU_GETTEXT_SISTER_DIR.
* acinclude.m4: Include gettext-sister.m4.
* Makefile.in (top_builddir, INTL, INTL_DEPS, INTL_CFLAGS): New
variables.
(INCLUDE_CFLAGS): Add INTL_CFLAGS.
(gdbserver$(EXEEXT), gdbreplay$(EXEEXT)): Use INTL_DEPS, INTL.
The selftest.m4 file is used by gdb, gdbserver and gdbsupport, I think
it belongs in gdbsupport.
gdb/ChangeLog:
* selftest.m4: Move to gdbsupport/.
* acinclude.m4: Update path to selftest.m4.
gdbserver/ChangeLog:
* acinclude.m4: Update path to selftest.m4.
gdbsupport/ChangeLog:
* selftest.m4: Moved from gdb/.
* acinclude.m4: Update path to selftest.m4.
The same is done for gdb, gdbserver and gdbsupport. I therefore think
it makes sense to move that to GDB_AC_COMMON.
It is required to move the call to GDB_AC_COMMON so it is before
GDB_AC_SELFTEST in gdbserver/configure.ac, otherwise the $development
variable isn't set when the code behind GDB_AC_SELFTEST executes.
gdb/ChangeLog:
* configure.ac: Don't source bfd/development.sh.
* selftest.m4: Modify comment.
* configure: Re-generate.
gdbserver/ChangeLog:
* configure.ac: Don't source bfd/development.sh, move
GDB_AC_COMMON higher.
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure.ac: Don't source bfd/development.sh.
* common.m4: Source bfd/development.sh.
* configure: Re-generate.
Before commit 3d1e5a43cb ("gdbsupport/configure.ac: source
development.sh"), the GDB build in non-development mode (turn
development to false in bfd/development.sh if you want to try) was
broken because the gdbsupport configure script didn't source
bfd/development.sh to set the development variable.
Since the GDB_AC_SELFTEST macro relies on the `development` variable, I
propose to modify it such that it errors out if $development does not
have an expected value of "true" or "false". This could prevent a
future similar problem from happening while refactoring the configure
scripts. It would have caught the problem fixed by the patch mentioned
earlier.
gdb/ChangeLog:
* selftest.m4 (GDB_AC_SELFTEST): Error out if $development is
not "true" or "false".
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
While compiling with clang, I noticed it didn't catch cases where my
function declaration didn't match my function definition. This is
normally caught by gcc with -Wmissing-declarations.
On clang, this is caught by -Wmissing-prototypes instead.
Note that on gcc, -Wmissing-prototypes also exists, but is only valid
for C and Objective-C. It gets correctly rejected by the configure
script since gcc rejects it with:
cc1plus: error: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++ -Werror
So this warning flag ends up not used for gcc (which is what we want).
gdb/ChangeLog:
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
* warning.m4: Enable -Wmissing-prototypes.
Copy the .dir-locls.el file from gdb/ to gdbserver/ and gdbsupport/ so
that we get the GNU/GDB style when editing these files in Emacs.
I initially wanted to remove the (c-mode . ((mode . c++))) that
switches c-mode files into c++-mode as we store C++ code in *.cc files
in the gdbserver/ directory, unlike gdb/ where we use *.c, however, I
was forgetting about the header files - we still use *.h for our C++
header files, so for now I left the settings in place to open all C
files in c++-mode.
We now have three copies of this file, which are all identical. It
would be nice if we could remove this duplication, however, for now we
haven't found a good way to do this.
Some options considered were:
1. Use symlinks to only have one copy of the file. This was
rejected as not all targets support symlinks in the way.
2. Have two of the .dir-locals.el files contain some mechanism by
which the third copy of the file is sourced. Though this would, in
theory, be possible, it would involve some advanced Emacs scripting,
would be fragile, and a maintenance burdon.
3. Move the .dir-locals up into top level src/ directory, then use
Emacs dir-locals directory pattern matching to only apply the rules
for the three directories we care about. The problem is that each
directory has to be listed separately, so we still end up having to
duplicate all the rules.
In the end, it was decided that having three copies of the file,
though not ideal, is probably easiest for now. This was all discussed
in this mailing list thread:
https://sourceware.org/ml/gdb-patches/2020-03/msg00024.html
The copyright date in the new files is left as for gdb/.dir-locals.el,
as the new files are a copy of the old, this is inline with this rule:
https://sourceware.org/gdb/wiki/ContributionChecklist#Copyright_Header
gdb/ChangeLog:
* .dir-locals.el: Add a comment referencing the other copies of
this file.
gdbserver/ChangeLog:
* .dir-locals.el: New file.
gdbsupport/ChangeLog:
* .dir-locals.el: New file.
Create .gitattributes files in gdb/, gdbserver/, and gdbsupport/.
The files specify cpp-style diffs for .h and .c files. This is
particularly helpful if a class in a header file is modified.
For instance, if the `stop_requested` field of `thread_info` in
gdb/gdbthread.h is modified, we get the following diff with
'git diff' (using git version 2.17.1):
@@ -379,7 +379,7 @@ public:
struct target_waitstatus pending_follow;
/* True if this thread has been explicitly requested to stop. */
- int stop_requested = 0;
+ bool stop_requested = 0;
/* The initiating frame of a nexting operation, used for deciding
which exceptions to intercept. If it is null_frame_id no
Note that the context of the change shows up as 'public:'; not so
useful. With the .gitattributes file, we get:
@@ -379,7 +379,7 @@ class thread_info : public refcounted_object
struct target_waitstatus pending_follow;
/* True if this thread has been explicitly requested to stop. */
- int stop_requested = 0;
+ bool stop_requested = 0;
/* The initiating frame of a nexting operation, used for deciding
which exceptions to intercept. If it is null_frame_id no
The context is successfully shown as 'class thread_info'.
This patch creates a .gitattributes file per each of gdb, gdbserver,
and gdbsupport folders. An alternative would be to define the
attributes in the root folder -- this would impact all the top-level
folders, though. I opted for the more conservative approach.
gdb/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
gdbserver/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
gdbsupport/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
There is a developer only feature in gdbserver that provides a
command line option --disable-packet that prevents some packets from
being sent, which is used to increase test coverage within GDB.
This commit extends this mechanism to prevent GDBserver from sending
the T stop reply packets, instead limiting GDBserver to only send the
S stop reply packets.
The S stop reply packet is part of the older target control mechanism,
which has design flaws that were worked around with the introduction
of the newer target control mechanism, which uses the T stop reply
packet.
Limiting GDBserver to use S stop packets instead of T stop packets
will, inevitably, mean that GDBserver doesn't function correctly in
many cases involving multiple threads, however, I don't think this is
too important, this is a developer only feature, intended to allow us
to test GDB.
A new test that makes use of this feature will be added in the next
commit.
gdbserver/ChangeLog:
* remote-utils.cc (prepare_resume_reply): Add ability to convert T
reply into an S reply.
* server.cc (disable_packet_T): New global.
(captured_main): Set new global when appropriate.
* server.h (disable_packet_T): Declare.
I noticed gdbserver's Makefile doesn't have a mostlyclean target. I
use this sometimes, so this patch adds it. Adding it as a synonym of
"clean" seemed to make sense, given the contents of that rule.
gdbserver/ChangeLog
2020-02-21 Tom Tromey <tom@tromey.com>
* Makefile.in (mostlyclean): New target.
The 'set_target_ops' function takes a target op vector and creates a
clone of it via XNEW and memcpy. This is not necessary. 'the_target'
is a singleton, and the argument that is passed to 'set_target_ops' is
always the address of a global, static object. Therefore, update the
implementation to simply copy the pointer.
gdbserver/ChangeLog:
2020-02-20 Pedro Alves <palves@redhat.com>
* target.cc (set_target_ops): Simply copy the given target pointer
instead of creating a copy of the pointed object.
This is the beginning of a series of patches where the goal is to turn
the target ops vector into a class and all the target op function
pointers into methods of this class.
Currently, the target ops is a struct of function pointers. At the
end of the series, it becomes a class with methods, and the existing
low target definitions become subclasses. That is, we end up with the
following class hierarchy:
process_stratum_target
^
|-- linux-low
|-- lynx-low
|-- nto-low
|-- win32-low
process_stratum_target either defines the default behavior for the
target ops or leaves them as pure virtual for the subclasses to
override.
The transformation is done by first introducing a helper class, called
'process_target', that is initially empty. An instance of this class
is added to the end of the current target ops vector. This new field
is called 'pt'. We will gradually carry target ops to the new class,
one by one, whereas the invocation of the target op will be converted
to a method call on 'pt'.
For instance, target op 'attach' is currently invoked as
(*the_target->attach) (args)
After moving 'attach' as a method to 'process_target', it will be
invoked as
the_target->pt->attach (args)
In this process, the concrete target vector definitions
(e.g. linux-low, win32-low, nto-low, etc.) are turned into derived
classes of 'process_target', so that they can either inherit the
default behavior of the target ops or can override the method.
We prefer to make this transition gradually rather than in a single
giant patch, to yield bite-size patches. The goal is that after each
patch gdbserver will still be buildable and testable.
The general rule of thumb when converting a target op to a method is
this:
(1) If the function call is protected with a NULL-check with an
obvious default behavior, simply implement that default behavior in
the base class (e.g.: supports_non_stop).
(2) If there is no NULL-check guard, the method becomes pure
virtual, and the derived targets are required to implement the method
(e.g.: attach).
(3) If there is a NULL-check but no apparent default behavior, or if
the NULL-check is utilized to populate a feature support packet,
introduce a 'supports_XYZ' method (e.g.: pid_to_exec_file).
The overall strategy is to preserve the existing behavior as much as
possible.
When we're done moving all the target ops into 'process_target', the
target op vector will contain nothing but the field 'pt'. At that
point, the auxiliary class 'process_target' will simply meld into
'process_stratum_target' and the method calls of the form
'the_target->pt->xyz' will be turned into 'the_target->xyz'.
The "linux-low" target has been built and reg-tested on X86_64 Linux
(Ubuntu). The "win32-low" target has been built (but not tested) via
cross-compilation to a x86_64-w64-mingw32 target. The "lynx-low" and
"nto-low" targets were neither built nor tested.
gdbserver/ChangeLog:
2020-02-20 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* target.h (class process_target): New class definition.
(struct process_stratum_target) <pt>: New field with type
'process_target*'.
* linux-low.h (class linux_process_target): Define as a derived
class of 'process_target'.
* linux-low.cc (linux_target_ops): Add a linux_process_target*
as the 'pt' field.
* lynx-low.h (class lynx_process_target): Define as a derived
class of 'process_target'.
* lynx-low.cc (lynx_target_ops): Add a lynx_process_target*
as the 'pt' field.
* nto-low.h (class nto_process_target): Define as a derived
class of 'process_target'.
* nto-low.cc (nto_target_ops): Add an nto_process_target*
as the 'pt' field.
* win32-low.h (class win32_process_target): Define as a derived
class of 'process_target'.
* win32-low.cc (win32_target_ops): Add a win32_process_target*
as the 'pt' field.
GCC's config/ChangeLog since the last time this merge was done
(in the binutils-gdb commit 0b4d000cc4) is included at the
end of this commit message.
It is worth noting that the binutils-gdb commit 301a9420d9
added the file config/debuginfod.m4 which is not present in GCC's
config/ directory. This file is preserved, unmodified, after this
commit.
In order to regenerate all of the configure files, I configured with
--enable-maintainer-mode, and built the 'all' target. I then did the
same thing on a source tree without this patch, and only committed
those files that changed when this patch was added.
GCC's config/ChangeLog entries:
2020-02-12 Sandra Loosemore <sandra@codesourcery.com>
PR libstdc++/79193
PR libstdc++/88999
* no-executables.m4: Use a non-empty program to test for linker
support.
2020-02-01 Andrew Burgess <andrew.burgess@embecosm.com>
* lib-link.m4 (AC_LIB_LINKFLAGS_BODY): Update shell syntax.
2020-01-27 Andrew Burgess <andrew.burgess@embecosm.com>
* lib-link.m4 (AC_LIB_LINKFLAGS_BODY): Add new
--with-libXXX-type=... option. Use this to guide the selection of
either a shared library or a static library.
2020-01-24 Maciej W. Rozycki <macro@wdc.com>
* toolexeclibdir.m4: New file.
2019-09-10 Christophe Lyon <christophe.lyon@st.com>
* futex.m4: Handle *-uclinux*.
* tls.m4 (GCC_CHECK_TLS): Likewise.
2019-09-06 Florian Weimer <fweimer@redhat.com>
* futex.m4 (GCC_LINUX_FUTEX): Include <unistd.h> for the syscall
function.
2019-07-08 Richard Sandiford <richard.sandiford@arm.com>
* bootstrap-Og.mk: New file.
2019-06-25 Kwok Cheung Yeung <kcy@codesourcery.com>
Andrew Stubbs <ams@codesourcery.com>
* gthr.m4 (GCC_AC_THREAD_HEADER): Add case for gcn.
2019-05-30 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
* ax_count_cpus.m4: New file.
2019-05-02 Richard Biener <rguenther@suse.de>
PR bootstrap/85574
* bootstrap-lto.mk (extra-compare): Set to gcc/lto1$(exeext).
2019-04-16 Martin Liska <mliska@suse.cz>
* bootstrap-lto-lean.mk: Filter out -flto in STAGEtrain_CFLAGS.
2019-04-09 Martin Liska <mliska@suse.cz>
* bootstrap-lto-lean.mk: New file.
2019-03-02 Johannes Pfau <johannespfau@gmail.com>
* mh-mingw: Also set __USE_MINGW_ACCESS flag for C++ code.
2018-10-31 Joseph Myers <joseph@codesourcery.com>
PR bootstrap/82856
* math.m4, tls.m4: Use AC_LANG_SOURCE.
Merge from binutils-gdb:
2018-06-19 Simon Marchi <simon.marchi@ericsson.com>
* override.m4 (_GCC_AUTOCONF_VERSION): Bump from 2.64 to 2.69.
config/ChangeLog:
* ax_count_cpus.m4: New file, backported from GCC.
* bootstrap-Og.mk: New file, backported from GCC.
* bootstrap-lto-lean.mk: New file, backported from GCC.
* bootstrap-lto.mk: Changes backported from GCC.
* futex.m4: Changes backported from GCC.
* gthr.m4: Changes backported from GCC.
* lib-link.m4: Changes backported from GCC.
* mh-mingw: Changes backported from GCC.
* no-executables.m4: Changes backported from GCC.
* tls.m4: Changes backported from GCC.
* toolexeclibdir.m4: New file, backported from GCC.
binutils/ChangeLog:
* configure: Regenerate.
gdb/ChangeLog:
* configure: Regenerate.
gdbserver/ChangeLog:
* configure: Regenerate.
gdbsupport/ChangeLog:
* configure: Regenerate.
intl/ChangeLog:
* configure: Regenerate.
libiberty/ChangeLog:
* configure: Regenerate.
zlib/ChangeLog.bin-gdb:
* configure: Regenerate.
Implement RISC-V/Linux support for both RV64 and RV32 systems, including
XML target description handling based on features determined, GPR and
FPR regset support including dynamic sizing of the latter, and software
breakpoint handling. Define two NT_FPREGSET regsets of a different size
matching the FPR sizes supported for generic `gdbserver' code to pick
from according to what the OS supplies.
Also handle a glibc bug where ELF_NFPREG is defined in terms of NFPREG,
however NFPREG is nowhere defined.
2020-02-19 Maciej W. Rozycki <macro@wdc.com>
Andrew Burgess <andrew.burgess@embecosm.com>
gdb/
* NEWS: Mention RISC-V GNU/Linux GDBserver support.
gdbserver/
* linux-riscv-low.cc: New file.
* Makefile.in (SFILES): Add linux-riscv-low.cc, arch/riscv.c,
and nat/riscv-linux-tdesc.c.
* configure.srv <riscv*-*-linux*> (srv_tgtobj)
(srv_linux_regsets, srv_linux_usrregs, srv_linux_thread_db):
Define.
This changes gdbserver so that it no longer builds its own gnulib and
libiberty. Instead, it now relies on the ones that were already built
at the top level.
gdbsupport is still built specially for gdbserver. This is more
complicated and will be tackled in a subsequent patch.
ChangeLog
2020-02-14 Tom Tromey <tom@tromey.com>
* Makefile.in: Rebuild.
* Makefile.def: Make gdbserver require gnulib and libiberty.
gdbserver/ChangeLog
2020-02-14 Tom Tromey <tom@tromey.com>
* acinclude.m4: Don't include acx_configure_dir.m4.
* Makefile.in (LIBIBERTY_BUILDDIR, GNULIB_BUILDDIR): Update.
(SUBDIRS, CLEANDIRS, REQUIRED_SUBDIRS): Remove.
(all, install-only, uninstall, clean-info, clean)
(maintainer-clean): Don't recurse.
(subdir_do, all-lib): Remove.
($(LIBGNU) $(LIBIBERTY) $(GNULIB_H)): Remove rule.
(GNULIB_H): Remove.
(generated_files): Update.
($(GNULIB_BUILDDIR)/Makefile): Remove rule.
* configure: Rebuild.
* configure.ac: Don't configure gnulib or libiberty.
(GNULIB): Update.
gdbsupport/ChangeLog
2020-02-14 Tom Tromey <tom@tromey.com>
* common-defs.h: Change path to gnulib/config.h.
Change-Id: I469cbbf5db2ab37109c058e9e3a1e4f4dabdfc98
gdbserver/ChangeLog
2020-02-14 Eli Zaretskii <eliz@gnu.org>
* win32-low.c (create_process): Prepend PROGRAM to ARGS when
preparing the command line for CreateProcess.
(win32_create_inferior): Reflect the program name in debugging
output that shows the process and its command line.
For the same reasons outlined in the previous patch, this patch renames
gdbserver source files to .cc.
I have moved the "-x c++" switch to only those rules that require it.
gdbserver/ChangeLog:
* Makefile.in: Rename source files from .c to .cc.
* %.c: Rename to %.cc.
* configure.ac: Rename server.c to server.cc.
* configure: Re-generate.
This patch renames the .c source files in gdbsupport to .cc.
In the gdb directory, there is an argument against renaming the source
files, which is that it makes using some git commands more difficult to
do archeology. Some commands have some kind of "follow" option that
makes git try to follow renames, but it doesn't work in all situations.
Given that we have just moved the gdbsupport directory, that argument
doesn't hold for source files in that directory. I therefore suggest
renaming them to .cc, so that they are automatically recognized as C++
by various tools and editors.
The original motivation behind this is that when building gdbsupport
with clang, I get:
CC agent.o
clang: error: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Werror,-Wdeprecated]
In the gdb/ directory, we make clang happy by passing "-x c++". We
could do this in gdbsupport too, but I think that renaming the files is
a better long-term solution.
gdbserver still does its own build of gdbsupport, so a few changes in
its Makefile are necessary.
gdbsupport/ChangeLog:
* Makefile.am: Rename source files from .c to .cc.
(CC, CFLAGS): Don't override.
(AM_CFLAGS): Rename to ...
(AM_CXXFLAGS): ... this.
* Makefile.in: Re-generate.
* %.c: Rename to %.cc.
gdbserver/ChangeLog:
* Makefile.in: Rename gdbsupport source files from .c to .cc.
handle_v_kill uses signal_pid because win32 doesn't support multi-process.
Without this gdb just refuses to kill the process:
(gdb) kill
Kill the program being debugged? (y or n) y
Sending packet: $vKill;a410#33...Packet received: E01
Packet vKill (kill) is supported
Can't kill process
gdbserver/ChangeLog:
2020-02-12 Hannes Domani <ssbssa@yahoo.de>
* win32-low.c (win32_create_inferior): Set signal_pid.
Correct fallout from commit 919adfe840 ("Move gdbserver to top level")
and revert to not building `gdbserver' in a cross-configuration, that is
where host != target, matching the documented behaviour. We have no way
to support non-native `gdbserver', and native `gdbserver' is usually of
no use with cross-GDB of the chosen host.
gdbserver/ChangeLog:
2020-02-12 Maciej W. Rozycki <macro@wdc.com>
Pedro Alves <palves@redhat.com>
Skip building gdbserver in a cross-configuration.
* configure.srv: Set $gdbserver_host depending on whether $target
is $host. Use $gdbserver_host instead of $host.
In my previous commit, I did a last minute modification of warning.m4,
but forgot to re-generate the configure scripts, this commit fixes that.
gdb/ChangeLog:
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
Commit 85f0dd3ce ("[gdb] Fix -Wstrict-null-sentinel warnings") fixed
some violations of -Wstrict-null-sentinel. If we want to enforce this
warning, I think we should enable it in our warning.m4 file.
gdbsupport/ChangeLog:
* warning.m4: Add -Wstrict-null-sentinel.
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdb/ChangeLog:
* configure: Re-generate.
This file is used by gdbsupport, gdbserver and gdb, so I think it
belongs in gdbsupport. Move it there and update the references the
various acinclude.m4 files.
gdbsupport/ChangeLog:
* warning.m4: Move here, from gdb/warning.m4.
* acinclude.m4: Update warning.m4 path.
* Makefile.in: Re-generate.
gdbserver/ChangeLog:
* acinclude.m4: Update warning.m4 path.
gdb/ChangeLog:
* acinclude: Update warning.m4 path.
* warning.m4: Move to gdbsupport.
This patch moves gdbserver to the top level.
This patch is as close to a pure move as possible -- gdbserver still
builds its own variant of gnulib and gdbsupport. Changing this will
be done in a separate patch.
[v2] Note that, per Simon's review comment, this patch changes the
tree so that gdbserver is not built for or1k or score. This makes
sense, because there is apparently not actually a gdbserver port here.
[v3] This version of the patch also splits out some configury into a
new file, gdbserver/configure.host, so that the top-level configure
script can simply rely on it in order to decide whether gdbserver
should be built.
[v4] This version adds documentation and removes some unnecessary
top-level dependencies.
[v5] Update docs to mention "make all-gdbserver" and change how
top-level configure decides whether to build gdbserver, switching to a
single, shared script.
Tested by the buildbot.
ChangeLog
2020-02-07 Tom Tromey <tom@tromey.com>
Pedro Alves <palves@redhat.com>
* src-release.sh (GDB_SUPPORT_DIRS): Add gdbserver.
* gdbserver: New directory, moved from gdb/gdbserver.
* configure.ac (host_tools): Add gdbserver.
Only build gdbserver on certain systems.
* Makefile.in, configure: Rebuild.
* Makefile.def (host_modules, dependencies): Add gdbserver.
* MAINTAINERS: Add gdbserver.
gdb/ChangeLog
2020-02-07 Tom Tromey <tom@tromey.com>
* README: Update gdbserver documentation.
* gdbserver: Move to top level.
* configure.tgt (build_gdbserver): Remove.
* configure.ac: Remove --enable-gdbserver.
* configure: Rebuild.
* Makefile.in (distclean): Don't mention gdbserver.
Change-Id: I826b7565b54604711dc7a11edea0499cd51ff39e
