Update ChangeLog entry of commit 7e38ddcb2e and mention PR breakpoints/25011

Update ChangeLog entry of commit 8ac39635f6 and mention PR gdb/25010

Automatic date update in version.in

[gdb/testsuite] Fix regexp in skip_opencl_tests

[ Backport of master commit d2b584a55b. ]

When running gdb-caching-proc.exp, if skip_opencl_tests fails like this:
...
(gdb) run
Starting program: \
  build/gdb/testsuite/outputs/gdb.base/gdb-caching-proc/opencltest13530.x
CHK_ERR (clGetPlatformIDs (1, &platform, NULL), -1001)
src/gdb/testsuite/lib/opencl_hostapp.c:73 error: Unknown
[Inferior 1 (process 13600) exited with code 01]
(gdb)
skip_opencl_tests: OpenCL support not detected
...
then this regexp in skip_opencl_tests fails to match:
...
        -re ".*$inferior_exited_re code.*${gdb_prompt} $" {
...
so instead we hit the default clause after a 30 seconds timeout.  With the
iteration count set at 10, we end up taking 6 minutes to run this test-case.

Fix this by adding the missing "with" in the regexp, bring back the runtime to
half a minute.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-04-29  Tom de Vries  <tdevries@suse.de>

PR testsuite/25005
* lib/opencl.exp (skip_opencl_tests): Add missing "with" in regexp.

Update ChangeLog entry of commit e9224f6d80ea35e90a61d44575f12b26742eaaf3 and mention PR breakpoints/24541

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

Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)

[ Backport of master commit 7d7571f0c1. ]

This bug has been reported on PR breakpoints/24541, but it is possible
to reproduce it easily by running:

  make check-gdb TESTS=gdb.base/stap-probe.exp RUNTESTFLAGS='--target_board unix/-m32'

The underlying cause is kind of complex, and involves decisions made
by GCC and the sys/sdt.h header file about how to represent a probe
argument that lives in a register in 32-bit programs.  I'll use
Andrew's example on the bug to illustrate the problem.

libstdc++ has a probe named "throw" with two arguments.  On i386, the
probe is:

  stapsdt              0x00000028       NT_STAPSDT (SystemTap probe descriptors)
    Provider: libstdcxx
    Name: throw
    Location: 0x00072c96, Base: 0x00133d64, Semaphore: 0x00000000
    Arguments: 4@%si 4@%di

I.e., the first argument is an unsigned 32-bit value (represented by
the "4@") that lives on %si, and the second argument is an unsigned
32-bit value that lives on %di.  Note the discrepancy between the
argument size reported by the probe (32-bit) and the register size
being used to store the value (16-bit).

However, if you take a look at the disassemble of a program that uses
this probe, you will see:

    00072c80 <__cxa_throw@@CXXABI_1.3>:
       72c80:       57                      push   %edi
       72c81:       56                      push   %esi
       72c82:       53                      push   %ebx
       72c83:       8b 74 24 10             mov    0x10(%esp),%esi
       72c87:       e8 74 bf ff ff          call   6ec00 <__cxa_finalize@plt+0x980>
       72c8c:       81 c3 74 e3 10 00       add    $0x10e374,%ebx
       72c92:       8b 7c 24 14             mov    0x14(%esp),%edi
       72c96:       90                      nop                      <----------------- PROBE IS HERE
       72c97:       e8 d4 a2 ff ff          call   6cf70 <__cxa_get_globals@plt>
       72c9c:       83 40 04 01             addl   $0x1,0x4(%eax)
       72ca0:       83 ec 04                sub    $0x4,%esp
       72ca3:       ff 74 24 1c             pushl  0x1c(%esp)
       72ca7:       57                      push   %edi
       72ca8:       56                      push   %esi
       72ca9:       e8 62 a3 ff ff          call   6d010 <__cxa_init_primary_exception@plt>
       72cae:       8d 70 40                lea    0x40(%eax),%esi
       72cb1:       c7 00 01 00 00 00       movl   $0x1,(%eax)
       72cb7:       89 34 24                mov    %esi,(%esp)
       72cba:       e8 61 96 ff ff          call   6c320 <_Unwind_RaiseException@plt>
       72cbf:       89 34 24                mov    %esi,(%esp)
       72cc2:       e8 c9 84 ff ff          call   6b190 <__cxa_begin_catch@plt>
       72cc7:       e8 d4 b3 ff ff          call   6e0a0 <_ZSt9terminatev@plt>
       72ccc:       66 90                   xchg   %ax,%ax
       72cce:       66 90                   xchg   %ax,%ax

