1. 11 May, 2019 2 commits
  2. 10 May, 2019 1 commit
  3. 09 May, 2019 1 commit
  4. 08 May, 2019 2 commits
    • Tom Tromey's avatar
      Fix style bug when paging · d0e1efa6
      Tom Tromey authored
      Philippe pointed out a styling bug that would occur in some conditions
      when paging:
      
          https://sourceware.org/ml/gdb-patches/2019-04/msg00101.html
      
      I was finally able to reproduce this, and this patch fixes the bug.
      
      The problem occurred when text overflowed the line, causing a
      pagination prompt, but when no wrap column had been set.  In this
      case, the current style was reset to show the prompt, but then not
      reset back to the previously applied style before emitting the rest of
      the line.
      
      The fix is to record the applied style in this case, and re-apply it
      afterward -- but only if the pager prompt was emitted, something that
      the existing style.exp pointed out on the first, more naive, version
      of the patch.
      
      Tested on x86-64 Fedora 29.
      
      gdb/ChangeLog
      2019-05-08  Tom Tromey  <tromey@adacore.com>
      
      	* utils.c (fputs_maybe_filtered): Reset style after paging, even
      	when no wrap column is set.
      d0e1efa6
    • GDB Administrator's avatar
      Automatic date update in version.in · 4dd5cf12
      GDB Administrator authored
      4dd5cf12
  5. 07 May, 2019 1 commit
  6. 06 May, 2019 1 commit
  7. 05 May, 2019 1 commit
  8. 04 May, 2019 2 commits
    • Tom Tromey's avatar
      Don't derive partial_symbol from general_symbol_info · 20555e9e
      Tom Tromey authored
      This patch partly reverts commit 8a6d4234 ("Change representation of
      psymbol to flush out accessors"); specifically, it changes
      partial_symbol to no longer derive from general_symbol_info.
      
      The basic problem here is that the bcache compares objects bitwise,
      and this change made it less likely that the relevant fields in the
      psymbol would be fully initialized.  This could be seen by running a
      test under valgrind on the Fedora-i686 buildbot.
      
      I considered a simpler patch, namely just zeroing the psymbol's
      "value" field in add_psymbol_to_bcache.  However, it wasn't clear to
      me that this memset could not then be optimized away by the compiler.
      
      Regression tested by the buildbot.  I think this should go in 8.3 as
      well.
      
      2019-05-04  Tom Tromey  <tom@tromey.com>
      
      	* psymtab.c (psymbol_name_matches, match_partial_symbol)
      	(lookup_partial_symbol, print_partial_symbols)
      	(recursively_search_psymtabs, sort_pst_symbols, psymbol_hash)
      	(psymbol_compare): Update.
      	(add_psymbol_to_bcache): Clear the entire psymbol.
      	(maintenance_check_psymtabs): Update.
      	* psympriv.h (struct partial_symbol): Don't derive from
      	general_symbol_info.
      	<obj_section, unrelocated_address, address,
      	set_unrelocated_address>: Update.
      	<ginfo>: New member.
      	* dwarf-index-write.c (write_psymbols, debug_names::insert)
      	(debug_names::write_psymbols): Update.
      20555e9e
    • GDB Administrator's avatar
      Automatic date update in version.in · 0af71a8e
      GDB Administrator authored
      0af71a8e
  9. 03 May, 2019 4 commits
    • Eli Zaretskii's avatar
      Fix compilation with mingw.org's MinGW. · bc694fdc
      Eli Zaretskii authored
      That flavor of MinGW assumes Windows 9X as the default target,
      which doesn't expose CONSOLE_FONT_INFO stuff in Windows header
      files.  Since we no longer support running on Windows older
      than XP anyway, requiring it at build time makes sense.
      
      gdb/ChangeLog
      2019-05-03  Eli Zaretskii  <eliz@gnu.org>
      
      	* windows-nat.c [_WIN32_WINNT]: Define _WIN32_WINNT to Windows XP
      	level, so that various Windows header files expose the necessary
      	declarations and definitions.
      bc694fdc
    • Eli Zaretskii's avatar
      Fix lookup of separate debug file on MS-Windows. · 661f3888
      Eli Zaretskii authored
      If you put the separate debug file in a global debug directory, GDB on
      MS-Windows would fail to find it.  This happens because we obtain the
      directory to look up the debug file by concatenating the debug
      directory name with the leading directories of the executable, and the
      latter includes the drive letter on MS-Windows.  So we get an invalid
      file name like
      
         d:/usr/lib/debug/d:/usr/bin/foo.debug
      
      This commit fixes that by removing the colon of the drive letter,
      thus producing
      
         d:/usr/lib/debug/d/usr/bin/foo.debug
      
      gdb/ChangeLog:
      2019-05-03  Eli Zaretskii  <eliz@gnu.org>
      
      	* symfile.c (find_separate_debug_file): Remove colon from the
      	drive spec of DOS/Windows file names of the target, so that the
      	file name produced from DEBUGDIR and the target's directory will
      	be valid on DOS/Windows systems.
      
      gdb/doc/ChangeLog:
      2019-05-03  Eli Zaretskii  <eliz@gnu.org>
      
      	* gdb.texinfo (Separate Debug Files): Document how the
      	subdirectory of the global debug directory is computed on
      	MS-Windows/MS-DOS.
      
      (cherry picked from commit 5f2459c2)
      661f3888
    • Nick Clifton's avatar
      Treat the .gnu.debuglink and .gnu.debugaltlink sections as debug sections when... · 35f76739
      Nick Clifton authored
      Treat the .gnu.debuglink and .gnu.debugaltlink sections as debug sections when reading them in from COFF/PE format files.
      
      	PR 24493
      	* coffcode.h (styp_to_sec_flags): Treat .gnu.debuglink and
      	.gnu.debugaltlink sections as debugging sections.
      
      (cherry picked from commit 2cdc1a97)
      35f76739
    • GDB Administrator's avatar
      Automatic date update in version.in · 0ade6866
      GDB Administrator authored
      0ade6866
  10. 02 May, 2019 1 commit
  11. 01 May, 2019 1 commit
  12. 30 Apr, 2019 3 commits
    • Joel Brobecker's avatar
      (Windows) fix thr != nullptr assert failure in delete_thread_1 · 002aae07
      Joel Brobecker authored
      We have observed that GDB would randomly trip the following
      assertion failure when debugging on Windows. When allowing
      the program to run until the inferior exits, we occasionally see:
      
           (gdb) cont
           Continuing.
           [Thread 48192.0xd100 exited with code 1]
           [Thread 48192.0x10ad8 exited with code 1]
           [Thread 48192.0x36e28 exited with code 0]
           [Thread 48192.0x52be4 exited with code 0]
           [Thread 48192.0x5aa40 exited with code 0]
           ../../src/gdb/thread.c:453: internal-error: void delete_thread_1(thread_inf
      o*, bool): Assertion `thr != nullptr' failed.
      
      Running the same scenario with some additional traces enabled...
      
          (gdb) set verbose
          (gdb) set debugevents
      
      ... allows us to understand what the issue is. To understand, we need
      to first look at the events received when starting the program, and
      in particular which threads got created how. First, we get a
      CREATE_PROCESS_DEBUG_EVENT for tid=0x442a8:
      
          gdb: kernel event for pid=317536 tid=0x442a8 code=CREATE_PROCESS_DEBUG_EVENT)
      
      Shortly after, we get some CREATE_THREAD_DEBUG_EVENT events,
      one of them being for tid=0x4010c:
      
          gdb: kernel event for pid=317536 tid=0x4010c code=CREATE_THREAD_DEBUG_EVENT)
      Fast forward a bit of debugging, and we do a "cont" as above,
      at which point the programs reaches the end, and the system reports
      "exit" events. The first interesting one is the following:
      
          gdb: kernel event for pid=317536 tid=0x442a8 code=EXIT_THREAD_DEBUG_EVENT)
      
      This is reporting a thread-exit event for a thread whose tid
      is the TID of what we call the "main thread". That's the thread
      that was created when we received the CREATE_PROCESS_DEBUG_EVENT
      notification, and whose TID is actually stored in a global variable
      named main_thread_id. This is not something we expected, as
      the assumption we made was that the main thread would exit last,
      and we would be notified of it via an EXIT_PROCESS_DEBUG_EVENT.
      But apparently, this is not always true, at least on Windows Server
      2012 and 2016 where this issue has been observed happening randomly.
      
      The consequence of the above notification is that we call
      windows_delete_thread for that thread, which removes it from
      our list of known threads.
      
      And a little bit later, then we then get the EXIT_PROCESS_DEBUG_EVENT,
      and we can see that the associated tid is not the main_thread_id,
      but rather the tid of one of the threads that was created during
      the lifetime of the program, in this case tid=0x4010c:
      
          gdb: kernel event for pid=317536 tid=0x4010c code=EXIT_PROCESS_DEBUG_EVENT)
      
      And the debug trace printed right after shows why we're crashing:
      
          [Deleting Thread 317536.0x442a8]
      
      We are trying to delete the thread whose tid=0x442a8, which is
      the main_thread_id! As we have already deleted that thread before,
      the search for it returns a nullptr, which then trips the assertion
      check in delete_thread_1.
      
      This commit fixes this issue. It ignores the open question of
      what to do with the main_thread_id global, particularly after
      that thread has been removed from our list of threads. This will
      be dealt with as a separate patch, to allow cherry-picking
      this patch into a release branch.
      
      For now, we fix the code so as to avoid this crash.
      
      gdb/ChangeLog:
      
      	* windows-nat.c (get_windows_debug_event) <EXIT_PROCESS_DEBUG_EVENT>:
      	Use current_event.dwThreadId instead of main_thread_id.
      002aae07
    • Tom Tromey's avatar
      Fix crash in dwarf2read.c with template parameters · 578f1223
      Tom Tromey authored
      PR c++/24470 concerns a crash in dwarf2read.c that occurs with a
      particular test case.
      
      The issue turns out to be that process_structure_scope will pass NULL
      to symbol_symtab.  This happens because new_symbol decided not to
      create a symbol for the particular DIE.
      
      This patch fixes the problem by finding another reasonably-appropriate
      symtab to use instead; issuing a complaint if one cannot be found for
      some reason.
      
      As mentioned in the bug, I think there are other bugs here.  For
      example, when using "ptype" on the "l" object in the test case, I
      think I would expect to see the template parameter.  I didn't research
      this too closely, since it seemed more important to fix the crash.
      
      Tested on x86-64 Fedora 29.
      
      I'd like to check this in to the 8.3 branch as well.
      
      gdb/ChangeLog
      2019-04-30  Tom Tromey  <tromey@adacore.com>
      
      	PR c++/24470:
      	* dwarf2read.c (process_structure_scope): Handle case where type
      	has template parameters but no symbol was created.
      
      gdb/testsuite/ChangeLog
      2019-04-30  Tom Tromey  <tromey@adacore.com>
      
      	PR c++/24470:
      	* gdb.cp/temargs.cc: Add test code from PR.
      578f1223
    • GDB Administrator's avatar
      Automatic date update in version.in · 1cdf668b
      GDB Administrator authored
      1cdf668b
  13. 29 Apr, 2019 1 commit
  14. 28 Apr, 2019 1 commit
  15. 27 Apr, 2019 1 commit
  16. 26 Apr, 2019 1 commit
  17. 25 Apr, 2019 1 commit
  18. 24 Apr, 2019 1 commit
  19. 23 Apr, 2019 1 commit
  20. 22 Apr, 2019 1 commit
  21. 21 Apr, 2019 1 commit
  22. 20 Apr, 2019 1 commit
  23. 19 Apr, 2019 4 commits
    • Sergei Trofimovich's avatar
      gdb/configure.ac: add --enable-source-highlight · 4ae3a64b
      Sergei Trofimovich authored
      Allow disabling source-highlight dependency autodetection even
      it exists in the system. More details on problem of automatic
      dependencies:
      https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies
      
      Noticed by Jeroen Roovers in https://bugs.gentoo.org/680238
      
      	* configure.ac: add --enable-source-highlight switch.
      	* configure: Regenerate.
      	* top.c (print_gdb_version): plumb --enable-source-highlight
      	status to "show configuration".
      
      gdb/ChangeLog
      2019-04-19  Sergei Trofimovich <siarheit@google.com>
      
      	* configure.ac: add --enable-source-highlight switch.
      	* configure: Regenerate.
      	* top.c (print_gdb_version): plumb --enable-source-highlight
      	status to "show configuration".
      4ae3a64b
    • Tom Tromey's avatar
      Fix "list" when control characters are seen · 014bc49b
      Tom Tromey authored
      PR symtab/24423 points out that control characters in a source file
      cause a hang in the "list" command, a regression introduced by the
      styling changes.
      
      This patch, from the PR, fixes the bug.  I've included a minimal
      change to the "list" test that exercises this code.
      
      I recall that this bug was discussed on gdb-patches, and I thought
      there was a patch there as well, but I was unable to find it.
      
      2019-04-19  Ilya Yu. Malakhov  <malakhov@mcst.ru>
      
      	PR symtab/24423:
      	* source.c (print_source_lines_base): Advance "iter" when a
      	control character is seen.
      
      gdb/testsuite/ChangeLog
      2019-04-19  Tom Tromey  <tromey@adacore.com>
      
      	PR symtab/24423:
      	* gdb.base/list0.h (foo): Add a control-l character.
      014bc49b
    • Philippe Waroquiers's avatar
      Fix GDB 8.3 regression crash when registers cannot be modified. · bf9a7cea
      Philippe Waroquiers authored
      This crash was detected when using GDB with the valgrind gdbserver.
      To reproduce:
      
      valgrind sleep 10000
      
      In another window:
      gdb
      target remote | vgdb
      p printf("make sleep print something\n")
      =>
      terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
      Aborted
      
      The problem is that the valgrind gdbserver does not allow to change
      registers when the inferior is blocked in a system call.
      GDB then raises an exception.  The exception causes the destructor
      of
       typedef std::unique_ptr<infcall_suspend_state, infcall_suspend_state_deleter>
          infcall_suspend_state_up;
      to be called.  This destructor itself tries to restore the value of
      the registers, and fails similarly.  We must catch the exception in
      the destructor to avoid crashing GDB.
      If the destructor encounters a problem, no warning is produced if
      there is an uncaught exception, as in this case, the user will already
      be informed of a problem via this exception.
      
      With this change, no crash anymore, and all the valgrind 3.15 tests
      pass succesfully.
      
      Note: when this patch is approved, I will push an equivalent patch
      on master, but with TRY/CATCH/e.message () replaced by
      try/catch/e.what ().
      
      gdb/ChangeLog
      2019-04-19  Philippe Waroquiers  <philippe.waroquiers@skynet.be>
      
      	* inferior.h (struct infcall_suspend_state_deleter):
      	Catch exception in destructor to avoid crash.
      bf9a7cea
    • GDB Administrator's avatar
      Automatic date update in version.in · 6530876a
      GDB Administrator authored
      6530876a
  24. 18 Apr, 2019 1 commit
  25. 17 Apr, 2019 1 commit
  26. 16 Apr, 2019 1 commit
  27. 15 Apr, 2019 1 commit
  28. 14 Apr, 2019 1 commit
  29. 13 Apr, 2019 1 commit