and though bugs are the bane of my existence, rest assured the wretched thing will get the best of care here

  1. 23 May, 2020 4 commits
  2. 22 May, 2020 1 commit
  3. 21 May, 2020 1 commit
  4. 20 May, 2020 1 commit
  5. 19 May, 2020 3 commits
    • Rainer Orth's avatar
      Avoid short i386 register names on Solaris/x86 [PR25981] · 3bfcbaaa
      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.
      3bfcbaaa
    • Rainer Orth's avatar
      Remove unused ps_lgetLDT etc. on Solaris/x86 [PR25981] · ff6da943
      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.
      ff6da943
    • GDB Administrator's avatar
      Automatic date update in version.in · 0b2afb86
      GDB Administrator authored
      0b2afb86
  6. 18 May, 2020 1 commit
  7. 17 May, 2020 3 commits
    • Joel Brobecker's avatar
      gdb/ChangeLog: Add PR number to the latest entry · 9502fa5e
      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.
      9502fa5e
    • Tom Tromey's avatar
      Avoid infinite recursion in get_msymbol_address · de9ba0d3
      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)
      de9ba0d3
    • GDB Administrator's avatar
      Automatic date update in version.in · 40ce64f0
      GDB Administrator authored
      40ce64f0
  8. 16 May, 2020 1 commit
  9. 15 May, 2020 1 commit
  10. 14 May, 2020 1 commit
  11. 13 May, 2020 1 commit
  12. 12 May, 2020 1 commit
  13. 11 May, 2020 1 commit
  14. 10 May, 2020 1 commit
  15. 09 May, 2020 1 commit
  16. 08 May, 2020 1 commit
  17. 07 May, 2020 1 commit
  18. 06 May, 2020 1 commit
  19. 05 May, 2020 1 commit
  20. 04 May, 2020 1 commit
  21. 03 May, 2020 1 commit
  22. 02 May, 2020 1 commit
  23. 01 May, 2020 1 commit
  24. 30 Apr, 2020 1 commit
  25. 29 Apr, 2020 1 commit
  26. 28 Apr, 2020 1 commit
  27. 27 Apr, 2020 1 commit
  28. 26 Apr, 2020 1 commit
  29. 25 Apr, 2020 1 commit
  30. 24 Apr, 2020 1 commit
  31. 23 Apr, 2020 1 commit
  32. 22 Apr, 2020 1 commit
  33. 21 Apr, 2020 1 commit