Note how the program is actually using %edi, and not %di, to store the
second argument.  This is the problem here.

GDB will basically read the probe argument, then read the contents of
%di, and then cast this value to uint32_t, which causes the wrong
value to be obtained.  In the gdb.base/stap-probe.exp case, this makes
GDB read the wrong memory location, and not be able to display a test
string.  In Andrew's example, this causes GDB to actually stop at a
"catch throw" when it should actually have *not* stopped.

After some discussion with Frank Eigler and Jakub Jelinek, it was
decided that this bug should be fixed on the client side (i.e., the
program that actually reads the probes), and this is why I'm proposing
this patch.

The idea is simple: we will have a gdbarch method, which, for now, is
only used by i386.  The generic code that deals with register operands
on gdb/stap-probe.c will call this method if it exists, passing the
current parse information, the register name and its number.

The i386 method will then verify if the register size is greater or
equal than the size reported by the stap probe (the "4@" part).  If it
is, we're fine.  Otherwise, it will check if we're dealing with any of
the "extendable" registers (like ax, bx, si, di, sp, etc.).  If we
are, it will change the register name to include the "e" prefix.

I have tested the patch here in many scenarios, and it fixes Andrew's
bug and also the regressions I mentioned before, on
gdb.base/stap-probe.exp.  No regressions where found on other tests.

Comments?

gdb/ChangeLog:
2019-06-27  Sergio Durigan Junior  <sergiodj@redhat.com>

PR breakpoints/24541
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh: Add 'stap_adjust_register'.
* i386-tdep.c: Include '<unordered_set>'.
(i386_stap_adjust_register): New function.
(i386_elf_init_abi): Register 'i386_stap_adjust_register'.
* stap-probe.c (stap_parse_register_operand): Call
'gdbarch_stap_adjust_register'.

Make stap-probe.c:stap_parse_register_operand's "regname" an std::string

[ Backport of master commit 677052f2a5. ]

This patch simplifies the code of
stap-probe.c:stap_parse_register_operand by making "regname" an
std::string.  No functionality change.

I'm this code's maintainer, so I'm pushing this as it's a fairly
trivial patch.

gdb/ChangeLog:
2019-05-16  Sergio Durigan Junior  <sergiodj@redhat.com>

* stap-probe.c (stap_parse_register_operand): Make "regname" an
"std::string", simplifying the algorithm.

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

[gdb] Handle vfork in thread with follow-fork-mode child

[ Backport of master commit b73715df01. ]

When debugging any of the testcases added by this commit, which do a
vfork in a thread with "set follow-fork-mode child" + "set
detach-on-fork on", we run into this assertion:

...
src/gdb/nat/x86-linux-dregs.c:146: internal-error: \
  void x86_linux_update_debug_registers(lwp_info*): \
  Assertion `lwp_is_stopped (lwp)' failed.
...

The assert is caused by the following: the vfork-child exit or exec
event is handled by handle_vfork_child_exec_or_exit, which calls
target_detach to detach from the vfork parent.  During target_detach
we call linux_nat_target::detach, which:

However, during the second step we run into this code in
stop_wait_callback:

...
  /* If this is a vfork parent, bail out, it is not going to report
     any SIGSTOP until the vfork is done with.  */
  if (inf->vfork_child != NULL)
    return 0;
...

and we don't wait for the threads to be stopped, which results in this
assert in x86_linux_update_debug_registers triggering during the third
step:

...
  gdb_assert (lwp_is_stopped (lwp));
...

The fix is to reset the vfork parent's vfork_child field before
calling target_detach in handle_vfork_child_exec_or_exit.  There's
already similar code for the other paths handled by
handle_vfork_child_exec_or_exit, so this commit refactors the code a
bit so that all paths share the same code.

The new tests cover both a vfork child exiting, and a vfork child
execing, since both cases would trigger the assertion.

The new testcases also exercise following the vfork children with "set
detach-on-fork off", since it doesn't seem to be tested anywhere.

Tested on x86_64-linux, using native and native-gdbserver.

gdb/ChangeLog:
2019-04-18  Tom de Vries  <tdevries@suse.de>
    Pedro Alves  <palves@redhat.com>

PR gdb/24454
* infrun.c (handle_vfork_child_exec_or_exit): Reset vfork parent's
vfork_child field before calling target_detach.

gdb/testsuite/ChangeLog:
2019-04-18  Tom de Vries  <tdevries@suse.de>
    Pedro Alves  <palves@redhat.com>

PR gdb/24454
* gdb.threads/vfork-follow-child-exec.c: New file.
* gdb.threads/vfork-follow-child-exec.exp: New file.
* gdb.threads/vfork-follow-child-exit.c: New file.
* gdb.threads/vfork-follow-child-exit.exp: New file.

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

Suppress SIGTTOU when handling errors

[ Backport of commit 766f883622. ]

Calls to error () can cause SIGTTOU to send gdb to the background.

For example, on an Arm build:
  (gdb) b main
  Breakpoint 1 at 0x10774: file /build/gdb/testsuite/../../../src/binutils-gdb/gdb/testsuite/gdb.base/watchpoint.c, line 174.
  (gdb) r
  Starting program: /build/gdb/testsuite/outputs/gdb.base/watchpoint/watchpoint

  [1]+  Stopped                 ../gdb ./outputs/gdb.base/watchpoint/watchpoint
  localhost$ fg
  ../gdb ./outputs/gdb.base/watchpoint/watchpoint
  Cannot parse expression `.L1199 4@r4'.
  warning: Probes-based dynamic linker interface failed.
  Reverting to original interface.

