aboutsummaryrefslogtreecommitdiff
path: root/gdbserver/ChangeLog
AgeCommit message (Collapse)AuthorFilesLines
2020-09-10Add minimal and functional NetBSD/amd64 gdbserverKamil Rytarowski1-0/+9
Implement the following functionality: create_inferior, post_create_inferior, attach, kill, detach, mourn, join, thread_alive, resume, wait, fetch_registers, store_registers, read_memory, write_memory, request_interrupt, supports_read_auxv, read_auxv, supports_hardware_single_step, sw_breakpoint_from_kind, supports_z_point_type, insert_point, remove_point, stopped_by_sw_breakpoint, supports_qxfer_siginfo, qxfer_siginfo, supports_stopped_by_sw_breakpoint, supports_non_stop, supports_multi_process, supports_fork_events, supports_vfork_events, supports_exec_events, supports_disable_randomization, supports_qxfer_libraries_svr4, qxfer_libraries_svr4, supports_pid_to_exec_file, pid_to_exec_file, thread_name, supports_catch_syscall. The only CPU architecture supported: x86_64. Implement only support for hardware assisted single step and software breakpoint. Implement support only for regular X86 registers, thus no FPU. gdbserver/ChangeLog: * netbsd-low.cc: Add. * netbsd-low.h: Likewise. * netbsd-amd64-low.cc: Likewise. * Makefile.in (SFILES): Register "netbsd-low.cc", "netbsd-low.h", "netbsd-amd64-low.cc". * configure.srv: Add x86_64-*-netbsd*.
2020-08-13gdb: allow specifying multiple filters when running selftestsSimon Marchi1-0/+5
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
2020-07-30Unify Solaris procfs and largefile handlingRainer Orth1-0/+4
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.
2020-07-26Don't unnecessarily redefine 'socklen_t' type in MinGW builds.Eli Zaretskii1-0/+8
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.
2020-07-22gdbserver: handle running threads in qXfer:threads:readPedro Alves1-0/+11
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.
2020-07-21gdb, gdbserver: make stopped_pids global variables staticSimon Marchi1-0/+4
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
2020-07-17gdb/riscv: delete target descriptions when gdb exitsAndrew Burgess1-0/+6
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.
2020-07-13gdbserver: fix memory leak when handling qsupported packetSimon Marchi1-0/+13
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
2020-06-29[gdbserver] Add missing include of gdbsupport/agent.hTom de Vries1-0/+4
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.
2020-06-23gdb: Print compatible information within print_xml_featureAndrew Burgess1-0/+6
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.
2020-06-22gdbserver/linux-low: use std::list to store pending signalsTankut Baris Aktemur1-0/+20
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.
2020-06-17gdb, gdbserver: remove ARM regdat filesSimon Marchi1-0/+5
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
2020-06-12gdbserver: remove support for ARM/WinCESimon Marchi1-0/+8
This port has been unmaintained for years, remove it. gdbserver/ChangeLog: * Makefile.in (SFILES): Remove win32-arm-low.cc, wincecompat.cc. * configure.srv: Remove mingw32ce cases. * server.h, win32-low.cc: Remove __MINGW32CE__-guarded code. * win32-low.h (to_back_slashes): Remove. * win32-arm-low.cc, wincecompat.cc, wincecompat.h: Remove. Change-Id: Ib75c0b55b0ab7caca38bbeff5f2fa9397a8e7e8d
2020-06-12gdbserver: remove support for TileSimon Marchi1-0/+6
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
2020-06-12gdbserver: remove support for M32RSimon Marchi1-0/+6
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
2020-06-12gdbserver: remove support for CRISSimon Marchi1-0/+6
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
2020-06-12gdbserver: remove support for BlackfinSimon Marchi1-0/+7
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
2020-06-12gdbserver: remove support for NeutrinoSimon Marchi1-0/+8
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
2020-06-12gdbserver: remove support for LynxOSSimon Marchi1-0/+8
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
2020-06-12gdbserver: small cleanup of README fileSimon Marchi1-0/+4
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
2020-05-27Don't close process handle provided by WaitForDebugEventHannes Domani1-0/+6
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.
2020-05-25Use construct_inferior_arguments which handles special charsMichael Weghorn1-0/+13
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 5d60742e2dd3c9b475dce54b56043a358751bbb8 ("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
2020-05-25nto_process_target::create_inferior: Pass args as char **Michael Weghorn1-0/+5
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 2090129c36c7e582943b7d300968d19b46160d84 ("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
2020-05-25gdbserver: Don't add extra NULL to program argsMichael Weghorn1-0/+5
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
2020-05-23Use safe-ctype.h (ISSPACE etc.) in symbol parsing & comparisonPedro Alves1-0/+4
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 b1b60145aedb8adcb0b9dcf43a5ae735c2f03b51 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.
2020-05-16gdbserver/linux-ia64-low: fix a build-breaking typoTankut Baris Aktemur1-0/+6
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.
2020-05-15Enable hardware breakpoints for gdbserver on WindowsHannes Domani1-0/+7
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.
2020-04-30Implement debugging of WOW64 processes in gdbserverHannes Domani1-0/+32
gdbserver/ChangeLog: 2020-04-30 Hannes Domani <ssbssa@yahoo.de> * configure.srv <x86_64-*-mingw*, x86_64-*-cygwin*> (srv_tgtobj): Add arch/i386.o. * win32-arm-low.cc (arm_num_regs): New function. (struct win32_target_ops): Use arm_num_regs. * win32-i386-low.cc (win32_get_current_dr): Adapt for WOW64 processes. (i386_get_thread_context): Likewise. (i386_prepare_to_resume): Likewise. (i386_thread_added): Likewise. (i386_single_step): Likewise. (i386_fetch_inferior_register): Likewise. (i386_store_inferior_register): Likewise. (i386_arch_setup): Likewise. (i386_win32_num_regs): New function. (struct win32_target_ops): Use i386_win32_num_regs. * win32-low.cc (win32_get_thread_context): Adapt for WOW64 processes. (win32_require_context): Likewise. (child_add_thread): Likewise. (do_initial_child_stuff): Likewise. (continue_one_thread): Likewise. (win32_process_target::resume): Likewise. (load_psapi): Likewise. (win32_add_all_dlls): Likewise. (maybe_adjust_pc): Likewise. (win32_process_target::qxfer_siginfo): Likewise. (initialize_low): Likewise. * win32-low.h (struct win32_target_ops): Change num_regs to callback function.
2020-04-27gdb, gdbserver: remove configure check for fs_base/gs_base in user_regs_structSimon Marchi1-0/+9
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.
2020-04-22Fix search of large memory area in gdbserverHannes Domani1-0/+5
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.
2020-04-16Fix Cygwin gdb buildTom Tromey1-0/+5
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.
2020-04-15gdbserver: fix format string warning in win32-low.ccSimon Marchi1-0/+4
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.
2020-04-13Remove gdb_fildes_tTom Tromey1-0/+10
gdb_fildes_t and pfildes are no longer used, so remove them. gdbserver/ChangeLog 2020-04-13 Tom Tromey <tom@tromey.com> * server.h (gdb_fildes_t): Remove typedef. * remote-utils.c (remote_desc, list_desc): Now int. (INVALID_DESCRIPTOR): Remove. (gdb_connected, remote_close) (check_remote_input_interrupt_request): Update. * utils.h (pfildes): Don't declare. * utils.c (pfildes): Remove.
2020-04-13Switch gdbserver to gdbsupport event loopTom Tromey1-0/+16
This changes gdbserver to use the gdbserver event loop, removing the ancient fork. gdbserver/ChangeLog 2020-04-13 Tom Tromey <tom@tromey.com> * server.h (handle_serial_event, handle_target_event): Update. * server.c: Don't call initialize_event_loop. (keep_processing_events): New global. (handle_serial_event): Return void. Set keep_processing_events. (handle_target_event): Return void. (start_event_loop): Move from event-loop.c. Rewrite. * remote-utils.c (handle_accept_event): Return void. (reset_readchar): Use delete_timer. (process_remaining): Return void. (reschedule): Use create_timer. * event-loop.h: Remove. * event-loop.cc: Remove. * Makefile.in (OBS): Use gdbsupport/event-loop.o, not event-loop.o.
2020-04-13Implement event-loop glue for gdbserverTom Tromey1-0/+6
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.
2020-04-13Move event-loop configury to common.m4Tom Tromey1-0/+5
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.
2020-04-08Add pending stop support to gdbserver's Windows portTom Tromey1-0/+7
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.
2020-04-08Implement stopped_by_sw_breakpoint for Windows gdbserverTom Tromey1-0/+16
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.
2020-04-08Introduce win32_target_ops::decr_pc_after_breakTom Tromey1-0/+7
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.
2020-04-08Add read_pc / write_pc support to win32-lowTom Tromey1-0/+13
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.
2020-04-08Move wait_for_debug_event to nat/windows-nat.cTom Tromey1-0/+5
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.
2020-04-08Share some inferior-related Windows codeTom Tromey1-0/+4
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.
2020-04-08Share handle_exceptionTom Tromey1-0/+8
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.
2020-04-08Share handle_load_dll and handle_unload_dll declarationsTom Tromey1-0/+7
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.
2020-04-08Normalize handle_output_debug_string APITom Tromey1-0/+6
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.
2020-04-08Share some Windows-related globalsTom Tromey1-0/+6
This moves some Windows-related globals into nat/windows-nat.c, sharing them between gdb and gdbserver. gdb/ChangeLog 2020-04-08 Tom Tromey <tromey@adacore.com> * windows-nat.c (current_process_handle, current_process_id) (main_thread_id, last_sig, current_event, last_wait_event) (current_windows_thread, desired_stop_thread_id, pending_stops) (struct pending_stop, siginfo_er): Move to nat/windows-nat.c. (display_selectors, fake_create_process) (get_windows_debug_event): Update. * nat/windows-nat.h (current_process_handle, current_process_id) (main_thread_id, last_sig, current_event, last_wait_event) (current_windows_thread, desired_stop_thread_id, pending_stops) (struct pending_stop, siginfo_er): Move from windows-nat.c. * nat/windows-nat.c (current_process_handle, current_process_id) (main_thread_id, last_sig, current_event, last_wait_event) (current_windows_thread, desired_stop_thread_id, pending_stops) (siginfo_er): New globals. Move from windows-nat.c. gdbserver/ChangeLog 2020-04-08 Tom Tromey <tromey@adacore.com> * win32-low.c (current_process_handle, current_process_id) (main_thread_id, last_sig, current_event, siginfo_er): Move to nat/windows-nat.c.
2020-04-08Share get_image_name between gdb and gdbserverTom Tromey1-0/+5
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.
2020-04-08Share thread_rec between gdb and gdbserverTom Tromey1-0/+8
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.
2020-04-08Wrap shared windows-nat code in windows_nat namespaceTom Tromey1-0/+8
This wraps the shared windows-nat code in a windows_nat namespace. This helps avoid name clashes. gdb/ChangeLog 2020-04-08 Tom Tromey <tromey@adacore.com> * windows-nat.c: Add "using namespace". * nat/windows-nat.h: Wrap contents in windows_nat namespace. * nat/windows-nat.c: Wrap contents in windows_nat namespace. gdbserver/ChangeLog 2020-04-08 Tom Tromey <tromey@adacore.com> * win32-low.h (struct win32_target_ops): Use qualified names where needed. * win32-i386-low.c: Add "using namespace". * win32-low.c: Add "using namespace". * win32-arm-low.c: Add "using namespace".
2020-04-08Call CloseHandle from ~windows_thread_infoTom Tromey1-0/+4
Add a destructor to windows_thread_info that calls CloseHandle. gdb/ChangeLog 2020-04-08 Tom Tromey <tromey@adacore.com> * nat/windows-nat.h (struct windows_thread_info): Declare destructor. * nat/windows-nat.c (~windows_thread_info): New. gdbserver/ChangeLog 2020-04-08 Tom Tromey <tromey@adacore.com> * win32-low.c (delete_thread_info): Don't call CloseHandle.
generated by cgit v1.1 at 2024-11-19 23:06:54 +0000