external/binutils.git
4 years agoAutomatic date update in version.in
GDB Administrator [Sat, 3 Aug 2019 00:00:52 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Fri, 2 Aug 2019 00:01:43 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Thu, 1 Aug 2019 00:00:56 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Wed, 31 Jul 2019 00:01:59 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Tue, 30 Jul 2019 00:01:00 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Mon, 29 Jul 2019 00:00:56 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sun, 28 Jul 2019 00:02:26 +0000 (00:02 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sat, 27 Jul 2019 00:00:58 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Fri, 26 Jul 2019 00:01:06 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Thu, 25 Jul 2019 00:01:06 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Wed, 24 Jul 2019 00:00:57 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Tue, 23 Jul 2019 00:02:10 +0000 (00:02 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Mon, 22 Jul 2019 00:00:59 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years ago[gdb/symtab] Fix symbol loading performance regression
Tom de Vries [Sun, 21 Jul 2019 18:01:35 +0000 (20:01 +0200)]
[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.

4 years agoAutomatic date update in version.in
GDB Administrator [Sun, 21 Jul 2019 00:01:39 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sat, 20 Jul 2019 00:01:00 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Fri, 19 Jul 2019 00:01:02 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Thu, 18 Jul 2019 00:01:03 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Wed, 17 Jul 2019 00:00:56 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Tue, 16 Jul 2019 00:01:12 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Mon, 15 Jul 2019 00:01:06 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sun, 14 Jul 2019 00:01:40 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sat, 13 Jul 2019 00:00:58 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoFix regression caused by recently added syscall restart code
Kevin Buettner [Fri, 12 Jul 2019 12:33:40 +0000 (14:33 +0200)]
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.

4 years agoFix amd64->i386 linux syscall restart problem
Kevin Buettner [Fri, 12 Jul 2019 12:33:40 +0000 (14:33 +0200)]
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.

4 years agoAutomatic date update in version.in
GDB Administrator [Fri, 12 Jul 2019 00:01:02 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Thu, 11 Jul 2019 00:01:07 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Wed, 10 Jul 2019 00:01:08 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Tue, 9 Jul 2019 00:00:51 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Mon, 8 Jul 2019 00:01:03 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sun, 7 Jul 2019 00:01:41 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sat, 6 Jul 2019 00:01:00 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Fri, 5 Jul 2019 00:01:03 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Thu, 4 Jul 2019 00:00:59 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Wed, 3 Jul 2019 00:01:05 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Tue, 2 Jul 2019 00:01:49 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Mon, 1 Jul 2019 00:01:59 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sun, 30 Jun 2019 00:01:41 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sat, 29 Jun 2019 00:01:04 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Fri, 28 Jun 2019 00:01:52 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Thu, 27 Jun 2019 00:01:01 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Wed, 26 Jun 2019 00:01:06 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Tue, 25 Jun 2019 00:01:10 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Mon, 24 Jun 2019 00:01:04 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sun, 23 Jun 2019 00:01:31 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sat, 22 Jun 2019 00:00:58 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Fri, 21 Jun 2019 00:01:04 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Thu, 20 Jun 2019 00:00:56 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Wed, 19 Jun 2019 00:01:22 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Tue, 18 Jun 2019 00:01:12 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Mon, 17 Jun 2019 00:01:06 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sun, 16 Jun 2019 00:01:42 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sat, 15 Jun 2019 00:01:06 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Fri, 14 Jun 2019 00:00:57 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Thu, 13 Jun 2019 00:01:30 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Wed, 12 Jun 2019 00:00:58 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Tue, 11 Jun 2019 00:00:52 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Mon, 10 Jun 2019 00:00:55 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sun, 9 Jun 2019 00:01:36 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sat, 8 Jun 2019 00:01:47 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Fri, 7 Jun 2019 00:00:54 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Thu, 6 Jun 2019 00:00:53 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Wed, 5 Jun 2019 00:00:56 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Tue, 4 Jun 2019 00:00:52 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Mon, 3 Jun 2019 00:01:37 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sun, 2 Jun 2019 00:01:36 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sat, 1 Jun 2019 00:01:00 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Fri, 31 May 2019 00:00:57 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Thu, 30 May 2019 00:00:56 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Wed, 29 May 2019 00:01:02 +0000 (00:01 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Tue, 28 May 2019 00:00:52 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Mon, 27 May 2019 00:00:52 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Sun, 26 May 2019 00:01:29 +0000 (00:01 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Sat, 25 May 2019 00:01:01 +0000 (00:01 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Fri, 24 May 2019 00:01:00 +0000 (00:01 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Thu, 23 May 2019 00:00:49 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Wed, 22 May 2019 00:00:54 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Tue, 21 May 2019 00:00:52 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Mon, 20 May 2019 00:01:02 +0000 (00:01 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Sun, 19 May 2019 00:01:37 +0000 (00:01 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Sat, 18 May 2019 00:00:52 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Fri, 17 May 2019 00:00:54 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Thu, 16 May 2019 00:00:47 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Wed, 15 May 2019 00:00:53 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Tue, 14 May 2019 00:00:46 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Mon, 13 May 2019 00:00:56 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Sun, 12 May 2019 00:01:39 +0000 (00:01 +0000)]
Automatic date update in version.in

5 years agoBump GDB version number to 8.3.0.DATE-git.
Joel Brobecker [Sat, 11 May 2019 18:37:30 +0000 (11:37 -0700)]
Bump GDB version number to 8.3.0.DATE-git.

gdb/ChangeLog:

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

5 years agoDocument the GDB 8.3 release in gdb/ChangeLog
Joel Brobecker [Sat, 11 May 2019 18:28:58 +0000 (11:28 -0700)]
Document the GDB 8.3 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 8.3 released.

5 years agoSet GDB version number to 8.3. gdb-8.3-release
Joel Brobecker [Sat, 11 May 2019 18:19:03 +0000 (11:19 -0700)]
Set GDB version number to 8.3.

gdb/ChangeLog:

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

5 years agoAutomatic date update in version.in
GDB Administrator [Sat, 11 May 2019 00:00:41 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Fri, 10 May 2019 00:00:56 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Thu, 9 May 2019 00:01:18 +0000 (00:01 +0000)]
Automatic date update in version.in

5 years agoFix style bug when paging
Tom Tromey [Wed, 1 May 2019 17:13:31 +0000 (11:13 -0600)]
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.

5 years agoAutomatic date update in version.in
GDB Administrator [Wed, 8 May 2019 00:01:01 +0000 (00:01 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Tue, 7 May 2019 00:00:51 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Mon, 6 May 2019 00:00:55 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Sun, 5 May 2019 00:01:33 +0000 (00:01 +0000)]
Automatic date update in version.in

5 years agoDon't derive partial_symbol from general_symbol_info
Tom Tromey [Tue, 23 Apr 2019 22:42:14 +0000 (16:42 -0600)]
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.

5 years agoAutomatic date update in version.in
GDB Administrator [Sat, 4 May 2019 00:00:47 +0000 (00:00 +0000)]
Automatic date update in version.in