- 23 May, 2020 4 commits
-
-
Joel Brobecker authored
This change is needed, now that the version in gdb/version.in has been bumped from 9.1 to 9.2. gdb/testsuite/ChangeLog: * gdb.base/default.exp: Change expected value for $_gdb_minor to 2.
-
Joel Brobecker authored
gdb/ChangeLog: * version.in: Set GDB version number to 9.2.
-
Christian Biesinger authored
This was a typo introduced in f6ac5f3d. Found by looking through NetBSD's GDB patches: https://github.com/NetBSD/pkgsrc-wip/blob/master/gdb-netbsd/patches/patch-gdb_sparc-nat.h This patch can't be tested on Linux because Linux does not use the sparc_target template. gdb/ChangeLog: 2020-05-23 Christian Biesinger <cbiesinger@google.com> PR gdb/26029: * sparc-nat.h (struct sparc_target) <xfer_partial>: Fix base class function call. Change-Id: I4fa88cbdc365efe89b84cc0619b60db38718d9ce (cherry picked from commit c6a42d11)
-
GDB Administrator authored
-
- 22 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 21 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 20 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 19 May, 2020 3 commits
-
-
Rainer Orth authored
This is the 32-bit companion to Remove unused ps_lgetLDT etc. on Solaris/x86 [PR25981] https://sourceware.org/pipermail/gdb-patches/2020-May/168713.html A 32-bit-default gdb fails to compile with the updated <sys/regset.h>. While it is also affected by the lack of a GS definition, which the compantion patch above fixes, it also fails to compile i386-sol2-nat.c like this /vol/src/gnu/gdb/hg/master/git/gdb/i386-sol2-nat.c:181:3: error: 'EAX' was not declared in this scope 181 | EAX, ECX, EDX, EBX, | ^~~ and several more. While this could be fixed by either including <ucontext.h> here or provding fallback definitions of the register macros, I chose to do what the 64-bit-default code in the same file (amd64_sol2_gregset32_reg_offset[]) does, namely just hardcode the numeric values instead. They are part of the ABI and thus guaranteed not to change. With this patch, a i386-pc-solaris2.11 configuration on master compiles again, however, it doesn't work. However, I could successfully test it on the gdb-9 branch. Compiling and testing proved to be messy, unfortunately: * For one, Solaris <sys/procfs.h> and largefile support used to be mutually exclusive (fixed in Solaris 11.4 and Illumos), which was exacerbated by the fact that g++ predefines _FILE_OFFSET_BITS=64 since GCC 9.1.0. For now I've worked around this by adding -U_FILE_OFFSET_BITS to CXXFLAGS and configuring with --disable-largefile. I hope to clean this up in a future patch. * gdb still defaults to startup-with-shell on. However, /bin/bash is a 64-bit executable which cannot be debugged by a 32-bit gdb. I hacked around that part by pointing $SHELL at a 32-bit bash before running make check. PR build/25981 * i386-sol2-nat.c [PR_MODEL_NATIVE != PR_MODEL_LP64] (regmap): Hardcode register numbers. -
Rainer Orth authored
As reported in PR build/25981, a future Solaris 11.4 update will soon remove the short i386 register names like SS etc. from <sys/regset.h>. They could leak into user code (e.g. via <signal.h> -> <sys/signal.h> -> <sys/ucontext.h>) and pollute the user namespace. Affected code would have a hard time avoiding the issue: LLVM is one of those. While the short names are required to be present by the i386 psABI, that document only demands that they exist in <ucontext.h>, which is what the upcoming update assures. With this change, in a 64-bit-default configuration, procfs.c fails to compile on Solaris/x86: /vol/src/gnu/gdb/hg/master/git/gdb/procfs.c: In function 'ssd* procfs_find_LDT_entry(ptid_t)': /vol/src/gnu/gdb/hg/master/git/gdb/procfs.c:1643:18: error: 'GS' was not declared in this scope 1643 | key = (*gregs)[GS] & 0xffff; | ^~ make[2]: *** [Makefile:1607: procfs.o] Error 1 Initially I meant to provide a definition using the planned replacement macro, but closer inspection revealed a better way. procfs_find_LDT_entry and its helper proc_get_LDT_entry are only used to implement ps_lgetLDT, one of the callback functions required by libthread_db.so.1 (cf. <proc_service.h>). While that function is still documented as being required even in Solaris 11.4, I found that calls to it had been removed long ago in Solaris 9, so just removing the three functions above is the easiest fix. The following patch does just that. It compiled successfully on amd64-pc-solaris2.11, however, as reported in PR gdb/25939, master is completely broken on Solaris since the multi-target patch. The patch applies cleanly to the gdb-9 branch and there I could test it successfully. PR build/25981 * procfs.c [(__i386__ || __x86_64__) && sun] (proc_get_LDT_entry, procfs_find_LDT_entry): Remove. * procfs.h [(__i386__ || __x86_64__) && sun] (struct ssd, procfs_find_LDT_entry): Remove. * sol-thread.c [(__i386__ || __x86_64__) && sun] (ps_lgetLDT): Remove. -
GDB Administrator authored
-
- 18 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 17 May, 2020 3 commits
-
-
Joel Brobecker authored
This adds the PR number to the following gdb/ChangeLog entry: 2020-05-17 Tom Tromey <tromey@adacore.com> Pushed by Joel Brobecker <brobecker@adacore.com> PR symtab/26003 * symfile.c (symbol_file_add_separate): Preserve OBJF_MAINLINE. -
Tom Tromey authored
Sometimes, get_msymbol_address can cause infinite recursion, leading to a crash. This was reported previously here: https://sourceware.org/pipermail/gdb-patches/2019-November/162154.html A user on irc reported this as well, and with his help and the help of a friend of his, we found that the problem occurred because, when reloading a separate debug objfile, the objfile would lose the OBJF_MAINLINE flag. This would cause some symbols from this separate debug objfile to be marked "maybe_copied" -- but then get_msymbol_address could find the same symbol and fail as reported. This patch fixes the bug by preserving OBJF_MAINLINE. No test case, unfortunately, because I could not successfully make one. gdb/ChangeLog 2020-04-10 Tom Tromey <tromey@adacore.com> * symfile.c (symbol_file_add_separate): Preserve OBJF_MAINLINE. (cherry picked from commit 0c4311ab)
-
GDB Administrator authored
-
- 16 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 15 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 14 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 13 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 12 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 11 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 10 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 09 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 08 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 07 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 06 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 05 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 04 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 03 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 02 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 01 May, 2020 1 commit
-
-
GDB Administrator authored
-
- 30 Apr, 2020 1 commit
-
-
GDB Administrator authored
-
- 29 Apr, 2020 1 commit
-
-
GDB Administrator authored
-
- 28 Apr, 2020 1 commit
-
-
GDB Administrator authored
-
- 27 Apr, 2020 1 commit
-
-
GDB Administrator authored
-
- 26 Apr, 2020 1 commit
-
-
GDB Administrator authored
-
- 25 Apr, 2020 1 commit
-
-
GDB Administrator authored
-
- 24 Apr, 2020 1 commit
-
-
GDB Administrator authored
-
- 23 Apr, 2020 1 commit
-
-
GDB Administrator authored
-
- 22 Apr, 2020 1 commit
-
-
GDB Administrator authored
-
- 21 Apr, 2020 1 commit
-
-
GDB Administrator authored
-