aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-04-24Use better test for usable compiler in ld testsuite.Sandra Loosemore41-55/+155
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].
2019-04-24Use "pulongest" on aarch64-tdep.c:aarch64_gdbarch_initSergio Durigan Junior2-2/+7
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 495143533ad95369811391c6e3c6dadd69d7dd67), 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".
2019-04-24Fix passing of struct with bitfields on x86-64Tom Tromey5-4/+37
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.
2019-04-24Stop strip from merging notes when stripping debug or dwo information.Nick Clifton3-3/+20
* objcopy.c (strip_main): Do not enable note merging by default if just stripping debug or dwo information. * doc/binutils.texi (strip): Update documentation.
2019-04-24resolve_symbol_value vs. .loc view resolutionAlan Modra3-29/+35
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.
2019-04-24S12Z: Opcodes: Handle bit map operations with non-canonical operands.John Darrington5-4/+21
opcodes/ * s12z-opc.c (bm_decode): Handle the RESERVERD0 case. gas/ * testsuite/gas/s12z/bit-manip-invalid.d: Extend the test. * testsuite/gas/s12z/bit-manip-invalid.s: Extend the test.
2019-04-24S12Z: s12z-opc.h: Add extern "C" bracketingJohn Darrington2-1/+13
opcodes/ * s12z-opc.h: Add extern "C" bracketing to help users who wish to use this interface in c++ code.
2019-04-24Automatic date update in version.inGDB Administrator1-1/+1
2019-04-23gdb/s12z: Use default gdbarch methods where possibleAndrew Burgess2-18/+7
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.
2019-04-23gdb/rl78: Use default gdbarch methods where possibleAndrew Burgess2-9/+5
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.
2019-04-23gdb/xstormy16: Use default gdbarch methods where possibleAndrew Burgess2-23/+8
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.
2019-04-23gdb/vax: Use default gdbarch methods where possibleAndrew Burgess2-7/+5
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.
2019-04-23gdb/v850: Use default gdbarch methods where possibleAndrew Burgess2-25/+8
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.
2019-04-23gdb/tilegx: Use default gdbarch methods where possibleAndrew Burgess2-26/+8
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.
2019-04-23gdb/tic6x: Use default gdbarch methods where possibleAndrew Burgess2-22/+7
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.
2019-04-23gdb/sparc: Use default_unwind_pcAndrew Burgess2-9/+6
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.
2019-04-23gdb/sh: Use default gdbarch methods where possibleAndrew Burgess2-25/+8
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.
2019-04-23gdb/score: Use default gdbarch methods where possibleAndrew Burgess2-23/+8
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.
2019-04-23gdb/rx: Use default gdbarch methods where possibleAndrew Burgess2-36/+10
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.
2019-04-23gdb/rs6000: Use default gdbarch methods where possibleAndrew Burgess2-18/+7
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.
2019-04-23gdb/or1k: Use default gdbarch methods where possibleAndrew Burgess2-9/+5
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.
2019-04-23gdb/nios2: Use default gdbarch methods where possibleAndrew Burgess2-20/+7
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.
2019-04-23gdb/nds32: Use default gdbarch methods where possibleAndrew Burgess2-28/+8
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.
2019-04-23gdb/msp430: Use default gdbarch methods where possibleAndrew Burgess2-32/+8
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.
2019-04-23gdb/moxie: Use default gdbarch methods where possibleAndrew Burgess2-33/+8
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.
2019-04-23gdb/mn10300: Use default gdbarch methods where possibleAndrew Burgess2-31/+11
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.
2019-04-23gdb/mep: Use default gdbarch methods where possibleAndrew Burgess2-29/+8
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.
2019-04-23gdb/m68hc11: Use default gdbarch methods where possibleAndrew Burgess2-24/+7
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.
2019-04-23gdb/m32r: Use default gdbarch methods where possibleAndrew Burgess2-37/+8
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.
2019-04-23gdb/m32c: Use default gdbarch methods where possibleAndrew Burgess2-34/+8
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.
2019-04-23gdb/lm32: Use default gdbarch methods where possibleAndrew Burgess2-23/+8
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.
2019-04-23gdb/iq2000: Use default gdbarch methods where possibleAndrew Burgess2-22/+8
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.
2019-04-23gdb/nds32: Use type_align instead of nds32_type_alignAndrew Burgess2-47/+7
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.
2019-04-23gdb/arm: Use type_align instead of arm_type_alignAndrew Burgess2-51/+23
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.
2019-04-23gdb/aarch64: Use type_align instead of aarch64_type_alignAndrew Burgess5-51/+144
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.
2019-04-23Remove unused overload of line_header::file_name_atTom Tromey2-8/+5
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.
2019-04-23[gdb/testsuite] Fix gdb.btrace/reconnect.exp with native-gdbserverTom de Vries2-1/+6
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.
2019-04-23[gdb/contrib] Remove superfluous .alt file after dwz invocation in ↵Tom de Vries2-0/+7
cc-with-tweaks.sh 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.
2019-04-23Testsuite: Remove pie from trace testsAlan Hayward13-12/+27
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.
2019-04-23Update binutils release making documenation to mention changing the symbolic ↵Nick Clifton2-0/+7
documentation link. * README-how-to-make-a-release: Add note to update the symbolic link from "docs" to "docs-2.x" on the sourceware website.
2019-04-23Fix automatic makefile dependencies for generated ld/e*.cAlan Modra4-17/+36
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.
2019-04-22Fix M5100 flags test with interAptiv-MR2Matthew Fortune2-1/+7
ld/ * testsuite/ld-mips-elf/mips-elf-flags.exp: Fix expected ASEs for M5100.
2019-04-22Support for DW_OP_addrx and DW_FORM_addrx tagsAli Tamur6-10/+44
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.
2019-04-23Automatic date update in version.inGDB Administrator1-1/+1
2019-04-22[FYI] Add myself to gdb/MAINTAINERSAli Tamur2-0/+5
2019-04-22RISC-V: Enable 32-bit linux gdb core file support.Jim Wilson2-1/+5
bfd/ * elfnn-riscv.c (PRSTATUS_SIZE) [ARCH_SIZE==32]: Change from 0 to 204.
2019-04-22solib-svr4: Pass down svr4_info as much as possibleSimon Marchi2-43/+76
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.
2019-04-22Fix "nosharedlibrary + continue + shared lib event" crashPedro Alves5-3/+133
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.
2019-04-22Improve reverse debugging docs, mention built-in support and supports archsPedro Alves2-7/+27
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.
2019-04-22Automatic date update in version.inGDB Administrator1-1/+1