- 20 Sep, 2019 2 commits
-
-
Joel Brobecker authored
gdb/ChangeLog: * version.in: Set GDB version number to 8.3.1.
-
GDB Administrator authored
-
- 19 Sep, 2019 3 commits
-
-
Tom Tromey authored
[ Backport of master commit d806ea2d. ] Currently, no release of GNU Source Highlight supports Rust. However, I've checked in a patch to do so there, and I plan to make a new release sometime this summer. This patch prepares gdb for that by adding support for Rust to the source highlighting code. Because Source Highlight will throw an exception if the language is unrecognized, this also changes gdb to ignore exceptions here. This will cause gdb to fall back to un-highlighted source text. This updates gdb's configure script to reject the combination of Source Highlight and -static-libstdc++. This is done because it's not possible to use -static-libstdc++ and then catch exceptions from a shared library. Tested with the current and development versions of Source Highlight. gdb/ChangeLog 2019-08-19 Tom Tromey <tom@tromey.com> PR gdb/25009 * configure: Rebuild. * configure.ac: Disallow the combination of -static-libstdc++ and source highlight. * source-cache.c (get_language_name): Handle rust. (source_cache::get_source_lines): Ignore highlighting exceptions.
-
Tom Tromey authored
[ Backport of master commit c1a5d03a. ] gdb should normally not be linked with -static-libstdc++. Currently this has not caused problems, but it's incompatible with catching an exception thrown from a shared library -- and a subsequent patch changes gdb to do just this. This patch adds a new --with-static-standard-libraries flag to the top-level configure. It defaults to "auto", which means enabled if gcc is being built, and disabled otherwise. ChangeLog 2019-08-19 Tom Tromey <tom@tromey.com> PR gdb/25009 * configure: Rebuild. * configure.ac: Add --with-static-standard-libraries.
-
GDB Administrator authored
-
- 18 Sep, 2019 5 commits
-
-
Tom de Vries authored
-
Tom de Vries authored
-
Tom de Vries authored
-
Tom de Vries authored
-
GDB Administrator authored
-
- 17 Sep, 2019 3 commits
-
-
Tom de Vries authored
[ Backport of master commit d2b584a5. ] When running gdb-caching-proc.exp, if skip_opencl_tests fails like this: ... (gdb) run Starting program: \ build/gdb/testsuite/outputs/gdb.base/gdb-caching-proc/opencltest13530.x CHK_ERR (clGetPlatformIDs (1, &platform, NULL), -1001) src/gdb/testsuite/lib/opencl_hostapp.c:73 error: Unknown [Inferior 1 (process 13600) exited with code 01] (gdb) skip_opencl_tests: OpenCL support not detected ... then this regexp in skip_opencl_tests fails to match: ... -re ".*$inferior_exited_re code.*${gdb_prompt} $" { ... so instead we hit the default clause after a 30 seconds timeout. With the iteration count set at 10, we end up taking 6 minutes to run this test-case. Fix this by adding the missing "with" in the regexp, bring back the runtime to half a minute. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-04-29 Tom de Vries <tdevries@suse.de> PR testsuite/25005 * lib/opencl.exp (skip_opencl_tests): Add missing "with" in regexp.
-
Sergio Durigan Junior authored
Update ChangeLog entry of commit e9224f6d and mention PR breakpoints/24541
-
GDB Administrator authored
-
- 16 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 15 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 14 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 13 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 12 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 11 Sep, 2019 3 commits
-
-
Sergio Durigan Junior authored
[ Backport of master commit 7d7571f0. ] This bug has been reported on PR breakpoints/24541, but it is possible to reproduce it easily by running: make check-gdb TESTS=gdb.base/stap-probe.exp RUNTESTFLAGS='--target_board unix/-m32' The underlying cause is kind of complex, and involves decisions made by GCC and the sys/sdt.h header file about how to represent a probe argument that lives in a register in 32-bit programs. I'll use Andrew's example on the bug to illustrate the problem. libstdc++ has a probe named "throw" with two arguments. On i386, the probe is: stapsdt 0x00000028 NT_STAPSDT (SystemTap probe descriptors) Provider: libstdcxx Name: throw Location: 0x00072c96, Base: 0x00133d64, Semaphore: 0x00000000 Arguments: 4@%si 4@%di I.e., the first argument is an unsigned 32-bit value (represented by the "4@") that lives on %si, and the second argument is an unsigned 32-bit value that lives on %di. Note the discrepancy between the argument size reported by the probe (32-bit) and the register size being used to store the value (16-bit). However, if you take a look at the disassemble of a program that uses this probe, you will see: 00072c80 <__cxa_throw@@CXXABI_1.3>: 72c80: 57 push %edi 72c81: 56 push %esi 72c82: 53 push %ebx 72c83: 8b 74 24 10 mov 0x10(%esp),%esi 72c87: e8 74 bf ff ff call 6ec00 <__cxa_finalize@plt+0x980> 72c8c: 81 c3 74 e3 10 00 add $0x10e374,%ebx 72c92: 8b 7c 24 14 mov 0x14(%esp),%edi 72c96: 90 nop <----------------- PROBE IS HERE 72c97: e8 d4 a2 ff ff call 6cf70 <__cxa_get_globals@plt> 72c9c: 83 40 04 01 addl $0x1,0x4(%eax) 72ca0: 83 ec 04 sub $0x4,%esp 72ca3: ff 74 24 1c pushl 0x1c(%esp) 72ca7: 57 push %edi 72ca8: 56 push %esi 72ca9: e8 62 a3 ff ff call 6d010 <__cxa_init_primary_exception@plt> 72cae: 8d 70 40 lea 0x40(%eax),%esi 72cb1: c7 00 01 00 00 00 movl $0x1,(%eax) 72cb7: 89 34 24 mov %esi,(%esp) 72cba: e8 61 96 ff ff call 6c320 <_Unwind_RaiseException@plt> 72cbf: 89 34 24 mov %esi,(%esp) 72cc2: e8 c9 84 ff ff call 6b190 <__cxa_begin_catch@plt> 72cc7: e8 d4 b3 ff ff call 6e0a0 <_ZSt9terminatev@plt> 72ccc: 66 90 xchg %ax,%ax 72cce: 66 90 xchg %ax,%ax Note how the program is actually using %edi, and not %di, to store the second argument. This is the problem here. GDB will basically read the probe argument, then read the contents of %di, and then cast this value to uint32_t, which causes the wrong value to be obtained. In the gdb.base/stap-probe.exp case, this makes GDB read the wrong memory location, and not be able to display a test string. In Andrew's example, this causes GDB to actually stop at a "catch throw" when it should actually have *not* stopped. After some discussion with Frank Eigler and Jakub Jelinek, it was decided that this bug should be fixed on the client side (i.e., the program that actually reads the probes), and this is why I'm proposing this patch. The idea is simple: we will have a gdbarch method, which, for now, is only used by i386. The generic code that deals with register operands on gdb/stap-probe.c will call this method if it exists, passing the current parse information, the register name and its number. The i386 method will then verify if the register size is greater or equal than the size reported by the stap probe (the "4@" part). If it is, we're fine. Otherwise, it will check if we're dealing with any of the "extendable" registers (like ax, bx, si, di, sp, etc.). If we are, it will change the register name to include the "e" prefix. I have tested the patch here in many scenarios, and it fixes Andrew's bug and also the regressions I mentioned before, on gdb.base/stap-probe.exp. No regressions where found on other tests. Comments? gdb/ChangeLog: 2019-06-27 Sergio Durigan Junior <sergiodj@redhat.com> PR breakpoints/24541 * gdbarch.c: Regenerate. * gdbarch.h: Regenerate. * gdbarch.sh: Add 'stap_adjust_register'. * i386-tdep.c: Include '<unordered_set>'. (i386_stap_adjust_register): New function. (i386_elf_init_abi): Register 'i386_stap_adjust_register'. * stap-probe.c (stap_parse_register_operand): Call 'gdbarch_stap_adjust_register'.
-
Sergio Durigan Junior authored
[ Backport of master commit 677052f2. ] This patch simplifies the code of stap-probe.c:stap_parse_register_operand by making "regname" an std::string. No functionality change. I'm this code's maintainer, so I'm pushing this as it's a fairly trivial patch. gdb/ChangeLog: 2019-05-16 Sergio Durigan Junior <sergiodj@redhat.com> * stap-probe.c (stap_parse_register_operand): Make "regname" an "std::string", simplifying the algorithm.
-
GDB Administrator authored
-
- 10 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 09 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 08 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 07 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 06 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 05 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 04 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 03 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 02 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 01 Sep, 2019 1 commit
-
-
GDB Administrator authored
-
- 31 Aug, 2019 1 commit
-
-
GDB Administrator authored
-
- 30 Aug, 2019 1 commit
-
-
GDB Administrator authored
-
- 29 Aug, 2019 1 commit
-
-
GDB Administrator authored
-
- 28 Aug, 2019 1 commit
-
-
GDB Administrator authored
-
- 27 Aug, 2019 1 commit
-
-
GDB Administrator authored
-
- 26 Aug, 2019 1 commit
-
-
GDB Administrator authored
-
- 25 Aug, 2019 1 commit
-
-
GDB Administrator authored
-
- 24 Aug, 2019 1 commit
-
-
GDB Administrator authored
-
- 23 Aug, 2019 1 commit
-
-
GDB Administrator authored
-