binutils-gdb

Commit Graph

Author	SHA1	Message	Date
Christophe Lyon	96c1bcb38b	gdb, gdbserver: Add missing install-dvi Makefile target For some reason install-dvi is missing although other targets of the same family are present. This looks like an oversight. This enables calling 'make install-dvi' from the top-level build directory. Fix what looks like another oversight: include 'pdf' in 'all-doc' in gdb/doc/Makefile.in. Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>	2 years ago
Simon Marchi	18d2988e5d	gdb, gdbserver, gdbsupport: remove includes of early headers Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>	2 years ago
Simon Marchi	ab7daea3ad	gdb, gdbserver, gdbsupport: include early header files with `-include` The motivation for this change is for analysis tools and IDEs to be better at analyzing header files on their own. There are some definitions and includes we want to occur at the very beginning of all translation units. The way we currently do that is by requiring all source files (.c and .cc files) to include one of defs.h (for gdb), server.h (for gdbserver) of common-defs.h (for gdbsupport and shared source files). These special header files define and include everything that needs to be included at the very beginning. Other header files are written in a way that assume that these special "prologue" header files have already been included. My problem with that is that my editor (clangd-based) provides a very bad experience when editing header files. Since clangd doesn't know that one of defs.h/server.h/common-defs.h was included already, a lot of things are flagged as errors. For instance, CORE_ADDR is not known. It's possible to edit the files in this state, but a lot of the power of the editor is unavailable. My proposal to help with this is to include those things we always want to be there using the compilers' `-include` option. Tom Tromey said that the current approach might exist because not all compilers used to have an option like this. But I believe that it's safe to assume they do today. With this change, clangd picks up the -include option from the compile command, and is able to analyze the header file correctly, as it sees all that stuff included or defined by that -include option. That works because when editing a header file, clangd tries to get the compilation flags from a source file that includes said header file. This change is a bit self-serving, because it addresses one of my frustrations when editing header files, but it might help others too. I'd be curious to know if others encounter the same kinds of problems when editing header files. Also, even if the change is not necessary by any means, I think the solution of using -include for stuff we always want to be there is more elegant than the current solution. Even with this -include flag, many header files currently don't include what they use, but rather depend on files included before them. This will still cause errors when editing them, but it should be easily fixable by adding the appropriate include. There's no rush to do so, as long as the code still compiles, it's just a convenience thing. The changes are: - Add the appropriate `-include` option to the various Makefiles. - There is one particularity for gdbserver's Makefile: we do not want to include server.h when building `gdbreplay.o`, as `gdbreplay.cc` doesn't include it. So we can't simply put the `-include` in `INTERNAL_CFLAGS`. Add the `-include server.h` option to the `COMPILE` and `IPAGENT_COMPILE` variables, and added a special rule to compile `gdbreplay.o` with `-include gdbsupport/common-defs.h`. - Remove the `-include` option from the `check-headers` rule in gdb/Makefile.in, since it is already included in `INTERNAL_CFLAGS`. Change-Id: If3e345d00a9fc42336322f1d8286687d22134340 Approved-By: Pedro Alves <pedro@palves.net>	2 years ago
Simon Marchi	1d43b17eac	{gdb,gdbserver}/Makefile.in: remove unnecessary intermediary variables Remove `INTERNAL_CFLAGS_BASE` and `INTERNAL_WARN_CFLAGS`, inline their contents in `INTERNAL_CFLAGS`. Not functional changes expected. Change-Id: I6a09794835ca2cfd4a88a3e9f2e627c8f5bd569f Approved-By: Pedro Alves <pedro@palves.net>	2 years ago
Simon Marchi	2f3dfa7f90	gdb, gdbserver, gdbsupport: reformat some Makefile variables, one entry per line Reformat some variables definitions. I think it makes them easier to read, and it also makes diffs clearer. Change-Id: I82f63ba0e6d0fe268eb1f1ad5ab22c3cd016ab02 Approved-By: Pedro Alves <pedro@palves.net>	2 years ago
Andrew Burgess	56f703d39d	Revert "gdbserver: convert have_ptrace_getregset to a tribool" This reverts commit `5920765d75`.	2 years ago
Andrew Burgess	59b198a616	Revert "gdbserver/x86: move no-xml code earlier in x86_linux_read_description" This reverts commit `0a7bb97ad2`.	2 years ago
Andrew Burgess	f06daade43	Revert "gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition" This reverts commit `7816b81e9b`.	2 years ago
Andrew Burgess	49a7660fb5	Revert "gdb/gdbserver: share some code relating to target description creation" This reverts commit `cd9b374ffe`.	2 years ago
Andrew Burgess	cba2791ca6	Revert "gdbserver: update target description creation for x86/linux" This reverts commit `61bb321605`.	2 years ago
Andrew Burgess	69324a74e3	Revert "gdb/gdbserver: share x86/linux tdesc caching" This reverts commit `198ff6ff81`.	2 years ago
Andrew Burgess	57d8b51d90	Revert "gdbserver/Makefile.in: add missing `-x c++`" This reverts commit `c7c9820071`.	2 years ago
Simon Marchi	c7c9820071	gdbserver/Makefile.in: add missing `-x c++` When building with Clang, I get: CXX nat/x86-linux-tdesc-ipa.o clang++: error: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Werror,-Wdeprecated] Fix that by adding the missing `-x c++` in the rule building `gdb/nat/*.c` files for the in-process agent. Change-Id: Ie53e4b9a8b57bef9669397fdfaf21617107c7180 Approved-By: Tom Tromey <tom@tromey.com>	2 years ago
Andrew Burgess	198ff6ff81	gdb/gdbserver: share x86/linux tdesc caching This commit builds on the previous series of commits to share the target description caching code between GDB and gdbserver for x86/Linux targets. The objective of this commit is to move the four functions (2 each of) i386_linux_read_description and amd64_linux_read_description into gdb/nat/x86-linux-tdesc.c and combine them so we have just a single copy of each. Then both GDB and gdbserver will link against these shared functions. It is worth reading the description of the previous commit to see why this merging is not as simple as it seems: on the gdbserver side we actually have two users of these functions, gdbserver itself, and the in process agent (IPA). However, the previous commit streamlined the gdbserver code, and so now it is simple to move the two functions along with all their support functions from the gdbserver directory into the gdb/nat/ directory, and then GDB is fine to call these functions. One small curiosity with this patch is the function x86_linux_post_init_tdesc. On the gdbserver side the two functions amd64_linux_read_description and i386_linux_read_description have some functionality that is not present on the GDB side, that is some additional configuration that is performed as each target description is created to setup the expedited registers. To support this I've added the function x86_linux_post_init_tdesc. This function is called from the two *_linux_read_description functions, but is implemented separately for GDB and gdbserver. This does mean adding back some non-shared code when this whole series has been about sharing code, but now the only non-shared bit is the single line that is actually different between GDB and gdbserver, all the rest, which is identical, is now shared. I did need to add a new rule to the gdbserver Makefile, this is to allow the nat/x86-linux-tdesc.c file to be compiled for the IPA. Approved-By: John Baldwin <jhb@FreeBSD.org>	3 years ago
Andrew Burgess	61bb321605	gdbserver: update target description creation for x86/linux This commit is part of a series which aims to share more of the target description creation between GDB and gdbserver for x86/Linux. After some refactoring, the previous commit actually started to share some code, we added the shared x86_linux_tdesc_for_tid function into nat/x86-linux-tdesc.c. However, this function still relies on amd64_linux_read_description and i386_linux_read_description which are implemented separately for both gdbserver and GDB. Given that at their core, all these functions to is: 1. take an xcr0 value as input, 2. mask out some feature bits, 3. look for a cached pre-generated target description and return it if found, 4. if no cached target description is found then call either amd64_create_target_description or i386_create_target_description to create a new target description, which is then added to the cache. Return the newly created target description. The inner functions amd64_create_target_description and i386_create_target_description are already shared between GDB and gdbserver (in the gdb/arch/ directory), so the only thing that the _read_description functions really do is add the caching layer, and it feels like this really could be shared. However, we have a small problem. On the GDB side we create target descriptions using a different set of cpu features than on the gdbserver side! This means that for the exact same target, we might get a different target description when using native GDB vs using gdbserver. This surely feels like a mistake, I would expect to get the same target description on each. The table below shows the number of possible different target descriptions that we can create on the GDB side vs on the gdbserver side for each target type: \| GDB \| gdbserver ------\|-----\|---------- i386 \| 64 \| 7 amd64 \| 32 \| 7 x32 \| 16 \| 7 So in theory, all I want to do is move the GDB version of _read_description into the nat/ directory and have gdbserver use that, then both GDB and gdbserver would be able to create any of the possible target descriptions. Unfortunately it's a little more complex than that due to the in process agent (IPA). When the IPA is in use, gdbserver sends a target description index to the IPA, and the IPA uses this to find the correct target description to use. START OF AN ASIDE Back in the day I suspect this approach made perfect sense. However since this commit: commit `a880623024` Date: Thu Dec 7 17:07:01 2017 +0000 Initialize target description early in IPA I think passing the index is now more trouble than its worth. We used to pass the index, and then use that index to lookup which target description to instantiate and use. However, the above commit fixed an issue where we can't call malloc() within (certain parts of) the IPA (apparently), so instead we now pre-compute _every_ possible target description within the IPA. The index is now only used to lookup which of the (many) pre-computed target descriptions to use. It would (I think) have been easier all around if the IPA just self-inspected, figured out its own xcr0 value, and used that to create the one target description that is required. So long as the xcr0 to target description code is shared (at compile time) with gdbserver, then we can be sure that the IPA will derive the same target description as gdbserver, and we would avoid all this index passing business, which has made this commit so very, very painful. END OF AN ASIDE Currently then for x86/linux, gdbserver sends a number between 0 and 7 to the IPA, and the IPA uses this to create a target description. However, I am proposing that gdbserver should now create one of (up to) 64 different target descriptions for i386, so this 0 to 7 index isn't going to be good enough any more (amd64 and x32 have slightly fewer possible target descriptions, but still more than 8, so the problem is the same). For a while I wondered if I was going to have to try and find some backward compatible solution for this mess. But after seeing how lightly the IPA is actually documented, I wonder if it is not the case that there is a tight coupling between a version of gdbserver and a version of the IPA? At least I'm hoping so. In this commit I have thrown out the old IPA target description index numbering scheme, and switched to a completely new numbering scheme. Instead of the index that is passed being arbitrary, the index is instead calculated from the set of cpu features that are present on the target. Within the IPA we can then reverse this logic to recreate the xcr0 value based on the index, and from the xcr0 value we can create the correct target description. With the gdbserver to IPA numbering scheme issue resolved I have then update the gdbserver versions of amd64_linux_read_description and i386_linux_read_description so that they create target descriptions using the same set of cpu features as GDB itself. After this gdbserver should now always come up with the same target description as GDB does on any x86/Linux target. This commit does not introduce any new code sharing between GDB and gdbserver as previous commits in this series does. Instead this commit is all about bringing GDB and gdbserver into alignment functionally so that the next commit can merge the GDB and gdbserver versions of these functions. Approved-By: John Baldwin <jhb@FreeBSD.org>	3 years ago
Andrew Burgess	cd9b374ffe	gdb/gdbserver: share some code relating to target description creation This commit is part of a series to share more of the x86 target description creation code between GDB and gdbserver. Unlike previous commits which were mostly refactoring, this commit is the first that makes a real change, though that change should mostly be for gdbserver; I've largely adopted the "GDB" way of doing things for gdbserver, and this fixes a real gdbserver bug. On a x86-64 Linux target, running the test: gdb.server/connect-with-no-symbol-file.exp results in two core files being created. Both of these core files are from the inferior process, created after gdbserver has detached. In this test a gdbserver process is started and then, after gdbserver has started, but before GDB attaches, we either delete the inferior executable, or change its permissions so it can't be read. Only after doing this do we attempt to connect with GDB. As GDB connects to gdbserver, gdbserver attempts to figure out the target description so that it can send the description to GDB, this involves a call to x86_linux_read_description. In x86_linux_read_description one of the first things we do is try to figure out if the process is 32-bit or 64-bit. To do this we look up the executable via the thread-id, and then attempt to read the architecture size from the executable. This isn't going to work if the executable has been deleted, or is no longer readable. And so, as we can't read the executable, we default to an i386 target and use an i386 target description. A consequence of using an i386 target description is that addresses are assumed to be 32-bits. Here's an example session that shows the problems this causes. This is run on an x86-64 machine, and the test binary (xx.x) is a standard 64-bit x86-64 binary: shell_1$ gdbserver --once localhost :54321 /tmp/xx.x shell_2$ gdb -q (gdb) set sysroot (gdb) shell chmod 000 /tmp/xx.x (gdb) target remote :54321 Remote debugging using :54321 warning: /tmp/xx.x: Permission denied. 0xf7fd3110 in ?? () (gdb) show architecture The target architecture is set to "auto" (currently "i386"). (gdb) p/x $pc $1 = 0xf7fd3110 (gdb) info proc mappings process 2412639 Mapped address spaces: Start Addr End Addr Size Offset Perms objfile 0x400000 0x401000 0x1000 0x0 r--p /tmp/xx.x 0x401000 0x402000 0x1000 0x1000 r-xp /tmp/xx.x 0x402000 0x403000 0x1000 0x2000 r--p /tmp/xx.x 0x403000 0x405000 0x2000 0x2000 rw-p /tmp/xx.x 0xf7fcb000 0xf7fcf000 0x4000 0x0 r--p [vvar] 0xf7fcf000 0xf7fd1000 0x2000 0x0 r-xp [vdso] 0xf7fd1000 0xf7fd3000 0x2000 0x0 r--p /usr/lib64/ld-2.30.so 0xf7fd3000 0xf7ff3000 0x20000 0x2000 r-xp /usr/lib64/ld-2.30.so 0xf7ff3000 0xf7ffb000 0x8000 0x22000 r--p /usr/lib64/ld-2.30.so 0xf7ffc000 0xf7ffe000 0x2000 0x2a000 rw-p /usr/lib64/ld-2.30.so 0xf7ffe000 0xf7fff000 0x1000 0x0 rw-p 0xfffda000 0xfffff000 0x25000 0x0 rw-p [stack] 0xff600000 0xff601000 0x1000 0x0 r-xp [vsyscall] (gdb) info inferiors Num Description Connection Executable * 1 process 2412639 1 (remote :54321) (gdb) shell cat /proc/2412639/maps 00400000-00401000 r--p 00000000 fd:03 45907133 /tmp/xx.x 00401000-00402000 r-xp 00001000 fd:03 45907133 /tmp/xx.x 00402000-00403000 r--p 00002000 fd:03 45907133 /tmp/xx.x 00403000-00405000 rw-p 00002000 fd:03 45907133 /tmp/xx.x 7ffff7fcb000-7ffff7fcf000 r--p 00000000 00:00 0 [vvar] 7ffff7fcf000-7ffff7fd1000 r-xp 00000000 00:00 0 [vdso] 7ffff7fd1000-7ffff7fd3000 r--p 00000000 fd:00 143904 /usr/lib64/ld-2.30.so 7ffff7fd3000-7ffff7ff3000 r-xp 00002000 fd:00 143904 /usr/lib64/ld-2.30.so 7ffff7ff3000-7ffff7ffb000 r--p 00022000 fd:00 143904 /usr/lib64/ld-2.30.so 7ffff7ffc000-7ffff7ffe000 rw-p 0002a000 fd:00 143904 /usr/lib64/ld-2.30.so 7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 7ffffffda000-7ffffffff000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] (gdb) Notice the difference between the mappings reported via GDB and those reported directly from the kernel via /proc/PID/maps, the addresses of every mapping is clamped to 32-bits for GDB, while the kernel reports real 64-bit addresses. Notice also that the $pc value is a 32-bit value. It appears to be within one of the mappings reported by GDB, but is outside any of the mappings reported from the kernel. And this is where the problem arises. When gdbserver detaches from the inferior we pass the inferior the address from which it should resume. Due to the 32/64 bit confusion we tell the inferior to resume from the 32-bit $pc value, which is not within any valid mapping, and so, as soon as the inferior resumes, it segfaults. If we look at how GDB (not gdbserver) figures out its target description then we see an interesting difference. GDB doesn't try to read the executable. Instead GDB uses ptrace to query the thread's state, and uses this to figure out the if the thread is 32 or 64 bit. If we update gdbserver to do it the "GDB" way then the above problem is resolved, gdbserver now sees the process as 64-bit, and when we detach from the inferior we give it the correct 64-bit address, and the inferior no longer segfaults. Now, I could just update the gdbserver code, but better, I think, to share one copy of the code between GDB and gdbserver in gdb/nat/. That is what this commit does. The cores of x86_linux_read_description from gdbserver and x86_linux_nat_target::read_description from GDB are moved into a new file gdb/nat/x86-linux-tdesc.c and combined into a single function x86_linux_tdesc_for_tid which is called from each location. This new function does things the GDB way, the only changes are to allow for the sharing; we now have a callback function to call the first time that the xcr0 state is read, this allows for GDB and gdbserver to perform their own initialisation as needed, and additionally, the new function takes a pointer for where to cache the xcr0 value, this isn't needed for this commit, but will be useful in a later commit where gdbserver will want to read this cached xcr0 value. Another thing to note about this commit is how the functions i386_linux_read_description and amd64_linux_read_description are handled. For now I've left these function as implemented separately in GDB and gdbserver. I've moved the declarations of these functions into gdb/nat/x86-linux-tdesc.h, but the implementations are left as separate. A later commit in this series will make these functions shared too, but doing this is not trivial, so I've left that for a separate commit. Merging the declarations as I've done here ensures that everyone implements the function to the same API, and once these functions are shared (in a later commit) we'll want a shared declaration anyway. Approved-By: John Baldwin <jhb@FreeBSD.org>	3 years ago
Andrew Burgess	7816b81e9b	gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and gdbserver. This commit is part of a series that aims to share more of the x86 target description creation code between GDB and gdbserver. The I386_LINUX_XSAVE_XCR0_OFFSET #define is used as part of the target description creation, and I noticed that this constant is defined separately for GDB and gdbserver. This commit moves the definition into gdb/nat/x86-linux.h, which allows the #define to be shared. There should be no user visible changes after this commit. Approved-By: John Baldwin <jhb@FreeBSD.org>	3 years ago
Andrew Burgess	0a7bb97ad2	gdbserver/x86: move no-xml code earlier in x86_linux_read_description This commit is part of a series that aims to share more of the x86 target description reading/generation code between GDB and gdbserver. There are a huge number of similarities between the code in gdbserver's x86_linux_read_description function and GDB's x86_linux_nat_target::read_description function, and it is this similarity that I plan, in a later commit, to share between GDB and gdbserver. However, one thing that is different in x86_linux_read_description is the code inside the '!use_xml' block. This is the code that handles the case where gdbserver is not allowed to send an XML target description back to GDB. In this case gdbserver uses some predefined, fixed, target descriptions. First, it's worth noting that I suspect this code is not tested any more. I couldn't find anything in the testsuite that tries to disable XML target description support. And the idea of having a single "fixed" target description really doesn't work well when we think about all the various x86 extensions that exist. Part of me would like to rip out the no-xml support in gdbserver (at least for x86), and if a GDB connects that doesn't support XML target descriptions, gdbserver can just give an error and drop the connection. GDB has supported XML target descriptions for 16 years now, I think it would be reasonable for our shipped gdbserver to drop support for the old way of doing things. Anyway.... this commit doesn't do that. What I did notice was that, over time, the '!use_xml' block appears to have "drifted" within the x86_linux_read_description function; it's now not the first check we do. Instead we make some ptrace calls and return a target description generated based on the result of these ptrace calls. Surely it only makes sense to generate variable target descriptions if we can send these back to GDB? So in this commit I propose to move the '!use_xml' block earlier in the x86_linux_read_description function. The benefit of this is that this leaves the later half of x86_linux_read_description much more similar to the GDB function x86_linux_nat_target::read_description and sets us up for potentially sharing code between GDB and gdbserver in a later commit. Approved-By: John Baldwin <jhb@FreeBSD.org>	3 years ago
Andrew Burgess	5920765d75	gdbserver: convert have_ptrace_getregset to a tribool Convert the have_ptrace_getregset global within gdbserver to a tribool. This brings the flag into alignment with the corresponding flag in GDB. The gdbserver have_ptrace_getregset variable is already used as a tribool, it just doesn't have the tribool type. In a future commit I plan to share more code between GDB and gdbserver, and having this variable be the same type in both code bases will make the sharing much easier. There should be no user visible changes after this commit. Approved-By: John Baldwin <jhb@FreeBSD.org>	3 years ago
H.J. Lu	4bb20a6244	gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32 Since MPX isn't available for x32, we should clear X86_XSTATE_MPX bits on x32. PR server/31511 * linux-x86-low.cc (x86_linux_read_description): Clear X86_XSTATE_MPX bits in xcr0 on x32. Reviewed-by: Felix Willgerodt <felix.willgerodt@intel.com>	2 years ago
Simon Marchi	da48217f31	gdbserver/linux: probe for libiconv in configure Make gdbserver's build system locate libiconv when building for Linux. Commit `07b3255c3b` ("Filter invalid encodings from Linux thread names") make libiconv madantory for building gdbserver on Linux. While trying to cross-compile gdb for xtensa-fsf-linux-uclibc (with a toolchain generated with crosstool-ng), I got: /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:48:10: fatal error: iconv.h: No such file or directory 48 \| #include <iconv.h> \| ^~~~~~~~~ I downloaded GNU libiconv, built it for that host, and installed it in an arbitrary directory. I had to modify the gdbserver build system to locate libiconv and use it, the result is this patch. I eventually found that crosstool-ng has a config option to make uclibc provide an implementation of iconv, which is of course much easier. But given that this patch is now written, I think it would be worth merging it, it could help some people who do not have iconv built-in their libc in the future (and may not have the luxury of rebuilding their libc like I do). Using AM_ICONV in configure.ac adds these options for configure (the same we have for gdb): --with-libiconv-prefix[=DIR] search for libiconv in DIR/include and DIR/lib --without-libiconv-prefix don't search for libiconv in includedir and libdir --with-libiconv-type=TYPE type of library to search for (auto/static/shared) It sets the `LIBICONV` variable with whatever is needed to link with libiconv, and adds the necessary `-I` flag to `CPPFLAGS`. To avoid unnecessarily linking against libiconv on hosts that don't need it, set `MAYBE_LIBICONV` with the contents of `LIBICONV` only if the host is Linux, and use `MAYBE_LIBICONV` in `Makefile.in`. Since libiconv is a hard requirement for Linux hosts, error out if it is not found. The bits in acinclude.m4 are similar to what we have in gdb/acinclude.m4. Update the top-level build system to support building against an in-tree libiconv (I did not test this part though). Something tells me that the all-gdbserver dependency on all-libiconv is unnecessary, since there is already a dependency of configure-gdbserver on all-libiconv (and all-gdbserver surely depends on configure-gdbserver). I just copied what's done for GDB though. ChangeLog: * Makefile.def: Add configure-gdbserver and all-gdbserver dependencies on all-libiconv. * Makefile.in: Re-generate. Change-Id: I90f8ef88dd4917df5a68b45550d93622fc9cfed4 Approved-By: Tom Tromey <tom@tromey.com>	2 years ago
Thiago Jung Bauermann	bbb12eb9c8	gdb/arm: Remove tpidruro register from non-FreeBSD target descriptions Commit `92d48a1e4e` ("Add an arm-tls feature which includes the tpidruro register from CP15.") introduced the org.gnu.gdb.arm.tls feature, which adds the tpidruro register, and unconditionally enabled it in aarch32_create_target_description. In Linux, the tpidruro register isn't available via ptrace in the 32-bit kernel but it is available for an aarch32 program running under an arm64 kernel via the ptrace compat interface. This isn't currently implemented however, which causes GDB on arm-linux with 64-bit kernel to list the register but show it as unavailable, as reported by Tom de Vries: $ gdb -q -batch a.out -ex start -ex 'p $tpidruro' Temporary breakpoint 1 at 0x512 Temporary breakpoint 1, 0xaaaaa512 in main () $1 = <unavailable> Simon Marchi then clarified: > The only time we should be seeing some "unavailable" registers or memory > is in the context of tracepoints, for things that are not collected. > Seeing an unavailable register here is a sign that something is not > right. Therefore, disable the TLS feature in aarch32 target descriptions for Linux and NetBSD targets (the latter also doesn't seem to support accessing tpidruro either, based on a quick look at arm-netbsd-nat.c). This patch fixes the following tests: Running gdb.base/inline-frame-cycle-unwind.exp ... FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 3: backtrace when the unwind is broken at frame 3 FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: backtrace when the unwind is broken at frame 5 FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1 Tested with Ubuntu 22.04.3 on armv8l-linux-gnueabihf in native, native-gdbserver and native-extended-gdbserver targets with no regressions. PR tdep/31418 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31418 Approved-By: John Baldwin <jhb@FreeBSD.org>	2 years ago
Tiezhu Yang	4a4fd10d17	gdb: Modify the output of "info breakpoints" and "delete breakpoints" The output of "info breakpoints" includes breakpoint, watchpoint, tracepoint, and catchpoint if they are created, so it should show all the four types are deleted in the output of "info breakpoints" to report empty list after "delete breakpoints". It should also change the output of "delete breakpoints" to make it clear that watchpoints, tracepoints, and catchpoints are also being deleted. This is suggested by Guinevere Larsen, thank you. $ make check-gdb TESTS="gdb.base/access-mem-running.exp" $ gdb/gdb gdb/testsuite/outputs/gdb.base/access-mem-running/access-mem-running [...] (gdb) break main Breakpoint 1 at 0x12000073c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 32. (gdb) watch global_counter Hardware watchpoint 2: global_counter (gdb) trace maybe_stop_here Tracepoint 3 at 0x12000071c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 27. (gdb) catch fork Catchpoint 4 (fork) (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x000000012000073c in main at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:32 2 hw watchpoint keep y global_counter 3 tracepoint keep y 0x000000012000071c in maybe_stop_here at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:27 not installed on target 4 catchpoint keep y fork Without this patch: (gdb) delete breakpoints Delete all breakpoints? (y or n) y (gdb) info breakpoints No breakpoints or watchpoints. (gdb) info breakpoints 3 No breakpoint or watchpoint matching '3'. With this patch: (gdb) delete breakpoints Delete all breakpoints, watchpoints, tracepoints, and catchpoints? (y or n) y (gdb) info breakpoints No breakpoints, watchpoints, tracepoints, or catchpoints. (gdb) info breakpoints 3 No breakpoint, watchpoint, tracepoint, or catchpoint matching '3'. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Approved-by: Kevin Buettner <kevinb@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>	3 years ago
Simon Marchi	aca8a74923	gdb: remove some GCC version checks Since we now require C++17, and therefore gcc >= 9, it's no longer useful to have gcc version checks for older gcc version. Change-Id: I3a87baa03c475f2b847b422b16b69c5ff7215b54 Reviewed-by: Kevin Buettner <kevinb@redhat.com> Approved-By: Pedro Alves <pedro@palves.net>	3 years ago
Pedro Alves	38065394e9	Fix crash in aarch64-linux gdbserver Since commit `393a6b5947` ("Thread options & clone events (Linux GDBserver)"), aarch64-linux gdbserver crashes when the inferior vforks. This happens in aarch64_get_debug_reg_state: struct process_info *proc = find_process_pid (pid); return &proc->priv->arch_private->debug_reg_state; Here, find_process_pid returns nullptr -- the new inferior hasn't yet been created in linux_process_target::handle_extended_wait. This patch fixes the problem by having linux_process_target::handle_extended_wait create the child process earlier, before the child LWP is created. This is what the function did before it was reorganized by the commit referred above. Change-Id: Ib8b3a2e6048c3ad2b91a92ea4430da507db03c50 Co-Authored-By: Tom Tromey <tromey@adacore.com>	3 years ago
Feiyang Chen	e4d74c01e7	gdb: LoongArch: Add LBT extension support Loongson Binary Translation (LBT) is used to accelerate binary translation, which contains 4 scratch registers (scr0 to scr3), x86/ARM eflags (eflags) and x87 fpu stack pointer (ftop). This patch support gdb to fetch/store these registers. Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn> # Framework Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> # Detail Optimizes Signed-off-by: Hui Li <lihui@loongson.cn> # Error Fixes Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>	3 years ago
Hui Li	1e9569f383	gdb: LoongArch: Add vector extensions support Add LoongArch's vector extensions support, which including 128bit LSX (i.e., Loongson SIMD eXtension) and 256bit LASX (i.e., Loongson Advanced SIMD eXtension). This patch support gdb to fetch/store vector registers. Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>	3 years ago
Tom Tromey	a197d5f7eb	Really fix Windows gdbserver segment registers My earlier attempt to mask the segment registers in gdbserver for Windows introduced some bugs. That patch is here: https://sourceware.org/pipermail/gdb-patches/2023-December/205306.html The problem turned out to be that these fields in the Windows 'CONTEXT' type are just 16 bits, so while masking the values on read is fine, writing the truncated values back then causes zeros to be written to some subsequent field. This patch cleans this up by arranging never to write too much data to a field. I also noticed that two register numbers here were never updated for the 64-bit port. This patch fixes this as well, and renames the "FCS" register to follow gdb. Finally, this patch applies the same treatment to windows-nat.c. Reviewed-by: John Baldwin <jhb@FreeBSD.org>	3 years ago
Andrew Burgess	1d506c26d9	Update copyright year range in header of all files managed by GDB This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.	3 years ago
Mike Frysinger	761ed61e7b	gdbsupport: tighten up libiberty code a bit with dnl No functional change here, just touch up generated output slightly. Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Mike Frysinger	908ff469f5	gdb: libiberty: switch to AC_CHECK_DECLS_ONCE Only check these decls once in case other m4 macros also look for them. Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Mike Frysinger	3f258212a8	gdb: move libiberty.m4 to gdbsupport This is used by gdb, gdbsupport, and gdbserver. We want to use it in the sim tree too. Move it to gdbsupport which is meant as the common sharing space for these projects. Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Tom Tromey	862180a2d1	Fix two bugs in gdbserver thread name handling Simon pointed out that my earlier patch to gdbserver's thread name code: commit `07b3255c3b` Author: Tom Tromey <tom@tromey.com> Date: Thu Jul 13 17:28:48 2023 -0600 Filter invalid encodings from Linux thread names ... introduced a regression. This bug was that the iconv output was not \0-terminated. Looking at it, I found another bug as well -- replace_non_ascii would not \0-terminate, and also would return the wrong pointer This patch fixes both of them. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31153	3 years ago
Simon Marchi	51e6b8cfd6	gdb: change regcache interface to use array_view Change most of regcache (and base classes) to use array_view when possible, instead of raw pointers. By propagating the use of array_view further, it enables having some runtime checks to make sure the what we read from or write to regcaches has the expected length (such as the one in the `copy(array_view, array_view)` function. It also integrates well when connecting with other APIs already using gdb::array_view. Add some overloads of the methods using raw pointers to avoid having to change all call sites at once (which is both a lot of work and risky). I tried to do this change in small increments, but since many of these functions use each other, it ended up simpler to do it in one shot than having a lot of intermediary / transient changes. This change extends into gdbserver as well, because there is some part of the regcache interface that is shared. Changing the reg_buffer_common interface to use array_view caused some build failures in nat/aarch64-scalable-linux-ptrace.c. That file currently "takes advantage" of the fact that reg_buffer_common::{raw_supply,raw_collect} operates on `void `, which IMO is dangerous. It uses raw_supply/raw_collect directly on uint64_t's, which I guess is fine because it is expected that native code will have the same endianness as the debugged process. To accomodate that, add some overloads of raw_collect and raw_supply that work on uint64_t. This file also uses raw_collect and raw_supply on `char` pointers. Change it to use `gdb_byte` pointers instead. Add overloads of raw_collect and raw_supply that work on `gdb_byte ` and make an array_view on the fly using the register's size. Those call sites could be converted to use array_view with not much work, in which case these overloads could be removed, but I didn't want to do it in this patch, to avoid starting to dig in arch-specific code. During development, I inadvertently changed reg_buffer::raw_compare's behavior to not accept an offset equal to the register size. This behavior (effectively comparing 0 bytes, returning true) change was caught by the AArch64 SME core tests. Add a selftest to make sure that this raw_compare behavior is preserved in the future. Change-Id: I9005f04114543ddff738949e12d85a31855304c2 Reviewed-By: John Baldwin <jhb@FreeBSD.org>	3 years ago
Simon Marchi	e4e20d4511	gdb: use reg_buffer_common throughout gdbsupport/common-regcache.h Right now, gdbsupport/common-regcache.h contains two abstractons for a regcache. An opaque type `regcache` (gdb and gdbserver both have their own regcache that is the concrete version of this) and an abstract base class `reg_buffer_common`, that is the base of regcaches on both sides. These abstractions allow code to be written for both gdb and gdbserver, for instance in the gdb/arch sub-directory. However, having two different abstractions is impractical. If some common code has a regcache, and wants to use an operation defined on reg_buffer_common, it can't. It would be better to have just one. Change all instances of `regcache ` in gdbsupport/common-regcache.h to be `reg_buffer_common `, then fix fallouts. Implementations in gdb and gdbserver now need to down-cast (using gdb::checked_static_cast) from reg_buffer_common to their concrete regcache type. Some of them could be avoided by changing free functions (like regcache_register_size) to be virtual methods on reg_buffer_common. I tried it, it seems to work, but I did not include it in this series to avoid adding unnecessary changes. Change-Id: Ia5503adb6b5509a0f4604bd2a68b4642cc5283fd Reviewed-by: John Baldwin <jhb@FreeBSD.org>	3 years ago
Stefano Moioli	fa659800b0	gdbserver/win32: fix crash on detach this patch fixes a crash in gdbserver whenever a process is detached. the crash is caused by `detach` calling `remove_process` before `win32_clear_inferiors` error message: Detaching from process 184 ../../gdbserver/inferiors.cc:160: A problem internal to GDBserver has been detec ted. remove_process: Assertion `find_thread_process (process) == NULL' failed. This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Andrew Burgess	8fd5a6058f	gdbserver: allow for general 'monitor set debug COMPONENT VALUE' use Building on the last commit, which added a general --debug=COMPONENT option to the gdbserver command line, this commit updates the monitor command to allow for general: (gdb) monitor set debug COMPONENT off\|on style commands. Just like with the previous commit, the COMPONENT can be any one of all, threads, remote, event-loop, and correspond to the same set of global debug flags. While on the command line it is possible to do: --debug=remote,event-loop,threads the components have to be entered one at a time with the monitor command. I guess there's no reason why we couldn't allow component grouping within the monitor command, but (to me) what I have here seemed more in the spirit of GDB's existing 'set debug ...' commands. If people want it then we can always add component grouping later. Notice in the above that I use 'off' and 'on' instead of '0' and '1', which is what the 'monitor set debug' command used to use. The 0/1 can still be used, but I now advertise off/on in all the docs and help text, again, this feels more inline with GDB's existing boolean settings. I have removed the two existing monitor commands: monitor set remote-debug 0\|1 monitor set event-loop-debug 0\|1 These are replaced by: monitor set debug remote off\|on monitor set debug event-loop off\|on respectively. Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>	3 years ago
Andrew Burgess	3bf9e166ca	gdbserver: allow the --debug command line option to take a value Currently, gdbserver has the following command line options related to debugging output: --debug --remote-debug --event-loop-debug This doesn't scale well. If I want an extra debug component I need to add another command line flag. This commit changes --debug to take a list of components. The currently supported components are: all, threads, remote, and event-loop. The 'threads' component represents the debug we currently get from the --debug option. And if --debug is used without a component list then the threads component is assumed as the default. Currently the threads component actually includes a lot of output that is not really threads related. In the future I'd like to split this up into some new, separate components. But that is not part of this commit, or even this series. The special component 'all' does what you'd expect: enables debug output from all supported components. The component list is parsed left to write, and you can prefix a component with '-' to disable that component, so I can write: target> gdbserver --debug=all,-event-loop to get debug for all components except the event-loop component. I've removed the existing --remote-debug and --event-loop-debug command line options, these are equivalent to --debug=remote and --debug=event-loop respectively, or --debug=remote,event-loop to enable both components. In this commit I've only update the command line options, in the next commit I'll update the monitor commands to support a similar interface. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Tom Tromey	74bbf9359a	Update fall-through comment in gdbserver I noticed that gdbserver/win32-low.cc has a fall-through comment that should have been converted to use the annotation instead. This patch makes the change.	3 years ago
Tom Tromey	c6f7f9c80c	Bail out of "attach" if a thread cannot be traced On Linux, threads are treated much like separate processes by the kernel. In particular, it's possible to ptrace just a single thread. If gdb tries to attach to a multi-threaded inferior, where a non-main thread is already being traced (e.g., by strace), then gdb will get into an infinite loop attempting to attach. This patch fixes this problem by having the attach fail if ptrace fails to attach to any thread of the inferior.	3 years ago
Tom Tromey	69f6730df3	Remove gdb_static_assert C++17 makes the second parameter to static_assert optional, so we can remove gdb_static_assert now.	3 years ago
Tom Tromey	d57f38ec74	Switch to -Wimplicit-fallthrough=5 This changes the various gdb-related directories to use -Wimplicit-fallthrough=5, meaning that only the fallthrough attribute can be used in switches -- special 'fallthrough' comments will no longer be usable. Approved-By: Pedro Alves <pedro@palves.net>	3 years ago
Tom Tromey	d182e39881	Use C++17 [[fallthrough]] attribute This changes gdb to use the C++17 [[fallthrough]] attribute rather than special comments. This was mostly done by script, but I neglected a few spellings and so also fixed it up by hand. I suspect this fixes the bug mentioned below, by switching to a standard approach that, presumably, clang supports. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159 Approved-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Pedro Alves <pedro@palves.net>	3 years ago
Tom Tromey	602971b386	Introduce throw_winerror_with_name This introduces throw_winerror_with_name, a Windows analog of perror_with_name, and changes various places in gdb to call it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770	3 years ago
Andrew Burgess	27365c5189	gdbserver: cleanup monitor_show_help After this commit: commit `0b04e52316` Date: Sun Jan 19 14:33:37 2014 -0700 link gdbserver against libiberty we can cleanup how the help text is generated in monitor_show_help. This doesn't change the output that the user will see -- it just folds multiple monitor_output calls into one. There should be no user visible change after this commit.	3 years ago
Lancelot Six	6b09f1342c	gdb: Replace gdb::optional with std::optional Since GDB now requires C++17, we don't need the internally maintained gdb::optional implementation. This patch does the following replacing: - gdb::optional -> std::optional - gdb::in_place -> std::in_place - #include "gdbsupport/gdb_optional.h" -> #include <optional> This change has mostly been done automatically. One exception is gdbsupport/thread-pool.* which did not use the gdb:: prefix as it already lives in the gdb namespace. Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>	3 years ago
Sam James	9e11e7460d	Finalized intl-update patches (deux) Doing this on behalf of Arsen as obvious. * gdb: Regenerate. * gdbserver: Regenerate. * gprofng: Regenerate.	3 years ago
Tom Tromey	07b3255c3b	Filter invalid encodings from Linux thread names On Linux, a thread can only be 16 bytes (including the trailing \0). A user sent in a test case where this causes a truncated UTF-8 sequence, causing gdbserver to create invalid XML. I went back and forth about different ways to solve this, and in the end decided to fix it in gdbserver, with the reason being that it seems important to generate correct XML for the <thread> response. I am not totally sure whether the call to setlocale could have unplanned consequences. This is needed, though, for nl_langinfo to return the correct result. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30618	3 years ago
Pedro Alves	e8a625d126	Report thread exit event for leader if reporting thread exit events If GDB sets the GDB_THREAD_OPTION_EXIT option on a thread, then if the thread disappears from the thread list, GDB expects to shortly see a thread exit event for it. See e.g., here, in remote_target::update_thread_list(): /* Do not remove the thread if we've requested to be notified of its exit. For example, the thread may be displaced stepping, infrun will need to handle the exit event, and displaced stepping info is recorded in the thread object. If we deleted the thread now, we'd lose that info. / if ((tp->thread_options () & GDB_THREAD_OPTION_EXIT) != 0) continue; There's one scenario that is deleting a thread from the remote/gdbserver thread list without ever reporting a corresponding thread exit event though -- check_zombie_leaders. This can lead to GDB getting confused. For example, with a following patch that enables GDB_THREAD_OPTION_EXIT whenever schedlock is enabled, we'd see this regression: $ make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" TESTS="gdb.threads/no-unwaited-for-left.exp" ... Running src/gdb/testsuite/gdb.threads/no-unwaited-for-left.exp ... FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits (timeout) ... some more cascading FAILs ... gdb.log shows: (gdb) continue Continuing. FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits (timeout) A passing run would have resulted in: (gdb) continue Continuing. No unwaited-for children left. (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits note how the leader thread is not listed in the remote-reported XML thread list below: (gdb) set debug remote 1 (gdb) set debug infrun 1 (gdb) info threads Id Target Id Frame 1 Thread 1163850.1163850 "no-unwaited-for" main () at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/no-unwaited-for-left.c:65 3 Thread 1163850.1164130 "no-unwaited-for" [remote] Sending packet: $Hgp11c24a.11c362#39 (gdb) c Continuing. [infrun] clear_proceed_status_thread: 1163850.1163850.0 ... [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [1163850.1163850.0] at 0x55555555534f [remote] Sending packet: $QPassSignals:#f3 [remote] Packet received: OK [remote] Sending packet: $QThreadOptions;3:p11c24a.11c24a#f3 [remote] Packet received: OK ... [infrun] target_set_thread_options: [options for Thread 1163850.1163850 are now 0x3] ... [infrun] do_target_resume: resume_ptid=1163850.1163850.0, step=0, sig=GDB_SIGNAL_0 [remote] Sending packet: $vCont;c:p11c24a.11c24a#98 [infrun] prepare_to_wait: prepare_to_wait [infrun] reset: reason=handling event [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote [infrun] fetch_inferior_event: exit [infrun] fetch_inferior_event: enter [infrun] scoped_disable_commit_resumed: reason=handling event [infrun] random_pending_event_thread: None found. [remote] wait: enter [remote] Packet received: N [remote] wait: exit [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = [infrun] print_target_wait_results: -1.0.0 [process -1], [infrun] print_target_wait_results: status->kind = NO_RESUMED [infrun] handle_inferior_event: status->kind = NO_RESUMED [remote] Sending packet: $Hgp0.0#ad [remote] Packet received: OK [remote] Sending packet: $qXfer:threads:read::0,1000#92 [remote] Packet received: l<threads>\n<thread id="p11c24a.11c362" core="0" name="no-unwaited-for" handle="0097d8f7ff7f0000"/>\n</threads>\n [infrun] handle_no_resumed: TARGET_WAITKIND_NO_RESUMED (ignoring: found resumed) ... ... however, infrun decided there was a resumed thread still, so ignored the TARGET_WAITKIND_NO_RESUMED event. Debugging GDB, we see that the "found resumed" thread that GDB finds, is the leader thread. Even though that thread is not on the remote-reported thread list, it is still on the GDB thread list, due to the special case in remote.c mentioned above. This commit addresses the issue by fixing GDBserver to report a thread exit event for the zombie leader too, i.e., making GDBserver respect the "if thread has GDB_THREAD_OPTION_EXIT set, report a thread exit" invariant. To do that, it takes a bit more code than one would imagine off hand, due to the fact that we currently always report LWP exit pending events as TARGET_WAITKIND_EXITED, and then decide whether to convert it to TARGET_WAITKIND_THREAD_EXITED just before reporting the event to GDBserver core. For the zombie leader scenario described, we need to record early on that we want to report a THREAD_EXITED event, and then make sure that decision isn't lost along the way to reporting the event to GDBserver core. Reviewed-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I1e68fccdbc9534434dee07163d3fd19744c8403b	4 years ago
Pedro Alves	ef980d654b	gdbserver: Queue no-resumed event after thread exit Normally, if the last resumed thread on the target exits, the server sends a no-resumed event to GDB. If however, GDB enables the GDB_THREAD_OPTION_EXIT option on a thread, and, that thread exits, the server sends a thread exit event for that thread instead. In all-stop RSP mode, since events can only be forwarded to GDB one at a time, and the whole target stops whenever an event is reported, GDB resumes the target again after getting a THREAD_EXITED event, and then the server finally reports back a no-resumed event if/when appropriate. For non-stop RSP though, events are asynchronous, and if the server sends a thread-exit event for the last resumed thread, the no-resumed event is never sent. This patch makes sure that in non-stop mode, the server queues a no-resumed event after the thread-exit event if it was the last resumed thread that exited. Without this, we'd see failures in step-over-thread-exit testcases added later in the series, like so: continue Continuing. - No unwaited-for children left. - (gdb) PASS: gdb.threads/step-over-thread-exit.exp: displaced-stepping=off: non-stop=on: target-non-stop=on: schedlock=off: ns_stop_all=1: continue stops when thread exits + FAIL: gdb.threads/step-over-thread-exit.exp: displaced-stepping=off: non-stop=on: target-non-stop=on: schedlock=off: ns_stop_all=1: continue stops when thread exits (timeout) (and other similar ones) Reviewed-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I927d78b30f88236dbd5634b051a716f72420e7c7	4 years ago

1 2 3 4 5 ...

465 Commits (34d5ac9244ccfe566232469ec3bef1329f0bc42e)