[ Backport of master commit c1a5d03a89. ]
gdb should normally not be linked with -static-libstdc++. Currently
this has not caused problems, but it's incompatible with catching an
exception thrown from a shared library -- and a subsequent patch
changes gdb to do just this.
This patch adds a new --with-static-standard-libraries flag to the
top-level configure. It defaults to "auto", which means enabled if
gcc is being built, and disabled otherwise.
ChangeLog
2019-08-19 Tom Tromey <tom@tromey.com>
PR gdb/25009
* configure: Rebuild.
* configure.ac: Add --with-static-standard-libraries.
[ 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.
[ 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'.
[ 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.
[ 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.
