[gdb/symtab] Fix symbol loading performance regression

[ Backport of master commit e99f9db0f5. ]

The commit "[gdb/symtab] Fix language of duplicate static minimal symbol"
introduces a performance regression, when loading a cc1 executable build with
-O0 -g and gcc 7.4.0.  The performance regression, measured in 'real' time is
about 175%.

The slower execution comes from the fact that the fix in symbol_set_names
makes the call to symbol_find_demangled_name unconditional.

Fix this by reverting the commit, and redoing the fix as follows.

Recapturing the original problem, the first time symbol_set_names is called
with gsymbol.language == lang_auto and linkage_name == "_ZL3foov", the name is
not present in the per_bfd->demangled_names_hash hash table, so
symbol_find_demangled_name is called to demangle the name, after which the
mangled/demangled pair is added to the hashtable.  The call to
symbol_find_demangled_name also sets gsymbol.language to lang_cplus.
The second time symbol_set_names is called with gsymbol.language == lang_auto
and linkage_name == "_ZL3foov", the name is present in the hash table, so the
demangled name from the hash table is used.  However, the language of the
symbol remains lang_auto.

Fix this by adding a field language in struct demangled_name_entry, and using
the field in symbol_set_names to set the language of gsymbol, if necessary.

Tested on x86_64-linux.

gdb/ChangeLog:

2019-06-10  Tom de Vries  <tdevries@suse.de>

PR symtab/24545
* symtab.c (struct demangled_name_entry): Add language field.
(symbol_set_names):  Revert "[gdb/symtab] Fix language of duplicate
static minimal symbol".  Set and use language field.

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 regression caused by recently added syscall restart code

[ Backport of master commit e90a813d96. ]

This line of code...

       *(int64_t *) ptr = *(int32_t *) ptr;

...in linux-x86-low.c is not needed (and does not work correctly)
within a 32-bit executable.  I added an __x86_64__ ifdef (which is
used extensively elsewhere in the file for like purposes) to prevent
this code from being included in 32-bit builds.

It fixes the following regressions when running on native
i686-pc-linux-gnu:

FAIL: gdb.server/abspath.exp: continue to main
FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=auto: continue to main
FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=off: continue to main
FAIL: gdb.server/ext-restart.exp: restart: run to main
FAIL: gdb.server/ext-restart.exp: run to main
FAIL: gdb.server/ext-run.exp: continue to main
FAIL: gdb.server/ext-wrapper.exp: print d
FAIL: gdb.server/ext-wrapper.exp: restart: print d
FAIL: gdb.server/ext-wrapper.exp: restart: run to marker
FAIL: gdb.server/ext-wrapper.exp: run to marker
FAIL: gdb.server/no-thread-db.exp: continue to breakpoint: after tls assignment
FAIL: gdb.server/reconnect-ctrl-c.exp: first: stop with control-c
FAIL: gdb.server/reconnect-ctrl-c.exp: second: stop with control-c
FAIL: gdb.server/run-without-local-binary.exp: run test program until the end
FAIL: gdb.server/server-kill.exp: continue to breakpoint: after server_pid assignment
FAIL: gdb.server/server-kill.exp: tstatus
FAIL: gdb.server/server-run.exp: continue to main

gdb/gdbserver/ChangeLog:

PR gdb/24592
* linux-x86-low.c (x86_fill_gregset): Don't compile 64-bit
sign extension code on 32-bit builds.

Fix amd64->i386 linux syscall restart problem

[ Backport of master commit 3f52fdbcb5. ]

This commit fixes some failures in gdb.base/interrupt.exp
when debugging a 32-bit i386 linux inferior from an amd64 host.

When running the following test...

  make check RUNTESTFLAGS="--target_board unix/-m32 interrupt.exp"

... without this commit, I see the following output:

FAIL: gdb.base/interrupt.exp: continue (the program exited)
FAIL: gdb.base/interrupt.exp: echo data
FAIL: gdb.base/interrupt.exp: Send Control-C, second time
FAIL: gdb.base/interrupt.exp: signal SIGINT (the program is no longer running)
ERROR: Undefined command "".
ERROR: GDB process no longer exists

=== gdb Summary ===

When the test is run with this commit in place, we see 12 passes
instead.  This is the desired behavior.

Analysis:

On Linux, when a syscall is interrupted by a signal, the syscall
may return -ERESTARTSYS when a signal occurs.  Doing so indicates that
the syscall is restartable.  Then, depending on settings associated
with the signal handler, and after the signal handler is called, the
kernel can then either return -EINTR or can cause the syscall to be
restarted.  In this discussion, we are concerned with the latter
case.

On i386, the kernel returns this status via the EAX register.

When debugging a 32-bit (i386) process from a 64-bit (amd64)
GDB, the debugger fetches 64-bit registers even though the
process being debugged is 32-bit.  Since we're debugging a 32-bit
target, only 32 bits are being saved in the register cache.
Now, ideally, GDB would save all 64-bits in the regcache and
then would be able to restore those same values when it comes
time to continue the target.  I've looked into doing this, but
it's not easy and I don't see many benefits to doing so.  One
benefit, however, would be that EAX would appear as a negative
value for doing syscall restarts.

At the moment, GDB is setting the high 32 bits of RAX (and other
registers too) to 0.  So, when GDB restores EAX just prior to
a syscall restart, the high 32 bits of RAX are zeroed, thus making
it look like a positive value.  For this particular purpose, we
need to sign extend EAX so that RAX will appear as a negative
value when EAX is set to -ERESTARTSYS.  This in turn will cause
the signal handling code in the kernel to recognize -ERESTARTSYS
which will in turn cause the syscall to be restarted.

This commit is based on work by Jan Kratochvil from 2009:

https://sourceware.org/ml/gdb-patches/2009-11/msg00592.html

Jan's patch had the sign extension code in amd64-nat.c.  Several
other native targets make use of this code, so it seemed better
to move the sign extension code to a linux specific file.  I
also added similar code to gdbserver.

Another approach is to fix the problem in the kernel.  Hui Zhu
tried to get a fix into the kernel back in 2014, but it was not
accepted.  Discussion regarding this approach may be found here:

https://lore.kernel.org/patchwork/patch/457841/

Even if a fix were to be put into the kernel, we'd still need
some kind of fix in GDB in order to support older kernels.

Finally, I'll note that Fedora has been carrying a similar patch for
at least nine years.  Other distributions, including RHEL and CentOS
have picked up this change and have been using it too.

gdb/ChangeLog:

PR gdb/24592
* amd64-linux-nat.c (amd64_linux_collect_native_gregset): New
function.
(fill_gregset): Call amd64_linux_collect_native_gregset instead
of amd64_collect_native_gregset.
(amd64_linux_nat_target::store_registers): Likewise.

gdb/gdbserver/ChangeLog:

PR gdb/24592
* linux-x86-low.c (x86_fill_gregset): Sign extend EAX value
when using a 64-bit gdbserver.

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

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