Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Bump GDB version number to 8.3.0.DATE-git.

gdb/ChangeLog:

* version.in: Set GDB version number to 8.3.0.DATE-git.

Document the GDB 8.3 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 8.3 released.

Set GDB version number to 8.3.

gdb/ChangeLog:

* version.in: Set GDB version number to 8.3.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix style bug when paging

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.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Don't derive partial_symbol from general_symbol_info

This patch partly reverts commit 8a6d42345 ("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.

Automatic date update in version.in

Fix compilation with mingw.org's MinGW.

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.

Fix lookup of separate debug file on MS-Windows.

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 5f2459c233faebe8f882e556b2f4a86594a51292)

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 2cdc1a970d3249888524d251abfb87a9bdc77434)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

(Windows) fix thr != nullptr assert failure in delete_thread_1

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.

Fix crash in dwarf2read.c with template parameters

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.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb/configure.ac: add --enable-source-highlight

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".

Fix "list" when control characters are seen

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.

Fix GDB 8.3 regression crash when registers cannot be modified.

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.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Another fix for GDB styling

gdb/ChangeLog:
2019-04-12  Eli Zaretskii  <eliz@gnu.org>

* utils.c (prompt_for_continue): Don't restore the styling at the
end, as applied_style has the wrong value.  This fixes styling in
long lists of file names that are interrupted by the "Continue?"
prompt.

(cherry picked from commit 51196bbc5618a3741bd7bbed01ac76b25a2e6f9c)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix testsuite hangs when gdb_test_multiple body errors out

This commit fixes a regression in the testsuite itself, triggered by
errors being raised from within gdb_test_multiple, originally reported
by Pedro Franco de Carvalho's at
<https://sourceware.org/ml/gdb-patches/2019-03/msg00160.html>.  Parts
of the commit message are based on his report.

This started happening due to a commit that was introduced recently,
and it can cause the testsuite to hang.

The commit that triggers this is:

 fe1a5cad302b5535030cdf62895e79512713d738
 [gdb/testsuite] Log wait status on process no longer exists error

That commit introduces a new "eof" block in gdb_test_multiple.  That
is not incorrect itself, but dejagnu's remote_expect is picking that
block as the "default" action when an error is raised from within the
commands inside a call to gdb_test_multiple:

  # remote_expect works basically the same as standard expect, but it
  # also takes care of getting the file descriptor from the specified
  # host and also calling the timeout/eof/default section if there is an
  # error on the expect call.
  #
  proc remote_expect { board timeout args } {

I find that "feature" surprising, and I don't really know why it
exists, but this means that the eof section that remote_expect picks
as the error block can be executed even when there was no actual eof
and the GDB process is still running, so the wait introduced in the
commit that tries to get the exit status of GDB hangs forever, while
GDB itself waits for input.

This only happens when there are internal testsuite errors (not
testcase failures).  This can be reproduced easily with a testcase
such as:

  gdb_start
  gdb_test_multiple "show version" "show version" {
    -re ".*" {
       error "forced error"
    }
  }

I think that working around this in GDB is useful so that the
testsuite doesn't hang in these cases.

Adding an empty "default" block at the end of the expect body in
gdb_test_multiple doesn't work, because dejagnu gives preference to
"eof" blocks:

    if { $x eq "eof" } {
set save_next 1
    } elseif { $x eq "default" || $x eq "timeout" } {
if { $error_sect eq "" } {
    set save_next 1
}
    }

And we do have "eof" blocks.  So we need to make sure that the last
"eof" block is safe to use as the default error block.  It's also
pedantically incorrect to print

 "ERROR: Process no longer exists"

which is what we'd get if the last eof block we have was selected
(more below on this).

So this commit solves this by appending an "eof" with an empty
spawn_id list, so that it won't ever match.

Now, why is the first "eof" block selected today as the error block,
instead of the last one?

The reason is that remote_expect, while parsing the body to select the
default block to execute after an error, is affected by the comments
in the body (since they are also parsed).

If this comment in gdb_test_multiple

 # patterns below apply to any spawn id specified.

is changed to

 # The patterns below apply to any spawn id specified.

then the second eof block is selected and there is no hang.

Any comment at that same place with an even number of tokens also
works.

This is IMO a coincidence caused by how comments work in TCL.
Comments should only appear in places where a command can appear.  And
here, remote_expect is parsing a list of options, not commands, so
it's not unreasonable to not parse comments, similarly to how this:

  set a_list {
     an_element
     # another_element
  }

results in a list with three elements, not one element.

The fact that comments with an even number of tokens work is just a
coincidence of how remote_expect's little state machine is
implemented.

I thought we could solve this by stripping out comment lines in
gdb_expect, but I didn't find an easy way to do that.  Particularly, a
couple naive approaches I tried run into complications.  For example,
we have gdb_test calls with regular expressions that include sequences
like "\r\n#", and by the time we get to gdb_expect, the \r\n have
already been expanded to a real newline, so just splitting the whole
body at newline boundaries, looking for lines that start with #
results in incorrectly stripping out half of the gdb_text regexp.  I
think it's better (at least in this commit), to move the comments out
of the list, because it's much simpler and risk free.

gdb/testsuite/ChangeLog:
2019-03-25  Pedro Alves  <palves@redhat.com>

* lib/gdb.exp (gdb_test_multiple): Split appends to $code and
move comments outside list.  Append '-i "" eof' section.

(cherry picked from commit 9a93502fa81734d39f213ccb33b497bc40e1423d)

Automatic date update in version.in

Automatic date update in version.in