- 11 May, 2019 2 commits
-
-
Joel Brobecker authored
gdb/ChangeLog: * version.in: Set GDB version number to 8.3.
-
GDB Administrator authored
-
- 10 May, 2019 1 commit
-
-
GDB Administrator authored
-
- 09 May, 2019 1 commit
-
-
GDB Administrator authored
-
- 08 May, 2019 2 commits
-
-
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. -
GDB Administrator authored
-
- 07 May, 2019 1 commit
-
-
GDB Administrator authored
-
- 06 May, 2019 1 commit
-
-
GDB Administrator authored
-
- 05 May, 2019 1 commit
-
-
GDB Administrator authored
-
- 04 May, 2019 2 commits
-
-
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.
-
GDB Administrator authored
-
- 03 May, 2019 4 commits
-
-
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.
-
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)
-
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)
-
GDB Administrator authored
-
- 02 May, 2019 1 commit
-
-
GDB Administrator authored
-
- 01 May, 2019 1 commit
-
-
GDB Administrator authored
-
- 30 Apr, 2019 3 commits
-
-
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. -
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.
-
GDB Administrator authored
-
- 29 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 28 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 27 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 26 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 25 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 24 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 23 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 22 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 21 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 20 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 19 Apr, 2019 4 commits
-
-
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".
-
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.
-
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. -
GDB Administrator authored
-
- 18 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 17 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 16 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 15 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 14 Apr, 2019 1 commit
-
-
GDB Administrator authored
-
- 13 Apr, 2019 1 commit
-
-
GDB Administrator authored
-