The SIGTTOU is raised whilst inside a syscall during the call to tcdrain.
Fix is to use scoped_ignore_sigttou to ensure SIGTTOU is blocked.

In addition fix include comments - job_control is not included via terminal.h

gdb/ChangeLog:

* event-top.c: Remove include comment.
* inflow.c (class scoped_ignore_sigttou): Move from here...
* inflow.h (class scoped_ignore_sigttou): ...to here.
* ser-unix.c (hardwire_drain_output): Block SIGTTOU during drain.
* top.c:  Remove include comment.

Fix breakpoints on file reloads for PIE binaries

[ Backport of master commit ea142fbfc9. ]

When a binary is built using PIE, reloading the file will cause GDB to error
on restart.  For example:
gdb ./a.out
(gdb) break main
(gdb) run
(gdb) file ./a.out
(gdb) continue

Will cause GDB to error with:
Continuing.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x9e0
Command aborted.

This is due to the symbol offsets not being relocated after reloading the file.

Fix is to ensure solib_create_inferior_hook is called, in the same manner as
infrun.c:follow_exec().

Expand the idempotent test to cover PIE scenarios.

gdb/ChangeLog:

* symfile.c (symbol_file_command): Call solib_create_inferior_hook.

gdb/testsuite/ChangeLog:

* gdb.base/break-idempotent.exp: Test both PIE and non PIE.

Testsuite: Ensure pie is disabled on some tests

[ Backport of master commit 968aa7ae38. ]

Recent versions of Ubuntu and Debian default GCC to enable pie.

In dump.exp, pie will causes addresses to be out of range for IHEX.

In break-interp.exp, pie is explicitly set for some tests and assumed
to be disabled for the remainder.

Ensure pie is disabled for these tests when required.

In addition, add a pie option to gdb_compile to match the nopie option
and simplify use.

gdb/testsuite/ChangeLog:

* README: Add pie options.
* gdb.base/break-interp.exp: Ensure pie is disabled.
* gdb.base/dump.exp: Likewise.
* lib/gdb.exp (gdb_compile): Add pie option.

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 buglet in cp_print_value_fields patch

[ Backport of master commit 3d507ff23b. ]

Pedro pointed out an issue in the cp_print_value_fields
patch, aka the fix for PR c++/20020.

This patch addresses the issue.  Tested on x86-64 Fedora 29.

gdb/testsuite/ChangeLog
2019-06-27  Tom Tromey  <tromey@adacore.com>

* gdb.cp/constexpr-field.exp: Use setup_xfail.

Fix crash in cp_print_value_fields

[ Backport of master commit 4330d61dfb. ]

PR c++/20020 concerns a crash in cp_print_value_fields.  The immediate
cause is that cp_print_value_fields does not handle the case where
value_static_field fails.  This is fixed in this patch by calling
cp_print_static_field from the "try" block.

Digging a bit deeper, the error occurs because GCC does not emit a
DW_AT_const_value for a static constexpr member appearing in a
template class.  I've filed a GCC bug for this.

Tested on x86-64 Fedora 29.

gdb/ChangeLog
2019-05-29  Tom Tromey  <tromey@adacore.com>

PR c++/20020:
* cp-valprint.c (cp_print_value_fields): Call
cp_print_static_field inside "try".

gdb/testsuite/ChangeLog
2019-05-29  Tom Tromey  <tromey@adacore.com>

PR c++/20020:
* gdb.cp/constexpr-field.exp: New file.
* gdb.cp/constexpr-field.cc: New file.

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

[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