The ld testsuite includes numerous tests that depend on being able to
compile and link programs with the C compiler. Some of these tests
use [which $CC] to check for the presence of the compiler before
proceeding with the test, but run_ld_link_exec_tests and run_cc_link_tests
give ERRORs if compilation fails. Also, even if $CC is defined and present,
it may not be usable due to missing libraries, etc.
This patch adds a new procedure check_compiler_available that attempts
to build an empty program and caches the result. Uses of [which $CC]
are replaced with calls to this procedure, and run_ld_link_exec_tests
and run_cc_link_tests now also guard attempts to use $CC.
2019-04-24 Sandra Loosemore <sandra@codesourcery.com>
ld/
* testsuite/config/default.exp: Use [check_compiler_available]
instead of [which $CC].
* testsuite/ld-auto-import/auto-import.exp: Likewise.
* testsuite/ld-cygwin/exe-export.exp: Likewise.
* testsuite/ld-elf/audit.exp: Likewise.
* testsuite/ld-elf/compress.exp: Likewise.
* testsuite/ld-elf/dwarf.exp: Likewise.
* testsuite/ld-elf/elf.exp: Likewise.
* testsuite/ld-elf/indirect.exp: Likewise.
* testsuite/ld-elf/linux-x86.exp: Likewise.
* testsuite/ld-elf/shared.exp: Likewise.
* testsuite/ld-elf/tls.exp: Likewise.
* testsuite/ld-elf/wrap.exp: Likewise.
* testsuite/ld-elfcomm/elfcomm.exp: Likewise.
* testsuite/ld-elfvers/vers.exp: Likewise.
* testsuite/ld-elfvsb/elfvsb.exp: Likewise.
* testsuite/ld-elfweak/elfweak.exp: Likewise.
* testsuite/ld-gc/gc.exp: Likewise.
* testsuite/ld-i386/i386.exp: Likewise.
* testsuite/ld-i386/no-plt.exp: Likewise.
* testsuite/ld-i386/tls.exp: Likewise.
* testsuite/ld-ifunc/ifunc.exp: Likewise.
* testsuite/ld-mn10300/mn10300.exp: Likewise.
* testsuite/ld-pe/pe-compile.exp: Likewise.
* testsuite/ld-pe/pe-run.exp: Likewise.
* testsuite/ld-pe/pe-run2.exp: Likewise.
* testsuite/ld-pie/pie.exp: Likewise.
* testsuite/ld-plugin/lto.exp: Likewise.
* testsuite/ld-plugin/plugin.exp: Likewise.
* testsuite/ld-scripts/crossref.exp: Likewise.
* testsuite/ld-sh/sh.exp: Likewise.
* testsuite/ld-shared/shared.exp: Likewise.
* testsuite/ld-size/size.exp: Likewise.
* testsuite/ld-srec/srec.exp: Likewise.
* testsuite/ld-undefined/undefined.exp: Likewise.
* testsuite/ld-unique/unique.exp: Likewise.
* testsuite/ld-x86-64/mpx.exp: Likewise.
* testsuite/ld-x86-64/no-plt.exp: Likewise.
* testsuite/ld-x86-64/tls.exp: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
* testsuite/lib/ld-lib.exp (run_ld_link_exec_tests): Call
check_compiler_available before trying to use the compiler.
(run_cc_link_tests): Likewise.
(check_compiler_available): New. Use it instead of [which $CC].
While trying to build GDB on i686, I found the following error:
In file included from ../../gdb/common/common-defs.h:105,
from ../../gdb/defs.h:28,
from ../../gdb/aarch64-tdep.c:21:
../../gdb/aarch64-tdep.c: In function 'gdbarch* aarch64_gdbarch_init(gdbarch_info, gdbarch_list*)':
../../gdb/aarch64-tdep.c:3176:43: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'uint64_t' {aka 'long long unsigned int'} [-Werror=format=]
3176 | internal_error (__FILE__, __LINE__, _("VQ out of bounds: %ld (max %d)"),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gdb/common/gdb_locale.h:28:29: note: in definition of macro '_'
28 | # define _(String) gettext (String)
| ^~~~~~
../../gdb/aarch64-tdep.c:3176:64: note: format string is defined here
3176 | internal_error (__FILE__, __LINE__, _("VQ out of bounds: %ld (max %d)"),
| ~~^
| |
| long int
| %lld
This happens because aarch64-tdep.c:aarch64_gdbarch_init prints a
"uint64_t" variable using "%ld". This patch fixes the build by using
"pulongest" instead. As explained in a similar fix (commit
495143533a), this should be safe because
if aarch64-tdep.c is included in the build, then ULONGEST must be a
64-bit type.
gdb/ChangeLog:
2019-04-24 Sergio Durigan Junior <sergiodj@redhat.com>
* aarch64-tdep.c (aarch64_gdbarch_init): Use "pulongest" to print
"vq".
Commit 4aa866af ("Fix AMD64 return value ABI in expression
evaluation") introduced a regression when calling a function with a
structure that contains bitfields.
Because the caller of amd64_has_unaligned_fields handles bitfields
already, it seemed to me that the simplest fix was to ignore bitfields
here.
gdb/ChangeLog
2019-04-24 Tom Tromey <tromey@adacore.com>
* amd64-tdep.c (amd64_has_unaligned_fields): Ignore bitfields.
gdb/testsuite/ChangeLog
2019-04-24 Tom Tromey <tromey@adacore.com>
* gdb.arch/amd64-eval.exp: Test bitfield return.
* gdb.arch/amd64-eval.cc (struct Bitfields): New.
(class Foo) <return_bitfields>: New method.
(main): Call it.
* objcopy.c (strip_main): Do not enable note merging by default if
just stripping debug or dwo information.
* doc/binutils.texi (strip): Update documentation.
In most cases we don't want expression symbols, such as that created
for an expression like "symbol + (1f - .)", resolved down to a
constant. Instead we'd like to leave the expression as "symbol +
constant" once the "1f - ." part has been resolved, and let the
backend decide whether "symbol" can be reduced further.
However, that doesn't work when trying to resolve .loc view symbols
early. We get expression symbols left as an O_symbol expression
pointing at an absolute symbol, and marked as sy_flags.sy_resolved.
That wouldn't really be a problem, but when one of those expression
symbols is used in further .loc view expressions, its value is taken
as zero.
This patch fixes the symbol value mistake, and stops creation of
O_symbol expression symbols pointing to absolute symbols. Either of
these fixes would cure the .loc view usage.
PR 24444
* symbols.c (resolve_symbol_value): When handling symbols
marked as sy_flags.resolved, return correct value for the
case of expression symbols left as an O_symbol expression.
Merge O_symbol code handling undefined and common symbols with
code handling special cases of expression symbols. Use
seg_left to test for undefined and common symbols. Don't
leave an O_symbol expression when X_add_symbol resolves to
the absolute_section. Init final_val later.
* testsuite/gas/mmix/basep-7.d: Adjust expected output.
Make use of the default gdbarch methods for gdbarch_unwind_pc, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* s12z-tdep.c (s12z_unwind_pc): Delete.
(s12z_unwind_sp): Delete.
(s12z_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch method gdbarch_unwind_sp where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* rl78-tdep.c (rl78_unwind_sp): Delete.
(rl78_gdbarch_init): Don't register deleted function with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* xstormy16-tdep.c (xstormy16_unwind_sp): Delete.
(xstormy16_unwind_pc): Delete.
(xstormy16_dummy_id): Delete.
(xstormy16_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch method gdbarch_unwind_pc where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* vax-tdep.c (vax_unwind_pc): Delete.
(vax_gdbarch_init): Don't register deleted function with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* v850-tdep.c (v850_unwind_sp): Delete.
(v850_unwind_pc): Delete.
(v850_dummy_id): Delete.
(v850_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* tilegx-tdep.c (tilegx_unwind_sp): Delete.
(tilegx_unwind_pc): Delete.
(tilegx_unwind_dummy_id): Delete.
(tilegx_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* tic6x-tdep.c (tic6x_unwind_sp): Delete.
(tic6x_dummy_id): Delete.
(tic6x_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch method gdbarch_unwind_pc where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* sparc-tdep.c (sparc_unwind_pc): Delete.
(sparc32_gdbarch_init): Don't register deleted function with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* sh-tdep.c (sh_unwind_sp): Delete.
(sh_unwind_pc): Delete.
(sh_dummy_id): Delete.
(sh_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* score-tdep.c (score_unwind_sp): Delete.
(score_unwind_pc): Delete.
(score_dummy_id): Delete.
(score_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* rx-tdep.c (rx_unwind_pc): Delete.
(rx_unwind_sp): Delete.
(rx_dummy_id): Delete.
(rx_gdbarch_init): Don't register deleted functions with
gdbarch. Update comment.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* rs6000-tdep.c (rs6000_unwind_pc): Delete.
(rs6000_dummy_id): Delete.
(rs6000_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch method gdbarch_dummy_id where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
This commit leaves or1k_unwind_sp and or1k_unwind_pc in place. These
functions do match the default methods except that they add additional
debugging code. In order to preserve the debug I have left these
functions unchanged.
gdb/ChangeLog:
* or1k-tdep.c (or1k_dummy_id): Delete.
(or1k_gdbarch_init): Don't register deleted function with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* nios2-tdep.c (nios2_dummy_id): Delete.
(nios2_unwind_sp): Delete.
(nios2_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* nds32-tdep.c (nds32_dummy_id): Delete.
(nds32_unwind_pc): Delete.
(nds32_unwind_sp): Delete.
(nds32_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* msp430-tdep.c (msp430_unwind_pc): Delete.
(msp430_unwind_sp): Delete.
(msp430_dummy_id): Delete.
(msp430_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* moxie-tdep.c (moxie_unwind_sp): Delete.
(moxie_unwind_pc): Delete.
(moxie_dummy_id): Delete.
(moxie_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* mn10300-tdep.c (mn10300_dummy_id): Delete.
(mn10300_unwind_pc): Delete.
(mn10300_unwind_sp): Delete.
(mn10300_push_dummy_call): Use gdbarch_unwind_sp not
mn10300_unwind_sp.
(mn10300_frame_unwind_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* mep-tdep.c (mep_unwind_pc): Delete.
(mep_unwind_sp): Delete.
(mep_dummy_id): Delete.
(mep_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_unwind_pc, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* m68hc11-tdep.c (m68hc11_unwind_pc): Delete.
(m68hc11_unwind_sp): Delete.
(m68hc11_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* m32r-tdep.c (m32r_unwind_sp): Delete.
(m32r_unwind_pc): Delete.
(m32r_dummy_id): Delete.
(m32r_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* m32c-tdep.c (m32c_unwind_pc): Delete.
(m32c_unwind_sp): Delete.
(m32c_dummy_id): Delete.
(m32c_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/lm32-tdep.c (lm32_unwind_sp): Delete.
(lm32_unwind_pc): Delete.
(lm32_dummy_id): Delete.
(lm32_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/iq2000-tdep.c (iq2000_unwind_sp): Delete.
(iq2000_unwind_pc): Delete.
(iq2000_dummy_id): Delete.
(iq2000_gdbarch_init): Don't register deleted functions with
gdbarch.
The general type_align method should be a suitable alternative to
nds32_type_align, so switch to use that.
The only change this will introduce is related to static fields in a
struct or union, the existing code doesn't take account of static
fields when computing the alignment for structs of unions, though this
is probably a bug - which would probably be exposed by the test case
gdb.cp/many-args.exp, though I don't have any way to test this target
right now.
gdb/ChangeLog:
* nds32-tdep.c (nds32_type_align): Delete.
(nds32_push_dummy_call): Use type_align instead.
Replaces use of arm_type_align with common type_align function.
Doing this fixes a bug in arm_type_align where static fields are
considered as part of the alignment calculation of a struct, which
results in arguments passed on the stack being misaligned, this bug
was causing a failure in gdb.cp/many-args.exp.
Part of the old arm_type_align is retained and used as the gdbarch
type align callback in order to correctly align vectors.
gdb/ChangeLog:
* arm-tdep.c (arm_type_align): Only handle vector override case.
(arm_push_dummy_call): Use type_align.
(arm_gdbarch_init): Register arm_type_align gdbarch function.
Replaces use of aarch64_type_align with common type_align function.
Doing this fixes a bug in aarch64_type_align where static fields are
considered as part of the alignment calculation of a struct, which
results in arguments passed on the stack being misaligned. This bug
is exposed in the new test gdb.cp/many-args.exp.
Part of the old aarch64_type_align is retained and used as the gdbarch
type align callback in order to correctly align vectors.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_type_align): Only handle vector override
case.
(pass_on_stack): Use type_align.
(aarch64_gdbarch_init): Register aarch64_type_align gdbarch
function.
gdb/testsuite/ChangeLog:
* gdb.cp/many-args.cc: New file.
* gdb.cp/many-args.exp: New file.
I noticed that one of the overloads of line_header::file_name_at is
unused. This patch removes it.
gdb/ChangeLog
2019-04-23 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (line_header::file_name_at): Remove unused
overload.
When running gdb.btrace/reconnect.exp with native-gdbserver, we run into:
...
FAIL: gdb.btrace/reconnect.exp: first: stepi 19
...
due to the fact that we're trying to match:
...
stepi 19^M
0x00007ffff7dd8b57 in _dl_start () from /lib64/ld-linux-x86-64.so.2^M
...
using pattern:
...
gdb_test "stepi 19" "0x.* in .* from target.*"
...
Fix this by changing the pattern to:
...
gdb_test "stepi 19" "0x.* in .* from .*"
...
Tested on x86_64-linux with native and native-gdbserver.
gdb/testsuite/ChangeLog:
2019-04-23 Tom de Vries <tdevries@suse.de>
PR gdb/24433
* gdb.btrace/reconnect.exp: Fix stepi 19 pattern.
The -m option of cc-with-tweaks.sh sets want_multi to true, invoking dwz like
this:
...
elif [ "$want_multi" = true ]; then
cp $output_file ${output_file}.alt
$DWZ -m ${output_file}.dwz "$output_file" ${output_file}.alt \
> /dev/null 2>&1
fi
...
The problem that is being solved here, is that we want to test dwz in
multifile mode, which requires more than one input file, while we only have
(at the scope of cc-with-tweaks.sh) one executable. We handle this by copying
the executable and offering this as a second input (and using a copy has the
additional benefit that it maximally enables dwz transformation).
However, after the dwz invocation, the copy is no longer used, and the
presence of the file actually causes a test regression:
...
FAIL: gdb.base/jit-so.exp: test jit-reader-load filename completion
...
Fix this by removing the superflous copy after dwz invocation.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-04-23 Tom de Vries <tdevries@suse.de>
PR gdb/24438
* contrib/cc-with-tweaks.sh: Remove superfluous .alt file after dwz
invocation.
Ubuntu/Debian defaults PIE to enabled. This causes the trace tests
to fall over due to variables being returned as "unavailable". The
tests were never designed to work with pie.
Simply ensure the nopie flag is always used for the failing tests.
This removes 100+ failures when running native-gdbserver on Ubuntu 18.04.
gdb/testsuite/ChangeLog:
* gdb.trace/backtrace.exp: Use nopie flag.
* gdb.trace/circ.exp: Likewise.
* gdb.trace/collection.exp: Likewise.
* gdb.trace/ftrace.exp: Likewise.
* gdb.trace/mi-trace-unavailable.exp: Likewise.
* gdb.trace/mi-traceframe-changed.exp: Likewise.
* gdb.trace/qtro.exp: Likewise.
* gdb.trace/read-memory.exp: Likewise.
* gdb.trace/report.exp: Likewise.
* gdb.trace/tfile.exp: Likewise.
* gdb.trace/tfind.exp: Likewise.
* gdb.trace/unavailable.exp: Likewise.
Commit c40e31a121 broke --enable-dependency-tracking=no.
* Makefile.am (GENDEPDIR): New var, used..
(GENSCRIPTS): ..here.
* Makefile.in: Regenerate.
* genscripts.sh: Test for $DEPDIR set before every use.
DW_OP_addrx is the new name of DW_OP_GNU_addr_index, and DW_FORM_addrx
is the name of DW_FORM_addr_index in the Dwarf 5 standard. This is a small
step towards supporting Dwarf 5 in gdb.
Note: I could not find any tests specifically for *_GNU_addr_index, and
I did not add any new tests, please advise.
While reviewing
https://sourceware.org/ml/gdb-patches/2019-04/msg00141.html
I noticed that we relied heavily on global state through the
get_svr4_info function, which uses current_program_space. I thought we
could improve this (make things more explicit and easier to follow) by
- Making get_svr4_info accept a program_space parameter, making it
return the SVR4 info for that program space.
- Passing down the svr4_info object from callers as much as possible.
This means looking up the svr4_info for the appropriate program space at
the entry points of the solib-svr4.c file and passing it down. For now,
these entry points (most of them are "methods" of svr4_so_ops) rely on
current_program_space, but we can later try to change the target_so_ops
interface to pass down the program space.
gdb/ChangeLog:
* solib-svr4.c (get_svr4_info): Add pspace parameter.
(svr4_keep_data_in_core): Pass current_program_space to get_svr4_info.
(open_symbol_file_object): Likewise.
(svr4_default_sos): Add info parameter.
(svr4_read_so_list): Likewise.
(svr4_current_sos_direct): Adjust functions calls to pass down
info.
(svr4_current_sos_1): Add info parameter.
(svr4_current_sos): Call get_svr4_info, pass info down to
svr4_current_sos_1.
(svr4_fetch_objfile_link_map): Pass objfile->pspace to
get_svr4_info.
(svr4_in_dynsym_resolve_code): Pass current_program_space to
get_svr4_info.
(probes_table_htab_remove_objfile_probes): Pass objfile->pspace
to get_svr4_info.
(probes_table_remove_objfile_probes): Likewise.
(register_solib_event_probe): Add info parameter.
(solist_update_incremental): Pass info parameter down to
svr4_read_so_list.
(disable_probes_interface): Add info parameter.
(svr4_handle_solib_event): Pass current_program_space to
get_svr4_info. Adjust disable_probes_interface cleanup.
(svr4_create_probe_breakpoints): Add info parameter, pass it
down to register_solib_event_probe.
(svr4_create_solib_event_breakpoints): Add info parameter,
pass it down to svr4_create_probe_breakpoints.
(enable_break): Pass info down to
svr4_create_solib_event_breakpoints.
(svr4_solib_create_inferior_hook): Pass current_program_space to
get_svr4_info.
(svr4_clear_solib): Likewise.
On systems that use the probes-based solib interface, GDB misbehaves
if you run the "nosharelibrary" command, continue execution, and then
the program hits the shared library event breakpoint. On my system it
aborts like this:
(gdb) nosharedlibrary
(gdb) c
Continuing.
pure virtual method called
terminate called without an active exception
Aborted (core dumped)
Though it's really undefined behavior territory, caused by deferencing
a dangling solib event probe pointer.
I've observed this by running "nosharedlibrary" when stopped at the
entry point, but it should happen at any other point, if the program
does a dlopen/dlclose after.
The fix is to discard an objfile's probes from the svr4 probes table
when an objfile is about to be released.
New test included, works with both native and gdbserver testing.
Valgrind log:
(gdb) starti
(gdb) nosharedlibrary
(gdb) c
Continuing.
==24895== Invalid read of size 8
==24895== at 0x89E5FB: solib_event_probe_action(probe_and_action*) (solib-svr4.c:1735)
==24895== by 0x89E95A: svr4_handle_solib_event() (solib-svr4.c:1872)
==24895== by 0x8A7198: handle_solib_event() (solib.c:1274)
==24895== by 0x4E3407: bpstat_stop_status(address_space const*, unsigned long, thread_info*, target_waitstatus const*, bpstats*) (breakpoint.c:5407)
==24895== by 0x721F41: handle_signal_stop(execution_control_state*) (infrun.c:5685)
==24895== by 0x720B11: handle_inferior_event(execution_control_state*) (infrun.c:5129)
==24895== by 0x71DD93: fetch_inferior_event(void*) (infrun.c:3748)
==24895== by 0x7059C3: inferior_event_handler(inferior_event_type, void*) (inf-loop.c:43)
==24895== by 0x874DF0: remote_async_serial_handler(serial*, void*) (remote.c:14039)
==24895== by 0x894101: run_async_handler_and_reschedule(serial*) (ser-base.c:137)
==24895== by 0x8941E6: fd_event(int, void*) (ser-base.c:188)
==24895== by 0x67AFEF: handle_file_event(file_handler*, int) (event-loop.c:732)
==24895== Address 0x18b63860 is 0 bytes inside a block of size 136 free'd
==24895== at 0x4C2E616: operator delete(void*, unsigned long) (vg_replace_malloc.c:585)
==24895== by 0x8C6A12: stap_probe::~stap_probe() (stap-probe.c:124)
==24895== by 0x66F7DB: probe_key_free(bfd*, void*) (elfread.c:1382)
==24895== by 0x69B705: bfdregistry_callback_adaptor(void (*)(registry_container*, void*), registry_container*, void*) (gdb_bfd.c:131)
==24895== by 0x855A57: registry_clear_data(registry_data_registry*, void (*)(void (*)(registry_container*, void*), registry_container*, void*), registry_container*, registry_fields*) (registry.c:79)
==24895== by 0x855B01: registry_container_free_data(registry_data_registry*, void (*)(void (*)(registry_container*, void*), registry_container*, void*), registry_container*, registry_fields*) (registry.c:92)
==24895== by 0x69B783: bfd_free_data(bfd*) (gdb_bfd.c:131)
==24895== by 0x69C4BA: gdb_bfd_unref(bfd*) (gdb_bfd.c:609)
==24895== by 0x7CC33F: objfile::~objfile() (objfiles.c:651)
==24895== by 0x7CD559: objfile_purge_solibs() (objfiles.c:1021)
==24895== by 0x8A7132: no_shared_libraries(char const*, int) (solib.c:1252)
==24895== by 0x548E3D: do_const_cfunc(cmd_list_element*, char const*, int) (cli-decode.c:106)
==24895== Block was alloc'd at
==24895== at 0x4C2D42A: operator new(unsigned long) (vg_replace_malloc.c:334)
==24895== by 0x8C527C: handle_stap_probe(objfile*, sdt_note*, std::vector<probe*, std::allocator<probe*> >*, unsigned long) (stap-probe.c:1561)
==24895== by 0x8C5535: stap_static_probe_ops::get_probes(std::vector<probe*, std::allocator<probe*> >*, objfile*) const (stap-probe.c:1656)
==24895== by 0x66F71B: elf_get_probes(objfile*) (elfread.c:1365)
==24895== by 0x7EDD85: find_probes_in_objfile(objfile*, char const*, char const*) (probe.c:227)
==24895== by 0x4DF382: create_longjmp_master_breakpoint() (breakpoint.c:3275)
==24895== by 0x4F6562: breakpoint_re_set() (breakpoint.c:13828)
==24895== by 0x8A66AA: solib_add(char const*, int, int) (solib.c:1010)
==24895== by 0x89F7C6: enable_break(svr4_info*, int) (solib-svr4.c:2360)
==24895== by 0x8A104C: svr4_solib_create_inferior_hook(int) (solib-svr4.c:2992)
==24895== by 0x8A70B9: solib_create_inferior_hook(int) (solib.c:1215)
==24895== by 0x70C073: post_create_inferior(target_ops*, int) (infcmd.c:467)
==24895==
pure virtual method called
terminate called without an active exception
==24895==
==24895== Process terminating with default action of signal 6 (SIGABRT): dumping core
==24895== at 0x7CF3750: raise (raise.c:51)
==24895== by 0x7CF4D30: abort (abort.c:79)
==24895== by 0xB008F4: __gnu_cxx::__verbose_terminate_handler() (in build/gdb/gdb)
==24895== by 0xAFF845: __cxxabiv1::__terminate(void (*)()) (in build/gdb/gdb)
==24895== by 0xAFF890: std::terminate() (in build/gdb/gdb)
==24895== by 0xAFF95E: __cxa_pure_virtual (in build/gdb/gdb)
==24895== by 0x89E610: solib_event_probe_action(probe_and_action*) (solib-svr4.c:1735)
==24895== by 0x89E95A: svr4_handle_solib_event() (solib-svr4.c:1872)
==24895== by 0x8A7198: handle_solib_event() (solib.c:1274)
==24895== by 0x4E3407: bpstat_stop_status(address_space const*, unsigned long, thread_info*, target_waitstatus const*, bpstats*) (breakpoint.c:5407)
==24895== by 0x721F41: handle_signal_stop(execution_control_state*) (infrun.c:5685)
==24895== by 0x720B11: handle_inferior_event(execution_control_state*) (infrun.c:5129)
==24895==
Note, this little bit in the patch is just a cleanup that I noticed:
- lookup.prob = prob;
lookup.address = address;
That line isn't necessary because hashing/comparison only looks at the
address.
gdb/ChangeLog:
2019-04-22 Pedro Alves <palves@redhat.com>
* solib-svr4.c (svr4_free_objfile_observer): New.
(probe_and_action::objfile): New field.
(probes_table_htab_remove_objfile_probes)
(probes_table_remove_objfile_probes): New functions.
(register_solib_event_probe): Add 'objfile' parameter. Store it
in the new probe_and_action. Don't store the probe in 'lookup'.
(svr4_create_probe_breakpoints): Pass objfile to
register_solib_event_probe.
(_initialize_svr4_solib): Register a free_objfile observer.
gdb/testsuite/ChangeLog:
2019-04-22 Pedro Alves <palves@redhat.com>
* gdb.base/solib-probes-nosharedlibrary.c,
gdb.base/solib-probes-nosharedlibrary.exp: New files.
gdb/doc/ChangeLog:
2019-04-22 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Reverse Execution): Mention and xref process record
and replay. Mention remote and system emulators.
(Process Record and Replay): List supported architectures.
Mention that "record btrace" is only supported on Intel
processors.
