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
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.
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.
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>
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.
...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
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:
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.
projects / thirdparty / binutils-gdb.git / log
