H.J. Lu [Mon, 29 Jan 2018 12:54:57 +0000 (04:54 -0800)]
ld: Skip unsupported static executable tests
Skip static executable tests if static executable is unsupported.
Tested on Linux/x86 without libc.a.
PR ld/22732
* testsuite/config/default.exp (STATIC_LDFLAGS): New. Set to
"-static" if target compiler supports it.
* testsuite/ld-bootstrap/bootstrap.exp: Skip static executable
tests if target compiler doesn't support it.
* testsuite/ld-ifunc/ifunc.exp: Likewise.
* testsuite/lib/ld-lib.exp (run_ld_link_exec_tests): Likewise.
(run_cc_link_tests): Likewise.
Alan Modra [Fri, 26 Jan 2018 21:49:33 +0000 (08:19 +1030)]
PR22741, objcopy segfault on fuzzed COFF object
PR 22741
* coffgen.c (coff_pointerize_aux): Ensure auxent tagndx is in
range before converting to a symbol table pointer.
GDB Administrator [Mon, 29 Jan 2018 00:00:28 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Sun, 28 Jan 2018 17:07:30 +0000 (12:07 -0500)]
Remove dwarf2_per_objfile_free and use after free of dwarf2_per_objfile
I got some crashes while doing some work with dwarf2_per_objfile. It
turns out that dwarf2_per_objfile_free is using the dwarf2_per_objfile
objects after their destructor has ran.
The easiest way to reproduce this is to run the inferior twice (do
"start" twice). Currently, it goes unnoticed, but when I tried to
change all_comp_units and all_type_units to std::vectors, things started
crashing.
The dwarf2_per_objfile objects get destroyed here:
#0 dwarf2_per_objfile::~dwarf2_per_objfile (this=0x35afe70, __in_chrg=<optimized out>) at /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:2422
#1 0x0000000000833282 in dwarf2_free_objfile (objfile=0x356cff0) at /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:25363
#2 0x0000000000699255 in elf_symfile_finish (objfile=0x356cff0) at /home/emaisin/src/binutils-gdb/gdb/elfread.c:1309
#3 0x0000000000911ed3 in objfile::~objfile (this=0x356cff0, __in_chrg=<optimized out>) at /home/emaisin/src/binutils-gdb/gdb/objfiles.c:674
and just after that the dwarf2read per-objfile registry cleanup function
gets called:
#0 dwarf2_per_objfile_free (objfile=0x356cff0, d=0x35afe70) at /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:25667
... registry boilerplate ...
#4 0x00000000009103ea in objfile_free_data (container=0x356cff0) at /home/emaisin/src/binutils-gdb/gdb/objfiles.c:61
#5 0x0000000000911ee2 in objfile::~objfile (this=0x356cff0, __in_chrg=<optimized out>) at /home/emaisin/src/binutils-gdb/gdb/objfiles.c:678
In dwarf2_per_objfile_free, we access fields of the dwarf2_per_objfile
object, which is invalid since its destructor has been executed.
This patch moves the content of dwarf2_per_objfile_free to the
destructor of dwarf2_per_objfile. The call to
register_objfile_data_with_cleanup in _initialize_dwarf2_read can be
changed to the simpler register_objfile_data.
gdb/ChangeLog:
* dwarf2read.c (free_dwo_files): Add forward-declaration.
(dwarf2_per_objfile::~dwarf2_per_objfile): Move content from
dwarf2_per_objfile_free here.
(dwarf2_per_objfile_free): Remove.
(_initialize_dwarf2_read): Don't register
dwarf2_per_objfile_free as a registry cleanup.
Nick Clifton [Sun, 28 Jan 2018 16:35:37 +0000 (16:35 +0000)]
Update release notes with a reminder to check the gpg key being used.
* README-how-to-make-a-release: Add note about checking gpg key
and the results of gnupload.
H.J. Lu [Sun, 28 Jan 2018 00:04:34 +0000 (16:04 -0800)]
Add a testcase for PR ld/22751
Since dummy.o must be placed before
-Wl,--whole-archive tmpdir/pr22751.a -Wl,--no-whole-archive
to trigger the bug, this patch adds an optional trailing ld options to
run_ld_link_exec_tests.
PR ld/22751
* testsuite/config/default.exp (INT128_CFLAGS): New.
* testsuite/ld-plugin/lto.exp (INT128_CFLAGS): New.
Run ld/22751 tests.
* testsuite/ld-plugin/pr22751.c: New file.
* testsuite/lib/ld-lib.exp (run_ld_link_exec_tests): Add
ld trailing options.
GDB Administrator [Sun, 28 Jan 2018 00:00:32 +0000 (00:00 +0000)]
Automatic date update in version.in
Alan Modra [Sat, 27 Jan 2018 21:33:26 +0000 (08:03 +1030)]
PR22751, LTO broken for libgcc libcalls
So what was happening was that the file added from libgcc.a during the
rescan was not put on file_chain. map_input_to_output_sections then
doesn't see the file and its sections are treated as discarded.
The file_chain list pointer bug was caused by that fact that an
archive element claimed by the plugin does not have my_archive set.
Or more correctly, the actual archive element does have my_archive
set, but this bfd is replaced with a dummy bfd that doesn't have
my_archive set.
PR 22751
* ldlang.c (find_rescan_insertion): Look past bfds with claim_archive
set.
Nick Clifton [Sat, 27 Jan 2018 16:37:24 +0000 (16:37 +0000)]
Update documentation on making a release
Eli Zaretskii [Sat, 27 Jan 2018 16:34:46 +0000 (18:34 +0200)]
Avoid compilation errors in MinGW native builds of GDB
The error is triggered by including python-internal.h, and the
error message is:
In file included from d:\usr\lib\gcc\mingw32\6.3.0\include\c++\math.h:36:0,
from build-gnulib/import/math.h:27,
from d:/usr/Python26/include/pyport.h:235,
from d:/usr/Python26/include/Python.h:58,
from python/python-internal.h:94,
from python/py-arch.c:24:
d:\usr\lib\gcc\mingw32\6.3.0\include\c++\cmath:1157:11: error: '::hypot' has not been declared
using ::hypot;
^~~~~
This happens because Python headers define 'hypot' to expand to
'_hypot' in the Windows builds.
gdb/ChangeLog:
2018-01-27 Eli Zaretskii <eliz@gnu.org>
* python/python-internal.h (_hypot) [__MINGW32__]: Define back to
'hypoth'. This avoids a compilation error.
Eli Zaretskii [Sat, 27 Jan 2018 16:25:06 +0000 (18:25 +0200)]
Avoid compilation warning in libiberty/simple-object-xcoff.c
gdb/ChangeLog:
2018-01-27 Eli Zaretskii <eliz@gnu.org>
* simple-object-xcoff.c (simple_object_xcoff_find_sections): Avoid
compilation warning in 32-bit builds not supported by
AC_SYS_LARGEFILE.
Nick Clifton [Sat, 27 Jan 2018 14:25:50 +0000 (14:25 +0000)]
Updated Russian translation for the bfd sub-directory
GDB Administrator [Sat, 27 Jan 2018 00:01:04 +0000 (00:01 +0000)]
Automatic date update in version.in
Maciej W. Rozycki [Fri, 26 Jan 2018 23:05:06 +0000 (23:05 +0000)]
MIPS/LD: Correct `mips-*-windiss' target emulation configuration
Fix an issue with commit
73934d319dae ("Disable .gnu.hash on MIPS
targets"), <https://sourceware.org/ml/binutils/2006-07/msg00341.html>,
which in turn caused a regression with commit
861fb55ab50a ("Defer
allocation of R_MIPS_REL32 GOT slots"),
<https://sourceware.org/ml/binutils/2008-08/msg00096.html>, and use
`mipself.em' as the extra emulation file for `mips-*-windiss' targets,
removing a segmentation fault triggered as `_bfd_mips_elf_final_link'
calls `htab_traverse' to process LA25 stubs with `htab->la25_stubs'
being NULL. This is in turn due to `_bfd_mips_elf_init_stubs' not
having been called, which is only done by `mipself.em'. No LA25 stubs
are supposed to be produced for `mips-*-windiss' targets, however the
internal data structures have to be initialized.
ld/
* emulparams/elf32mipswindiss.sh (EXTRA_EM_FILE): Set to
`mipself'.
Maciej W. Rozycki [Fri, 26 Jan 2018 23:05:05 +0000 (23:05 +0000)]
MIPS/GAS: Correct `mips-*-windiss' target emulation configuration
Fix a commit
0a44bf6950b3 ("mips-vxworks support"),
<https://sourceware.org/ml/binutils/2006-03/msg00179.html>, regression
and override the choice of the `vxworks' target environment introduced
with commit
ea3eed15006f ("Add generic vxworks GAS target."),
<https://sourceware.org/ml/binutils/2005-01/msg00052.html>, for
`mips-*-windiss' targets as they have not been converted to the VxWorks
target format introduced with the former commit, removing a GAS target
format selection failure:
Assembler messages:
Fatal error: selected target format 'elf32-bigmips-vxworks' unknown
on any assembly attempt with `mips-windiss' and equivalent target
configurations.
gas/
* configure.tgt: Use generic emulation for `mips-*-windiss',
overriding the blanket choice made for `*-*-windiss'.
Maciej W. Rozycki [Fri, 26 Jan 2018 23:05:05 +0000 (23:05 +0000)]
MIPS/GAS: Correct `mips-*-sysv4*' target emulation configuration
Use `mips-*-sysv4*' rather than `mips-*-sysv4*MP*' to match the system
type for System V Release 4 MIPS targets, removing a GAS target
selection failure:
Assembler messages:
Fatal error: selected target format 'elf32-bigmips' unknown
on any assembly attempt with `mips-sysv4' and equivalent target
configurations. These would typically be called `mips-sni-sysv4'
(Sinix) vs `mips-dde-sysv4.2MP' (Supermax).
This corrects commit
8614eeee67f9 ("Traditional MIPS patches"),
<https://sourceware.org/ml/binutils/2000-07/msg00018.html>, making GAS
target selection match commit
dd745cfae548 ("Traditional MIPS patches"),
<https://sourceware.org/ml/binutils/2000-07/msg00018.html>, and commit
3548145dcbf6 ("Traditional MIPS patches"),
<https://sourceware.org/ml/binutils/2000-07/msg00018.html>, which added
support for these targets to BFD and LD respectively.
gas/
* configure.tgt: Use `mips-*-sysv4*' rather than
`mips-*-sysv4*MP*'.
Alan Hayward [Fri, 26 Jan 2018 14:34:52 +0000 (14:34 +0000)]
Add myself as a write-after-approval GDB maintainer.
gdb/
* MAINTAINERS (Write After Approval): Add Alan Hayward.
Alan Hayward [Fri, 26 Jan 2018 14:34:52 +0000 (14:34 +0000)]
Add myself as a write-after-approval GDB maintainer.
gdb/
* MAINTAINERS (Write After Approval): Add Alan Hayward.
Nick Clifton [Fri, 26 Jan 2018 11:14:26 +0000 (11:14 +0000)]
Update notes on making a release
Alan Modra [Wed, 24 Jan 2018 04:52:17 +0000 (15:22 +1030)]
PowerPC PLT stub matching
This patch fixes a number of bugs in ppc32 plt stub matching code.
1) The 4-insn stubs for shared libs and PIEs weren't matched.
2) The executable stub miscalculated PLT entry address (by oring a
sign-extended quantity rather than adding).
3) Comments were not accurate.
In addition, the insn arrays are made const.
* ppc-linux-tdep.c (powerpc32_plt_stub): Make const.
(powerpc32_plt_stub_so_1): Rename from powerpc32_plt_stub_so.
Remove nop. Make const. Comment.
(powerpc32_plt_stub_so_2): New.
(POWERPC32_PLT_CHECK_LEN): Rename from POWERPC32_PLT_STUB_LEN.
Correct count. Update uses.
(ppc_skip_trampoline_code): Match powerpc32_plt_stub_so_2 too.
Move common code reading PLT entry word. Correct
powerpc32_plt_stub PLT address calculation.
* ppc64-tdep.c (ppc64_standard_linkage1): Make const.
(ppc64_standard_linkage2, ppc64_standard_linkage3): Likewise.
(ppc64_standard_linkage4, ppc64_standard_linkage5): Likewise.
(ppc64_standard_linkage6, ppc64_standard_linkage7): Likewise.
(ppc64_standard_linkage8): Likewise.
* rs6000-tdep.c (ppc_insns_match_pattern): Make pattern const.
Correct insns description.
* ppc-tdep.h (ppc_insns_match_pattern): Update prototype.
Reviewed-By: Yao Qi <qiyaoltc@gmail.com>
Alan Modra [Tue, 23 Jan 2018 00:20:02 +0000 (10:50 +1030)]
Define __start/__stop symbols when there is only a dynamic def
This patch fixes a case where a user had a C-representable named
section in both the executable and shared libraries, and of course
wanted the size of the local section in the executable, not the
dynamic section. It does mean that __start and __stop symbols don't
behave exactly like PROVIDEd symbols, but I think that's a reasonable
difference particularly since this is the way they used to behave.
* elflink.c (bfd_elf_define_start_stop): Override symbols when
they are defined dynamically.
Alan Modra [Fri, 26 Jan 2018 01:55:09 +0000 (12:25 +1030)]
PowerPC64 .branch_lt size change leads to "stubs don't match calculated size"
https://bugzilla.redhat.com/show_bug.cgi?id=
1523457
I haven't analyzed this myself, I'm relying on Nick's excellent
analysis. What I believe is happening is that after some number of
stub sizing iterations, a long-branch stub needs to be converted to a
plt-branch, but either due to stub alignment or other stubs shrinking
in size, the stub group section size doesn't change.
That means we exit from ppc64_elf_size_stubs after sizing with an
incorrect layout, in fact the additional .branch_lt entry overlays
.got! Since .TOC. is normally set to .got + 0x8000 the stub sizing
code decides that entry is within +/-32k of the TOC pointer and so a
three insn stub is sufficient. When we come to build the stubs using
a correct non-overlaying layout, a four insn plt-branch stub is
generated and the stub group size doesn't match that calculated
earlier.
* elf64-ppc.c (ppc64_elf_size_stubs): Iterate sizing when
.branch_lt changes size.
GDB Administrator [Fri, 26 Jan 2018 00:00:35 +0000 (00:00 +0000)]
Automatic date update in version.in
Alan Modra [Thu, 25 Jan 2018 11:17:41 +0000 (21:47 +1030)]
PR22746, crash when running 32-bit objdump on corrupted file
Avoid unsigned int overflow by performing bfd_size_type multiplication.
PR 22746
* elfcode.h (elf_object_p): Avoid integer overflow.
Eric Botcazou [Thu, 25 Jan 2018 11:16:06 +0000 (12:16 +0100)]
Fix PR ld/22727 (TLS breakage in PIC/PIE mode on SPARC).
There are actually 2 different bugs:
1. TLS transition is broken in PIE mode.
2. TLS is broken in PIC/PIE mode when the __tls_get_addr symbol
is versioned (as is the case on Linux and Solaris at least).
The 1st bug is fixed by reverting the problematic change for now
(note that the associated test doesn't pass on SPARC because of another
issue so there is no formal regression in the testsuite). The 2nd bug
is fixed by changing the call to _bfd_generic_link_add_one_symbol
on __tls_get_addr into a mere lookup in _bfd_sparc_elf_check_relocs.
bfd/
* elfxx-sparc.c (_bfd_sparc_elf_check_relocs) <R_SPARC_TLS_GD_CALL>:
Do a mere lookup of the __tls_get_addr symbol instead of adding it.
Revert
2017-10-19 H.J. Lu <hongjiu.lu@intel.com>
PR ld/22263
* elfxx-sparc.c (sparc_elf_tls_transition): Replace
bfd_link_pic with !bfd_link_executable, !bfd_link_pic with
bfd_link_executable for TLS check.
(_bfd_sparc_elf_check_relocs): Likewise.
(allocate_dynrelocs): Likewise.
(_bfd_sparc_elf_relocate_section): Likewise.
ld/
* testsuite/ld-sparc/sparc.exp (32-bit: Helper shared library):
Link with a version script.
(32-bit: TLS -fpie): New test.
(64-bit: Helper shared library): Link with a version script.
(64-bit: TLS -fpie): New test.
(64-bit: GOTDATA relocations): Pass -Av9 to the assembler.
* testsuite/ld-sparc/tlslib.ver: New file.
* testsuite/ld-sparc/tlspie32.dd: Likewise.
* testsuite/ld-sparc/tlspie32.s: Likewise.
* testsuite/ld-sparc/tlspie64.dd: Likewise.
* testsuite/ld-sparc/tlspie64.s: Likewise.
* testsuite/ld-sparc/tlssunbin32.dd: Adjust for versioned symbol.
* testsuite/ld-sparc/tlssunbin32.rd: Likewise.
* testsuite/ld-sparc/tlssunbin32.sd: Likewise.
* testsuite/ld-sparc/tlssunbin64.dd: Likewise.
* testsuite/ld-sparc/tlssunbin64.rd: Likewise.
* testsuite/ld-sparc/tlssunbin64.sd: Likewise.
GDB Administrator [Thu, 25 Jan 2018 00:00:20 +0000 (00:00 +0000)]
Automatic date update in version.in
Pedro Alves [Wed, 24 Jan 2018 17:22:05 +0000 (17:22 +0000)]
Fix GCC PR83906 - [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4
GCC PR83906 [1] is about a GCC/libstdc++ GDB/Python type printer
testcase failing randomly, as shown by running (in libstdc++'s
testsuite):
make check RUNTESTFLAGS=prettyprinters.exp=80276.cc
in a loop. Sometimes you get this:
FAIL: libstdc++-prettyprinters/80276.cc whatis p4
I.e., this:
type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >>[]>>[99]>
instead of this:
type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::string>[]>>[99]>
Jonathan Wakely tracked it on the printer side to this bit in
libstdc++'s type printer:
if self.type_obj == type_obj:
return strip_inline_namespaces(self.name)
This assumes the two types resolve to the same gdb.Type but some times
the comparison unexpectedly fails.
Running the testcase manually under Valgrind finds the problem in GDB:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
==6118== Conditional jump or move depends on uninitialised value(s)
==6118== at 0x4C35CB0: bcmp (vg_replace_strmem.c:1100)
==6118== by 0x6F773A: check_types_equal(type*, type*, VEC_type_equality_entry_d**) (gdbtypes.c:3515)
==6118== by 0x6F7B00: check_types_worklist(VEC_type_equality_entry_d**, bcache*) (gdbtypes.c:3618)
==6118== by 0x6F7C03: types_deeply_equal(type*, type*) (gdbtypes.c:3655)
==6118== by 0x4D5B06: typy_richcompare(_object*, _object*, int) (py-type.c:1007)
==6118== by 0x63D7E6C: PyObject_RichCompare (object.c:961)
==6118== by 0x646EAEC: PyEval_EvalFrameEx (ceval.c:4960)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That "bcmp" call is really a memcmp call in check_types_equal. The
problem is that gdb is memcmp'ing two objects that are equal in value:
(top-gdb) p *TYPE_RANGE_DATA (type1)
$1 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0,
flag_bound_evaluated = 0}
(top-gdb) p *TYPE_RANGE_DATA (type2)
$2 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0,
flag_bound_evaluated = 0}
but differ in padding. Notice the 4-byte hole:
(top-gdb) ptype /o range_bounds
/* offset | size */ type = struct range_bounds {
/* 0 | 16 */ struct dynamic_prop {
/* 0 | 4 */ dynamic_prop_kind kind;
/* XXX 4-byte hole */
/* 8 | 8 */ union dynamic_prop_data {
/* 8 */ LONGEST const_val;
/* 8 */ void *baton;
/* total size (bytes): 8 */
} data;
which is filled with garbage:
(top-gdb) x /40bx TYPE_RANGE_DATA (type1)
0x2fa7ea0: 0x01 0x00 0x00 0x00 0x43 0x01 0x00 0x00
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0x2fa7ea8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x2fa7eb0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00
0x2fa7eb8: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x2fa7ec0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
(top-gdb) x /40bx TYPE_RANGE_DATA (type2)
0x20379b0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0x20379b8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x20379c0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00
0x20379c8: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x20379d0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
(top-gdb) p memcmp (TYPE_RANGE_DATA (type1), TYPE_RANGE_DATA (type2), sizeof (*TYPE_RANGE_DATA (type1)))
$3 = -187
In some cases objects of type range_bounds are memset when allocated,
but then their dynamic_prop low/high fields are copied over from some
template dynamic_prop object that wasn't memset. E.g.,
create_static_range_type's low/high locals are left with garbage in
the padding, and then that padding is copied over to the range_bounds
object's low/high fields.
At first, I considered making sure to always memset range_bounds
objects, thinking that maybe type objects are being put in some bcache
instance somewhere. But then I hacked bcache/bcache_full to poison
non-pod types, and made dynamic_prop a non-pod, and GDB still
compiled.
So given that, it seems safest to not assume padding will always be
memset, and instead treat them as regular value types, implementing
(in)equality operators and using those instead of memcmp.
This fixes the random FAILs in GCC's testcase.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906
gdb/ChangeLog:
2018-01-24 Pedro Alves <palves@redhat.com>
GCC PR libstdc++/83906
* gdbtypes.c (operator==(const dynamic_prop &,
const dynamic_prop &)): New.
(operator==(const range_bounds &, const range_bounds &)): New.
(check_types_equal): Use them instead of memcmp.
* gdbtypes.h (operator==(const dynamic_prop &,
const dynamic_prop &)): Declare.
(operator!=(const dynamic_prop &, const dynamic_prop &)): Declare.
(operator==(const range_bounds &, const range_bounds &)): Declare.
(operator!=(const range_bounds &, const range_bounds &)): Declare.
Renlin Li [Thu, 18 Jan 2018 12:17:55 +0000 (12:17 +0000)]
[LD][AARCH64]Add group relocations to create PC-relative offset.
This is a patch to add linker support for group relocations to create a
16, 32, 48, or 64 bit PC-relative offset inline.
The following relocations are added along with the test cases:
BFD_RELOC_AARCH64_MOVW_PREL_G0, BFD_RELOC_AARCH64_MOVW_PREL_G0_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G1, BFD_RELOC_AARCH64_MOVW_PREL_G1_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G2, BFD_RELOC_AARCH64_MOVW_PREL_G2_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G3.
bfd/
2018-01-24 Renlin Li <renlin.li@arm.com>
* elfnn-aarch64.c (elfNN_aarch64_final_link_relocate): Add support for
BFD_RELOC_AARCH64_MOVW_PREL_G0, BFD_RELOC_AARCH64_MOVW_PREL_G0_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G1, BFD_RELOC_AARCH64_MOVW_PREL_G1_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G2, BFD_RELOC_AARCH64_MOVW_PREL_G2_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G3.
* elfxx-aarch64.c (_bfd_aarch64_elf_put_addend): Likewise.
(_bfd_aarch64_elf_resolve_relocation): Likewise.
ld/
2018-01-24 Renlin Li <renlin.li@arm.com>
* testsuite/ld-aarch64/aarch64-elf.exp: Run new testes.
* testsuite/ld-aarch64/emit-relocs-287.s: Fix test case.
* testsuite/ld-aarch64/emit-relocs-287.d: Fix expected output.
* testsuite/ld-aarch64/emit-relocs-287-overflow.s: New.
* testsuite/ld-aarch64/emit-relocs-287-overflow.d: New.
* testsuite/ld-aarch64/emit-relocs-288.d: New.
* testsuite/ld-aarch64/emit-relocs-288.s: New.
* testsuite/ld-aarch64/emit-relocs-289.d: New.
* testsuite/ld-aarch64/emit-relocs-289.s: New.
* testsuite/ld-aarch64/emit-relocs-289-overflow.s: New.
* testsuite/ld-aarch64/emit-relocs-289-overflow.d: New.
* testsuite/ld-aarch64/emit-relocs-290.d: New.
* testsuite/ld-aarch64/emit-relocs-290.s: New.
* testsuite/ld-aarch64/emit-relocs-291.d: New.
* testsuite/ld-aarch64/emit-relocs-291.s: New.
* testsuite/ld-aarch64/emit-relocs-291-overflow.s: New.
* testsuite/ld-aarch64/emit-relocs-291-overflow.d: New.
* testsuite/ld-aarch64/emit-relocs-292.d: New.
* testsuite/ld-aarch64/emit-relocs-292.s: New.
* testsuite/ld-aarch64/emit-relocs-293.d: New.
* testsuite/ld-aarch64/emit-relocs-293.s: New.
Renlin Li [Thu, 18 Jan 2018 12:08:40 +0000 (12:08 +0000)]
[GAS][AARCH64]Add group relocations to create PC-relative offset.
This is a patch to add the gas support for group relocations to create a
16, 32, 48, or 64 bit PC-relative offset inline.
The following relocations are added along with the test cases:
BFD_RELOC_AARCH64_MOVW_PREL_G0, BFD_RELOC_AARCH64_MOVW_PREL_G0_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G1, BFD_RELOC_AARCH64_MOVW_PREL_G1_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G2, BFD_RELOC_AARCH64_MOVW_PREL_G2_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G3.
bfd/
2018-01-24 Renlin Li <renlin.li@arm.com>
* reloc.c: Add BFD_RELOC_AARCH64_MOVW_PREL_G0,
BFD_RELOC_AARCH64_MOVW_PREL_G0_NC, BFD_RELOC_AARCH64_MOVW_PREL_G1,
BFD_RELOC_AARCH64_MOVW_PREL_G1_NC, BFD_RELOC_AARCH64_MOVW_PREL_G2,
BFD_RELOC_AARCH64_MOVW_PREL_G2_NC, BFD_RELOC_AARCH64_MOVW_PREL_G3.
* bfd-in2.h: Regenerate.
* libbfd.h: Regenerate.
* elfnn-aarch64.c (elfNN_aarch64_howto_table): Add entries for
BFD_RELOC_AARCH64_MOVW_PREL_G0, BFD_RELOC_AARCH64_MOVW_PREL_G0_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G1, BFD_RELOC_AARCH64_MOVW_PREL_G1_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G2, BFD_RELOC_AARCH64_MOVW_PREL_G2_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G3.
gas/
2018-01-24 Renlin Li <renlin.li@arm.com>
* config/tc-aarch64.c (reloc_table): add entries for
BFD_RELOC_AARCH64_MOVW_PREL_G0, BFD_RELOC_AARCH64_MOVW_PREL_G0_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G1, BFD_RELOC_AARCH64_MOVW_PREL_G1_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G2, BFD_RELOC_AARCH64_MOVW_PREL_G2_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G3.
(process_movw_reloc_info): Supports newly added MOVW_PREL relocations.
(md_apply_fix): Likewise
* testsuite/gas/aarch64/prel_g0.s: New.
* testsuite/gas/aarch64/prel_g0.d: New.
* testsuite/gas/aarch64/prel_g0_nc.s: New.
* testsuite/gas/aarch64/prel_g0_nc.d: New.
* testsuite/gas/aarch64/prel_g1.s: New.
* testsuite/gas/aarch64/prel_g1.d: New.
* testsuite/gas/aarch64/prel_g1_nc.s: New.
* testsuite/gas/aarch64/prel_g1_nc.d: New.
* testsuite/gas/aarch64/prel_g2.s: New.
* testsuite/gas/aarch64/prel_g2.d: New.
* testsuite/gas/aarch64/prel_g2_nc.s: New.
* testsuite/gas/aarch64/prel_g2_nc.d: New.
* testsuite/gas/aarch64/prel_g3.s: New.
* testsuite/gas/aarch64/prel_g3.d: New.
GDB Administrator [Wed, 24 Jan 2018 00:00:19 +0000 (00:00 +0000)]
Automatic date update in version.in
Maciej W. Rozycki [Tue, 23 Jan 2018 21:18:24 +0000 (21:18 +0000)]
MIPS/GAS: Correct default ABI selection for `mips64*-ps2-elf*'
Correct an issue with the `mips64*-ps2-elf*' target introduced with
commit
e407c74b5b60 ("Support for MIPS R5900 (Sony Playstation 2)"),
<https://sourceware.org/ml/binutils/2012-12/msg00240.html> and make
the n32 ABI the default for GAS, consistently with how BFD and LD
are configured for this target.
gas/
* configure.ac: Also set `mips_default_abi' to N32_ABI for
`mips64*-ps2-elf*'.
* configure: Regenerate.
Maciej W. Rozycki [Tue, 23 Jan 2018 19:01:35 +0000 (19:01 +0000)]
MIPS/GAS: Remove a stale OPTION_COMPAT_ARCH_BASE option marker
Complement commit
23fce1e31156 ("MIPS16 intermix test failure"),
<https://sourceware.org/ml/binutils/2009-01/msg00335.html>, and
remove a stale option marker entry.
gas/
* config/tc-mips.c (options): Remove OPTION_COMPAT_ARCH_BASE
enum value.
Maciej W. Rozycki [Tue, 23 Jan 2018 19:01:34 +0000 (19:01 +0000)]
MIPS/BFD: Update a stale `mips_elf32_section_processing' reference
Update a stale reference to `mips_elf32_section_processing', following a
merge of the function into `_bfd_mips_elf_section_processing' made with
commit
103186c62b99 ("PATCH for MIPS 64-bit ABI suport"),
<https://sourceware.org/ml/binutils/1999-q3/msg00072.html>.
bfd/
* elfxx-mips.c (_bfd_mips_elf_final_link): Update a stale
`mips_elf32_section_processing' comment reference.
Igor Tsimbalist [Tue, 23 Jan 2018 16:56:30 +0000 (19:56 +0300)]
Enable Intel PCONFIG instruction.
Intel has disclosed a set of new instructions for Icelake processor.
The spec is
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
This patch enables Intel PCONFIG instruction.
gas/
* config/tc-i386.c (cpu_arch): Add .pconfig.
* doc/c-i386.texi: Document .pconfig.
* testsuite/gas/i386/i386.exp: Add PCONFIG tests.
* testsuite/gas/i386/pconfig-intel.d: New test.
* testsuite/gas/i386/pconfig.d: Likewise.
* testsuite/gas/i386/pconfig.s: Likewise.
* testsuite/gas/i386/x86-64-pconfig-intel.d: Likewise.
* testsuite/gas/i386/x86-64-pconfig.d: Likewise.
* testsuite/gas/i386/x86-64-pconfig.s: Likewise.
opcodes/
* i386-dis.c (enum): Add pconfig.
* i386-gen.c (cpu_flag_init): Add CPU_PCONFIG_FLAGS.
(cpu_flags): Add CpuPCONFIG.
* i386-opc.h (enum): Add CpuPCONFIG.
(i386_cpu_flags): Add cpupconfig.
* i386-opc.tbl: Add PCONFIG instruction.
* i386-init.h: Regenerate.
* i386-tbl.h: Likewise.
Igor Tsimbalist [Tue, 23 Jan 2018 16:39:05 +0000 (19:39 +0300)]
Enable Intel WBNOINVD instruction.
Intel has disclosed a set of new instructions for Icelake processor.
The spec is
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
This patch enables Intel WBNOINVD instruction.
gas/
* config/tc-i386.c (cpu_arch): Add .wbnoinvd.
* doc/c-i386.texi: Document .wbnoinvd.
* testsuite/gas/i386/i386.exp: Add WBNOINVD tests.
* testsuite/gas/i386/wbnoinvd-intel.d: New test.
* testsuite/gas/i386/wbnoinvd.d: Likewise.
* testsuite/gas/i386/wbnoinvd.s: Likewise.
* testsuite/gas/i386/x86-64-wbnoinvd-intel.d: Likewise.
* testsuite/gas/i386/x86-64-wbnoinvd.d: Likewise.
* testsuite/gas/i386/x86-64-wbnoinvd.s: Likewise.
opcodes/
* i386-dis.c (enum): Add PREFIX_0F09.
* i386-gen.c (cpu_flag_init): Add CPU_WBNOINVD_FLAGS.
(cpu_flags): Add CpuWBNOINVD.
* i386-opc.h (enum): Add CpuWBNOINVD.
(i386_cpu_flags): Add cpuwbnoinvd.
* i386-opc.tbl: Add WBNOINVD instruction.
* i386-init.h: Regenerate.
* i386-tbl.h: Likewise.
Maciej W. Rozycki [Tue, 23 Jan 2018 14:51:22 +0000 (14:51 +0000)]
MIPS/GAS: Correct `as --help' always reporting `o32' as the default ABI
Remove an issue with `as --help' always reporting `o32' as the default
ABI regardless of what the default actually is, originally caused by
commit
cac012d6d394 ("check mips abi x linker emulation compatibility"),
<https://sourceware.org/ml/binutils/2003-05/msg00187.html> missing an
update here.
gas/
* config/tc-mips.c (md_show_usage): Correctly indicate the
configuration-specific default ABI.
Maciej W. Rozycki [Tue, 23 Jan 2018 14:51:22 +0000 (14:51 +0000)]
MIPS/GAS: Add missing `-mmips16e2'/`-mno-mips16e2' help text
Correct a commit
25499ac7ee92 ("MIPS16e2: Add MIPS16e2 ASE support") GAS
bug and add missing help text for the `-mmips16e2' and `-mno-mips16e2'
options added with said commit.
gas/
* config/tc-mips.c (md_show_usage): Report `-mmips16e2' and
`-mno-mips16e2' options.
Philipp Rudo [Tue, 23 Jan 2018 12:37:44 +0000 (13:37 +0100)]
s390: Clean up s390-linux-tdep.c
After moving big parts of the code to the new s390-tdep.c file
s390-linux-tdep.c now contains many includes it doesn't need anymore.
Furthermore, there are some functions lacking a description.
Fix both and order the remaining includes alphabetically.
gdb/ChangeLog
* s390-linux-tdep.c: Remove unneeded includes and order them
alphabetically. Add comments to functions without description.
Philipp Rudo [Tue, 23 Jan 2018 12:37:44 +0000 (13:37 +0100)]
s390: Move record-replay to s390-tdep.c
Record-replay is independent of the OS. So it can be moved to the common
s390 code without problem.
gdb/ChangeLog:
* s390-linux-tdep.c (s390_record_address_mask)
(s390_record_calc_disp_common, s390_record_calc_disp)
(s390_record_calc_disp_vsce, s390_record_calc_rl, s390_popcnt)
(s390_record_gpr_g, s390_record_gpr_h, s390_record_vr)
(s390_process_record): Move to s390-tdep.c.
(s390_linux_init_abi_any): Adjust.
* s390-tdep.c (s390_record_address_mask)
(s390_record_calc_disp_common, s390_record_calc_disp)
(s390_record_calc_disp_vsce, s390_record_calc_rl, s390_popcnt)
(s390_record_gpr_g, s390_record_gpr_h, s390_record_vr)
(s390_process_record): Moved from s390-linux-tdep.c
(s390_gdbarch_init): Adjust.
Philipp Rudo [Tue, 23 Jan 2018 12:37:43 +0000 (13:37 +0100)]
s390: Split up s390-linux-tdep.c into two files
Currently all target dependent code for s390 is in one file,
s390-linux-tdep.c. This includes code general for the architecture as
well as code specific for uses in GNU/Linux (user space). Up until now
this was OK as GNU/Linux was the only supported OS. In preparation to
support the new Linux kernel 'OS' split up the existing s390 code into a
general s390-tdep and a GNU/Linux-specific s390-linux-tdep.
Note: The record-replay feature will be moved in a separate patch. This
is simply due to the fact that the combined patch would be too large for
the mailing list. This requires setting the process_record hook during
OSABI init to keep the code bisectable. The patch moving record-replay
cleans up this hack.
gdb/ChangeLog:
* s390-linux-nat.c (s390-tdep.h): New include.
* Makefile.in (ALL_TARGET_OBS): Add s390-tdep.o.
(HFILES_NO_SRCDIR): Add s390-tdep.h.
(ALLDEPFILES): Add s390-tdep.c.
* configure.tgt (s390*-*-linux*): Add s390-tdep.o.
* s390-linux-tdep.h (HWCAP_S390_*, S390_*_REGNUM): Move to...
* s390-tdep.h: ...this. New file.
* s390-linux-tdep.c (s390-tdep.h): New include.
(_initialize_s390_tdep): Rename to...
(_initialize_s390_linux_tdep): ...this and adjust.
(s390_abi_kind, s390_vector_abi_kind, gdbarch_tdep)
(enum named opcodes, S390_NUM_GPRS, S390_NUM_FPRS): Move to
s390-tdep.h.
(s390_break_insn, s390_breakpoint, s390_readinstruction, is_ri)
(is_ril, is_rr, is_rre, is_rs, is_rsy, is_rx, is_rxy)
(s390_is_partial_instruction, s390_software_single_step)
(is_non_branch_ril, s390_displaced_step_copy_insn)
(s390_displaced_step_fixup, s390_displaced_step_hw_singlestep)
(s390_prologue_data, s390_addr, s390_store, s390_load)
(s390_check_for_saved, s390_analyze_prologue, s390_skip_prologue)
(s390_register_call_saved, s390_guess_tracepoint_registers)
(s390_register_name, s390_dwarf_regmap, s390_dwarf_reg_to_regnum)
(regnum_is_gpr_full, regnum_is_vxr_full, s390_value_from_register)
(s390_pseudo_register_name, s390_pseudo_register_type)
(s390_pseudo_register_read, s390_pseudo_register_write)
(s390_pseudo_register_reggroup_p, s390_ax_pseudo_register_collect)
(s390_ax_pseudo_register_push_stack, s390_gen_return_address)
(s390_addr_bits_remove, s390_address_class_type_flags)
(s390_address_class_type_flags_to_name)
(s390_address_class_name_to_type_flags, s390_effective_inner_type)
(s390_function_arg_float, s390_function_arg_vector)
(is_power_of_two, s390_function_arg_integer, s390_arg_state)
(s390_handle_arg, s390_push_dummy_call, s390_dummy_id)
(s390_frame_align, s390_register_return_value, s390_return_value)
(s390_stack_frame_destroyed_p, s390_unwind_pc, s390_unwind_sp)
(s390_unwind_pseudo_register, s390_adjust_frame_regnum)
(s390_dwarf2_prev_register, s390_dwarf2_frame_init_reg)
(s390_trad_frame_prev_register, s390_unwind_cache)
(s390_prologue_frame_unwind_cache)
(s390_backchain_frame_unwind_cache, s390_frame_unwind_cache)
(s390_frame_this_id, s390_frame_prev_register, s390_frame_unwind)
(s390_stub_unwind_cache, s390_stub_frame_unwind_cache)
(s390_stub_frame_this_id, s390_stub_frame_prev_register)
(s390_stub_frame_sniffer, s390_stub_frame_unwind)
(s390_frame_base_address, s390_local_base_address)
(s390_frame_base, s390_gcc_target_options)
(s390_gnu_triplet_regexp, s390_stap_is_single_operand)
(s390_validate_reg_range, s390_tdesc_valid)
(s390_gdbarch_tdep_alloc, s390_gdbarch_init): Move to...
* s390-tdep.c: ...this. New file.
Philipp Rudo [Tue, 23 Jan 2018 12:37:43 +0000 (13:37 +0100)]
s390: gdbarch_tdep add hook for syscall record
Most parts of s390_process_record are common for the architecture. Only
the system call handling differs between the OSes. In order to be able to
move s390_process_record to a common code file add a hook to record
syscalls to gdbarch_tdep. So every OS can implement their own handling.
gdb/ChangeLog:
* s390-linux-tdep.c (gdbarch_tdep.s390_syscall_record): New hook.
(s390_process_record, s390_gdbarch_tdep_alloc)
(s390_linux_init_abi_any): Use/set new hook.
Philipp Rudo [Tue, 23 Jan 2018 12:37:43 +0000 (13:37 +0100)]
s390: Hook s390 into OSABI mechanism
Do what the title says and distinguish between 31- and 64-bit systems.
The goal is to init the OSABI as late as possible in gdbarch_init so the
OSABI has the chance to overwrite the defaults.
There are two pitfalls to be aware of:
First, the dwarf2 unwinder must be appended before the OSABI is
initialized. Otherwise the OS could add a default unwinder which always
takes control before the dwarf unwinder even gets a chance.
Second, tdesc_use_registers has to be handled with extra care. It sets
several gdbarch hooks, especially gdbarch_register_name, which has to be
overwritten again after the call. Furthermore it deletes the tdesc_data
without checking. Therefore there must not be a call to
tdesc_data_cleanup afterwards or GDB will crash with a double free.
gdb/ChangeLog:
* s390-linux-tdep.c (osabi.h): New include.
(s390_linux_init_abi_31, s390_linux_init_abi_64)
(s390_linux_init_abi_any): New functions.
(s390_gdbarch_init, _initialize_s390_tdep): Adjust.
Philipp Rudo [Tue, 23 Jan 2018 12:37:43 +0000 (13:37 +0100)]
s390: if -> gdb_assert for tdesc_has_registers check
Before doing the tdesc validation there is a check whether the tdesc has
registers or not. This check is not only unnecessary but wrong.
First the check is done after a default tdesc is assigned if the original
tdesc has no registers. These default tdescs always have registers so the
check alway returns true.
Second if the default tdesc would not have registers the check only skips
the tdesc validation instead of returning an error. This would trigger a
gdb_assert later on in tdesc_use_registers.
gdb/ChangeLog:
* s390-linux-tdep.c (s390_gdbarch_init): Use gdb_assert for
tdesc_has_registers check
Philipp Rudo [Tue, 23 Jan 2018 12:37:42 +0000 (13:37 +0100)]
s390: Move tdesc validation to separate function
Simplify s390_gdbarch_init by moving the target description validation to
a separate function.
gdb/ChangeLog:
* s390-linux-tdep.c (s390_tdesc_valid): New function.
(s390_validate_reg_range): New macro.
(s390_gdbarch_init): Adjust.
Philipp Rudo [Tue, 23 Jan 2018 12:37:42 +0000 (13:37 +0100)]
s390: gdbarch_tdep add field tdesc
Add a field for the target description to gdbarch_tdep. This will later be
needed to pass the 'correct' target description from osabi_init to
gdbarch_init. Unfortunately this cannot be done using gdbarch_info as it
is only passed by copy, not reference.
gdb/ChangeLog:
* s390-linux-tdep.c (gdbarch_tdep) <tdesc>: New field.
(s390_gdbarch_tdep_alloc): Adjust.
(s390_gdbarch_init): Adjust.
Philipp Rudo [Tue, 23 Jan 2018 12:37:42 +0000 (13:37 +0100)]
s390: gdbarch_tdep.have_* int -> bool
Currently the gdbarch_tdep.have_* flags are a mix of int and bool. Clean
this up by making them all bool.
gdb/ChangeLog:
* s390-linux-tdep.c (gdbarch_tdep) <have_linux_v1, have_linux_v2>
<have_tdb>: Change type to bool.
(s390_gdbarch_tdep_alloc): Adjust.
(s390_gdbarch_init): Adjust.
Philipp Rudo [Tue, 23 Jan 2018 12:37:41 +0000 (13:37 +0100)]
s390: Allocate gdbarch & tdep at start of gdbarch_init
Moving the allocation of gdbarch_tdep to the start of s390_gdbarch_init
allows us to use its fields for tracking the different features instead of
using separate variables. To make the code a little nicer move the actual
allocation and initialization to a separate function. Also move the
allocation of gdbarch to keep the two together.
gdb/ChangeLog:
* s390-linux-tdep (s390_abi_kind) <ABI_NONE>: New default field.
(gdbarch_tdep) <have_upper, have_vx>: New fields.
(s390_gdbarch_tdep_alloc): New function.
(s390_gdbarch_init): Allocate tdep at start and use its fields
instead of separate variables.
Philipp Rudo [Tue, 23 Jan 2018 12:37:41 +0000 (13:37 +0100)]
s390: Remove duplicate checks for cached gdbarch at init
When initializing the gdbarch there is a check whether an appropriate
gdbarch already exists in the gdbarch_list. Failing of some of the checks
would lead to a different target description. However
gdbarch_list_lookup_by_info already checks for
if (info->target_desc != arches->gdbarch->target_desc)
continue;
Remove these duplicate checks.
gdb/ChangeLog:
* s390-linux-tdep.c (s390_gdbarch_init): Remove duplicate checks
when looking for cached gdbarch and add comment for remaining.
GDB Administrator [Tue, 23 Jan 2018 00:00:22 +0000 (00:00 +0000)]
Automatic date update in version.in
Maciej W. Rozycki [Mon, 22 Jan 2018 21:06:35 +0000 (13:06 -0800)]
GAS/doc: Correct `.set nomips16e2' directive description syntax
gas/
* doc/c-mips.texi (MIPS ASE Instruction Generation Overrides):
Correct syntax of the `.set nomips16e2' directive description.
Maciej W. Rozycki [Mon, 22 Jan 2018 21:05:56 +0000 (13:05 -0800)]
binutils/doc: Fix a "using" typo in `objcopy --rename-section' description
binutils/
* doc/binutils.texi (objcopy): Fix a typo in `--rename-section'
option description.
Pedro Alves [Mon, 22 Jan 2018 17:33:13 +0000 (17:33 +0000)]
Fix segfault with 'set print object on' + 'whatis <struct>' & co
Compiling GDB with a recent GCC exposes a problem:
../../gdb/typeprint.c: In function 'void whatis_exp(const char*, int)':
../../gdb/typeprint.c:515:12: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized]
real_type = value_rtti_type (val, &full, &top, &using_enc);
~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The warning is correct. There are indeed code paths that use
uninitialized 'val', leading to crashes. Inside the
value_rtti_indirect_type/value_rtti_type calls here in whatis_exp:
if (opts.objectprint)
{
if (((TYPE_CODE (type) == TYPE_CODE_PTR) || TYPE_IS_REFERENCE (type))
&& (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_STRUCT))
real_type = value_rtti_indirect_type (val, &full, &top, &using_enc);
else if (TYPE_CODE (type) == TYPE_CODE_STRUCT)
real_type = value_rtti_type (val, &full, &top, &using_enc);
}
We reach those calls above with "set print object on", and then with
any of:
(gdb) whatis struct some_structure_type
(gdb) whatis struct some_structure_type *
(gdb) whatis struct some_structure_type &
because "whatis" with a type argument enters this branch:
/* The behavior of "whatis" depends on whether the user
expression names a type directly, or a language expression
(including variable names). If the former, then "whatis"
strips one level of typedefs, only. If an expression,
"whatis" prints the type of the expression without stripping
any typedef level. "ptype" always strips all levels of
typedefs. */
if (show == -1 && expr->elts[0].opcode == OP_TYPE)
{
which does not initialize VAL. Trying the above triggers crashes like
this:
(gdb) set print object on
(gdb) whatis some_structure_type
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x00000000005dda90 in check_typedef (type=0x6120736573756170) at src/gdb/gdbtypes.c:2388
2388 int instance_flags = TYPE_INSTANCE_FLAGS (type);
...
This is a regression caused by a recent-ish refactoring of the code on
'whatis_exp', introduced by:
commit
c973d0aa4a2c737ab527ae44a617f1c357e07364
Date: Mon Aug 21 11:34:32 2017 +0100
Fix type casts losing typedefs and reimplement "whatis" typedef stripping
Fix this by setting VAL to NULL in the "whatis TYPE" case, and
skipping fetching the dynamic type if there's no value to fetch it
from.
New tests included.
gdb/ChangeLog:
2018-01-22 Pedro Alves <palves@redhat.com>
Sergio Durigan Junior <sergiodj@redhat.com>
* typeprint.c (whatis_exp): Initialize "val" in the "whatis type"
case.
gdb/testsuite/ChangeLog:
2018-01-22 Pedro Alves <palves@redhat.com>
Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/whatis.exp: Add tests for 'set print object on' +
'whatis <struct>' 'whatis <struct> *' and 'whatis <struct> &'.
Maciej W. Rozycki [Mon, 22 Jan 2018 15:38:09 +0000 (07:38 -0800)]
MAINTAINERS: Update my company e-mail address
Following my recent transition from Imagination Technologies to the
reincarnated MIPS company update MAINTAINERS entries accordingly.
binutils/
* MAINTAINERS: Update my company e-mail address.
gdb/
* MAINTAINERS: Update my company e-mail address.
sim/
* MAINTAINERS: Update my company e-mail address.
Oleg Endo [Mon, 22 Jan 2018 14:31:10 +0000 (14:31 +0000)]
Fix the RX assembler so that it can handle escaped double quote characters, ie: \"
PR 22737
* config/tc-rx.c (rx_start_line): Handle escaped double-quote character.
* testsuite/gas/rx/pr22737.s: New test.
* testsuite/gas/rx/pr22737.d: Likewise.
* testsuite/gas/rx/rx.exp: Run the new test.
Nick Clifton [Mon, 22 Jan 2018 13:48:15 +0000 (13:48 +0000)]
Update Swedish translation for the binutils sub-directory
Yao Qi [Mon, 22 Jan 2018 11:02:49 +0000 (11:02 +0000)]
regcache::cooked_write test
Since my following patches will change how each gdbarch read and write
pseudo registers, it's better to write a unit test to
regcache::cooked_write, to make sure my following changes don't cause
any regressions. See the comments on cooked_write_test.
gdb:
2018-01-22 Yao Qi <yao.qi@linaro.org>
* regcache.c (cooked_write_test): New function.
(_initialize_regcache): Register the test.
Yao Qi [Mon, 22 Jan 2018 11:02:49 +0000 (11:02 +0000)]
regcache_cooked_read -> regcache->cooked_read
Similarly, this patch replaces regcache_cooked_read with
regcache->cooked_read.
gdb:
2018-01-22 Yao Qi <yao.qi@linaro.org>
* ia64-tdep.c (ia64_pseudo_register_read): Call
regcache->cooked_read instead of regcache_cooked_read_unsigned.
* m32c-tdep.c (m32c_cat_read): Likewise.
(m32c_r3r2r1r0_read): Likewise.
* m68hc11-tdep.c (m68hc11_pseudo_register_read): Likewise.
* xtensa-tdep.c (xtensa_register_read_masked): Likewise.
Yao Qi [Mon, 22 Jan 2018 11:02:49 +0000 (11:02 +0000)]
Replace regcache_raw_read with regcache->raw_read
The patch later in this series will move regcache's raw_read and
cooked_read methods to a new class regcache_read, and regcache is
dervied from it. Also pass regcache_read instead of regcache to gdbarch
methods pseudo_register_read and pseudo_register_read_value. In order
to prepare for this change, this patch changes regcache_raw_read to
regcache->raw_read. On the other hand, since we are in C++, I prefer
using class method (regcache->raw_read).
gdb:
2018-01-22 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (aarch64_pseudo_read_value): Call regcache
method raw_read instead of regcache_raw_read.
* amd64-tdep.c (amd64_pseudo_register_read_value): Likewise.
* arm-tdep.c (arm_neon_quad_read): Likewise.
* avr-tdep.c (avr_pseudo_register_read): Likewise.
* bfin-tdep.c (bfin_pseudo_register_read): Likewise.
* frv-tdep.c (frv_pseudo_register_read): Likewise.
* h8300-tdep.c (h8300_pseudo_register_read): Likewise.
* i386-tdep.c (i386_mmx_regnum_to_fp_regnum): Likewise.
(i386_pseudo_register_read_into_value): Likewise.
* mep-tdep.c (mep_pseudo_cr32_read): Likewise.
* msp430-tdep.c (msp430_pseudo_register_read): Likewise.
* nds32-tdep.c (nds32_pseudo_register_read): Likewise.
* rl78-tdep.c (rl78_pseudo_register_read): Likewise.
* s390-linux-tdep.c (s390_pseudo_register_read): Likewise.
* sparc-tdep.c (sparc32_pseudo_register_read): Likewise.
* sparc64-tdep.c (sparc64_pseudo_register_read): Likewise.
* spu-tdep.c (spu_pseudo_register_read_spu): Likewise.
* xtensa-tdep.c (xtensa_pseudo_register_read): Likewise.
Yao Qi [Mon, 22 Jan 2018 11:02:49 +0000 (11:02 +0000)]
Remove mt port
This patch removes the MT port. The removal was annoucned
https://sourceware.org/ml/gdb-announce/2017/msg00006.html
I'll remove MT from the top-level configure later.
gdb:
2018-01-22 Yao Qi <yao.qi@linaro.org>
* Makefile.in (ALL_TARGET_OBS): Remove mt-tdep.o.
* configure.tgt: Remove target mt.
* mt-tdep.c: Remove.
* regcache.c (cooked_read_test): Remove the check for mt.
Yao Qi [Mon, 22 Jan 2018 11:02:48 +0000 (11:02 +0000)]
Don't call gdbarch_pseudo_register_read_value in jit.c
gdbarch_pseudo_register_read_value is not implemented in every gdbarch, so
the predicate gdbarch_pseudo_register_read_value_p is needed before
calling it. However, there is no such guard in jit_frame_prev_register, I
am wondering how does jit work on the arch without having gdbarch method
pseudo_register_read_value.
The proper way to get register value is to call cooked_read, and then
create the value object from the buffer.
gdb:
2018-01-22 Yao Qi <yao.qi@linaro.org>
* jit.c (jit_frame_prev_register): Call regcache::cooked_read
instead of gdbarch_pseudo_register_read_value.
Joel Brobecker [Mon, 22 Jan 2018 04:23:34 +0000 (23:23 -0500)]
Ada/DWARF: Assume the Ada compiler produces descriptive type attributes
GCC was enhanced in 2011 to generate this attribute, so I think we can
now assume that it is available when using that compiler. Doing so
allows us to speed up what we call "parallel type" lookups when
processing certain types encoded using the GNAT encoding.
This patch changes need_gnat_info to always expect those attributes
to be generated when the language is Ada. This is an assumption
that on the surfcace looks like it might be a bit on the edge; but
in practice, it should be OK because this is only useful in the
context of handling GNAT-specific encodings. Other Ada compilers
would presumably produce debugging information using pure DWARF
constructs, so would not be impacted by this.
gdb/ChangeLog:
* dwarf2read.c (need_gnat_info): Return nonzero if the cu's
language is Ada.
Tested on x86_64-linux.
Joel Brobecker [Mon, 22 Jan 2018 04:14:50 +0000 (23:14 -0500)]
wrong line number in breakpoint location
Consider the following situation, where we have one file containing...
$ cat -n body.inc
1 i = i + 1;
... we include that file from some code, like so:
$ cat -n cat -n small.c
[...]
17 int
18 next (int i)
19 {
20 #include "body.inc"
21 return i;
22 }
When trying to insert a breakpoint on line 18, for instance:
(gdb) b small.c:18
Breakpoint 1 at 0x40049f: file body.inc, line 18.
^^
||
Here, the issue is that GDB reports the breakpoint to be in file
body.inc, which is true, but with the line number that corresponding
to the user-requested location, which is not correct.
Although the simple reproducer may look slightly artificial,
the above is simply one way to reproduce the same issue observed
when trying to insert a breakpoint on a function provided in
a .h files and then subsequently inlined in a C file.
What happens is the following:
1. We resolve the small.c:18 linespec into a symtab_and_line which
has "small.c" and 18 as the symtab and line number.
2. Next, we call skip_prologue_sal, which calculates the PC
past the prologue, and updates the symtab_and_line: PC,
but also symtab (now body.inc) and the new line (now 1).
3. However, right after that, we do:
/* Make sure the line matches the request, not what was
found. */
intermediate_results.sals[i].line = val.line;
We should either restore both symtab and line, or leave the actual
line to match the actual symtab. This patch chose the latter.
This introduces a few changes in a few tests, which required some
updates, but looking at those change, I believe them to be expected.
gdb/ChangeLog:
* linespec.c (create_sals_line_offset): Remove code that preserved
the symtab_and_line's line number.
gdb/testsuite/ChangeLog:
* gdb.base/break-include.c, gdb.base/break-include.inc,
gdb.base/break-include.exp: New files.
* gdb.base/ending-run.exp: Minor adaptations due to the breakpoint's
line number now being the actual line number where the breakpoint
was inserted.
* gdb.mi/mi-break.exp: Likewise.
* gdb.mi/mi-reverse.exp: Likewise.
* gdb.mi/mi-simplerun.exp: Ditto.
Tested on x86_64-linux.
GDB Administrator [Mon, 22 Jan 2018 00:00:29 +0000 (00:00 +0000)]
Automatic date update in version.in
Andrew Burgess [Thu, 19 Oct 2017 10:27:48 +0000 (11:27 +0100)]
gdb: Don't store a thread-id for floating varobj
When creating a varobj with -var-create a user can create either fixed
varobj, or floating varobj.
A fixed varobj will always be evaluated within the thread/frame/block in
which the varobj was created, if that thread/frame/block is no longer
available then the varobj is considered out of scope.
A floating varobj will always be evaluated within the current
thread/frame/block.
Despite never using them GDB was storing the thread/frame/block into a
floating varobj, and the thread-id would then be displayed when GDB
reported on the state of the varobj, this could confuse a user into
thinking that the thread-id was relevant.
This commit prevents GDB storing the thread/frame/block onto floating
varobj, and updates the few tests where this impacts the results.
gdb/ChangeLog:
* varobj.c (varobj_create): Don't set valid_block when creating a
floating varobj.
gdb/testsuite/ChangeLog:
* gdb.python/py-mi.exp: Don't expect a thread-id for floating
varobj.
* gdb.mi/mi-var-create-rtti.exp: Likewise.
Andrew Burgess [Thu, 19 Oct 2017 09:59:22 +0000 (10:59 +0100)]
gdb: Remove out of date comment
Comment clean up.
gdb/ChangeLog:
* varobj.c (varobj_create): Remove out of date comment.
Andrew Burgess [Wed, 18 Oct 2017 19:07:19 +0000 (20:07 +0100)]
gdb: PR mi/20395: Fix -var-update for registers in frames 1 and up
This patch fixes a problem with using the MI -var-update command
to access the values of registers in frames other than the current
frame. The patch includes a test that demonstrates the problem:
* run so there are several frames on the stack
* create a fixed varobj for $pc in each frame, #'s 1 and above
* step one instruction, to modify the value of $pc
* call -var-update for each of the previously created varobjs
to verify that they are not reported as having changed.
Without the patch, the -var-update command reported that $pc for all
frames 1 and above had changed to the value of $pc in frame 0.
A varobj is created as either fixed, the expression is evaluated within
the context of a specific frame, or floating, the expression is
evaluated within the current frame, whatever that may be.
When a varobj is created by -var-create we set two fields of the varobj
to track the context in which the varobj was created, these two fields
are varobj->root->frame and var->root->valid_block.
If a varobj is of type fixed, then, when we subsequently try to
reevaluate the expression associated with the varobj we must determine
if the original frame (and block) is still available, if it is not then
the varobj can no longer be evaluated.
The problem is that for register expressions varobj->root->valid_block
is not set correctly. This block tracking is done using the global
'innermost_block' which is set in the various parser files (for example
c-exp.y). However, this is not set for register expressions.
The fix then seems like it should be to just update the innermost block
when parsing register expressions, however, that solution causes several
test regressions.
The problem is that in some cases we rely on the expression parsing
code not updating the innermost block for registers, one example is
when we parse the expression for a 'display' command. The display
commands treats registers like floating varobjs, but symbols are
treated like fixed varobjs. So 'display $reg_name' will always show
the value of '$reg_name' even as the user moves from frame to frame,
while 'display my_variable' will only show 'my_variable' while it is
in the current frame and/or block, when the user moves to a new frame
and/or block (even one with a different 'my_variable' in) then the
display of 'my_variable' stops. For the case of 'display', without
the option to force fixed or floating expressions, the current
behaviour is probably the best choice. For the varobj system though,
we can choose between floating and fixed, and we should try to make
this work for registers.
There's only one existing test case that needs to be updated, in that
test a fixed varobj is created using a register, the MI output now
include the thread-id in which the varobj should be evaluated, which I
believe is correct behaviour. I also added a new floating test case
into the same test script, however, right now this also includes the
thread-id in the expected output, which I believe is an existing gdb
bug, which I plan to fix next.
Tested on x86_64 Linux native and native-gdbserver, no regressions.
gdb/ChangeLog:
PR mi/20395
* ada-exp.y (write_var_from_sym): Pass extra parameter when
updating innermost block.
* parse.c (innermost_block_tracker::update): Take extra type
parameter, and check types match before updating innermost block.
(write_dollar_variable): Update innermost block for registers.
* parser-defs.h (enum innermost_block_tracker_type): New enum.
(innermost_block_tracker::innermost_block_tracker): Initialise
m_types member.
(innermost_block_tracker::reset): Take type parameter.
(innermost_block_tracker::update): Take type parameter, and pass
type through as needed.
(innermost_block_tracker::m_types): New member.
* varobj.c (varobj_create): Pass type when reseting innermost
block.
gdb/testsuite/ChangeLog:
* gdb.mi/basics.c: Add new global.
* gdb.mi/mi-frame-regs.exp: New file.
* gdb.mi/mi-var-create-rtti.exp: Update expected results, add new
case.
Andrew Burgess [Wed, 18 Oct 2017 18:53:21 +0000 (19:53 +0100)]
gdb: New API for tracking innermost block
This commit is preparation for a later change, at this point there
should be no user visible change.
We currently maintain a global innermost_block which tracks the most
inner block encountered when parsing an expression.
This commit wraps the innermost_block into a new class, and switches all
direct accesses to the variable to use the class API.
gdb/ChangeLog:
* ada-exp.y (write_var_from_sym): Switch to innermost_block API.
* ada-lang.c (resolve_subexp): Likewise.
* breakpoint.c (set_breakpoint_condition) Likewise.
(watch_command_1) Likewise.
* c-exp.y (variable): Likewise.
* d-exp.y (PrimaryExpression): Likewise.
* f-exp.y (variable): Likewise.
* go-exp.y (variable): Likewise.
* m2-exp.y (variable): Likewise.
* objfiles.c (objfile::~objfile): Likewise.
* p-exp.y (variable): Likewise.
* parse.c (innermost_block): Change type.
* parser-defs.h (class innermost_block_tracker): New.
(innermost_block): Change to innermost_block_tracker.
* printcmd.c (display_command): Switch to innermost_block API.
(do_one_display): Likewise.
* rust-exp.y (do_one_display): Likewise.
* symfile.c (clear_symtab_users): Likewise.
* varobj.c (varobj_create): Switch to innermost_block API, replace
use of innermost_block with block stored on varobj object.
Andrew Burgess [Wed, 18 Oct 2017 18:04:17 +0000 (19:04 +0100)]
gdb: Remove duplicate declaration of global innermost_block
The global 'innermost_block' is declared in two header files. Remove
one of the declarations, and add an include of the other header into
the one source file that could no longer see a declaration of
'innermost_block'.
gdb/ChangeLog:
* expression.h (innermost_block): Remove declaration.
* varobj.c: Add 'parser-defs.h' include.
Andrew Burgess [Sat, 20 Jan 2018 23:56:37 +0000 (23:56 +0000)]
gdb: Add test for some error cases of @entry usage
Adds a test that using @entry for a non-parameter, or for an unknown
symbol, both give the expected error. This error message was
previously untested.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-entry-value.exp: Test using @entry on a
non-parameter, and on an unknown symbol.
GDB Administrator [Sun, 21 Jan 2018 00:00:35 +0000 (00:00 +0000)]
Automatic date update in version.in
H.J. Lu [Sat, 20 Jan 2018 22:25:24 +0000 (14:25 -0800)]
x86: Check the versioned __tls_get_addr symbol
We need to check the versioned __tls_get_addr symbol when looking up
"__tls_get_addr".
bfd/
PR ld/22721
* elfxx-x86.c (_bfd_x86_elf_link_check_relocs): Check the
versioned __tls_get_addr symbol.
ld/
PR ld/22721
* testsuite/ld-plugin/lto.exp: Run PR ld/22721 tests.
* testsuite/ld-plugin/pr22721.t: New file.
* testsuite/ld-plugin/pr22721a.s: Likewise.
* testsuite/ld-plugin/pr22721b.c: Likewise.
GDB Administrator [Sat, 20 Jan 2018 00:00:22 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom Tromey [Fri, 19 Jan 2018 22:25:19 +0000 (15:25 -0700)]
Fix qualified name lookup for Rust
In https://github.com/rust-lang/rust/pull/46457, "m4b" pointed out
that the Rust support in gdb doesn't properly handle the lookup of
qualified names.
In particular, as shown in the test case in this patch, something like
"::NAME" should be found in the global scope, but is not.
This turns out to happen because rust_lookup_symbol_nonlocal does not
search the global scope unless the name in question is unqualified.
However, lookup_symbol_aux does not search the global scope, and
appears to search the static scope only as a fallback (I wonder if
this is needed?).
This patch fixes the problem by changing rust_lookup_symbol_nonlocal
to search the static and global blocks in more cases.
Regression tested against various versions of the rust compiler on
Fedora 26 x86-64. (Note that there are unrelated failures with newer
versions of rustc; I will be addressing those separately.)
2018-01-19 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_lookup_symbol_nonlocal): Look up qualified
symbols in the static and global blocks.
2018-01-19 Tom Tromey <tom@tromey.com>
* gdb.rust/modules.rs (TWENTY_THREE): New global.
* gdb.rust/modules.exp: Add ::-qualified lookup test.
Andreas Arnez [Fri, 19 Jan 2018 18:59:53 +0000 (19:59 +0100)]
S390: Fix infcalls in s390-vregs test case
GDB used to assume that functions without debug info return int. It
accepted an expression containing such a function call and silently
interpreted the function's return value as int. But nowadays GDB yields
an error message instead, see
https://sourceware.org/ml/gdb-patches/2017-07/msg00139.html
This affects the s390-vregs test case, because it contains calls to
setrlimit64 and chdir. When no glibc debug info is installed, these lead
to unnecessary FAILs. Fix this by adding appropriate casts to the
inferior function calls.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-vregs.exp: Explicitly cast the return values of
setrlimit and chdir to int.
James Clarke [Fri, 19 Jan 2018 17:22:50 +0000 (17:22 +0000)]
gdb: Add missing #ifdef USE_THREAD_DB to gdbserver
Otherwise, linking fails with:
[...]/linux-low.c:664: undefined reference to `thread_db_notice_clone(thread_info*, ptid_t)'
gdb/gdbserver/ChangeLog:
* linux-low.c (handle_extended_wait): Surround call to
thread_db_notice_clone with #ifdef USE_THREAD_DB.
James Clarke [Fri, 19 Jan 2018 17:22:49 +0000 (17:22 +0000)]
gdb: Fix ia64 defining TRAP_HWBKPT before including gdb_wait.h
On ia64, gdb_wait.h eventually includes siginfo-consts-arch.h, which
contains an enum with TRAP_HWBKPT, along with a #define. Thus we cannot
define TRAP_HWBKPT to 4 beforehand, and so gdb_wait.h must be included
earlier; include it from linux-ptrace.h so it can never come afterwards.
gdb/ChangeLog:
* nat/linux-ptrace.c: Remove unnecessary reinclusion of
gdb_ptrace.h, and move including gdb_wait.h ...
* nat/linux-ptrace.h: ... to here.
Simon Marchi [Fri, 19 Jan 2018 16:48:11 +0000 (11:48 -0500)]
Make linux_nat_detach/thread_db_detach use the inferior parameter
This patch makes these two functions actually use the inferior parameter
added by the previous patch, instead of reading inferior_ptid. I chose
these two, because they are the one actually used when I detach on my
GNU/Linux system, so they were easy to test.
I took the opportunity to pass the inferior being detached to
inf_ptrace_detach_success, so it could use it too. From there, it made
sense to add an overload of detach_inferior that takes the inferior
directly rather than the pid, to avoid having to pass inf->pid only for
the callee to look up the inferior structure by pid.
gdb/ChangeLog:
* inf-ptrace.c (inf_ptrace_detach): Adjust call to
inf_ptrace_detach_success.
(inf_ptrace_detach_success): Add inferior parameter, use it
instead of inferior_ptid, pass it to detach_inferior.
* inf-ptrace.h (inf_ptrace_detach_success): Add inferior
parameter.
* inferior.c (detach_inferior): Add overload that takes an
inferior object.
* inferior.h (detach_inferior): Likewise.
* linux-nat.c (linux_nat_detach): Use the inf parameter, don't
use inferior_ptid, adjust call to inf_ptrace_detach_success.
* linux-thread-db.c (thread_db_detach): Use inf parameter.
Simon Marchi [Fri, 19 Jan 2018 16:47:57 +0000 (11:47 -0500)]
Pass inferior down to target_detach and to_detach
The to_detach target_ops method implementations are currently expected
to work on current_inferior/inferior_ptid. In order to make things more
explicit, and remove some "shadow" parameter passing through globals,
this patch adds an "inferior" parameter to to_detach. Implementations
will be expected to use this instead of relying on the global. However,
to keep things simple, this patch only does the minimum that is
necessary to add the parameter. The following patch gives an example of
how one such implementation would be adapted. If the approach is deemed
good, we can then look into adapting more implementations. Until then,
they'll continue to work as they do currently.
gdb/ChangeLog:
* target.h (struct target_ops) <to_detach>: Add inferior
parameter.
(target_detach): Likewise.
* target.c (dispose_inferior): Pass inferior down.
(target_detach): Pass inferior down. Assert that it is equal to
the current inferior.
* aix-thread.c (aix_thread_detach): Pass inferior down.
* corefile.c (core_file_command): Pass current_inferior() down.
* corelow.c (core_detach): Add inferior parameter.
* darwin-nat.c (darwin_detach): Likewise.
* gnu-nat.c (gnu_detach): Likewise.
* inf-ptrace.c (inf_ptrace_detach): Likewise.
* infcmd.c (detach_command): Pass current_inferior() down to
target_detach.
* infrun.c (follow_fork_inferior): Pass parent_inf to
target_detach.
(handle_vfork_child_exec_or_exit): Pass inf->vfork_parent to
target_detach.
* linux-nat.c (linux_nat_detach): Add inferior parameter.
* linux-thread-db.c (thread_db_detach): Likewise.
* nto-procfs.c (procfs_detach): Likewise.
* procfs.c (procfs_detach): Likewise.
* record.c (record_detach): Likewise.
* record.h (struct inferior): Forward-declare.
(record_detach): Add inferior parameter.
* remote-sim.c (gdbsim_detach): Likewise.
* remote.c (remote_detach_1): Likewise.
(remote_detach): Likewise.
(extended_remote_detach): Likewise.
* sol-thread.c (sol_thread_detach): Likewise.
* target-debug.h (target_debug_print_inferior_p): New macro.
* target-delegates.c: Re-generate.
* top.c (kill_or_detach): Pass inferior down to target_detach.
* windows-nat.c (windows_detach): Add inferior parameter.
Simon Marchi [Fri, 19 Jan 2018 16:47:24 +0000 (11:47 -0500)]
Remove args from target detach
I was looking into adding a parameter to target_detach, and was
wondering what the args parameter was. It seems like in the distant
past, it was possible to specify a signal number when detaching. That
signal was injected in the process before it was detached. There is an
example of code handling this in linux_nat_detach. With today's GDB, I
can't get this to work. Doing "detach 15" (15 == SIGTERM) doesn't work,
because detach is a prefix command and doesn't recognize the sub-command
15. Doing "detach inferiors 15" doesn't work because it expects a list
of inferior id to detach. Therefore, I don't think there's a way of
invoking detach_command with a non-NULL args. I also didn't find any
documentation related to this feature.
I assume that this feature stopped working when detach was made a prefix
command, which is in
f73adfeb8bae36885e6ea248d12223ab0d5eb9cb (sorry,
there's no commit title) from 2006. Given that this feature was broken
for such a long time and we haven't heard anything (AFAIK, I did not
find any related bug), I think it's safe to remove it, as well as the
args parameter to target_detach. If someone wants to re-introduce it, I
would suggest rethinking the user interface, and in particular would
suggest using signal name instead of numbers.
I tried to fix all the impacted code, but I might have forgotten some
spots. It shouldn't be hard to fix if that's the case. I also couldn't
build-test everything I changed, especially the nto and solaris stuff.
gdb/ChangeLog:
* target.h (struct target_ops) <to_detach>: Remove args
parameter.
(target_detach): Likewise.
* target.c (dispose_inferior): Adjust.
(target_detach): Remove args parameter, adjust.
* aix-thread.c (aix_thread_detach): Adjust.
* corefile.c (core_file_command): Adjust.
* corelow.c (core_detach): Adjust.
* darwin-nat.c (darwin_detach): Adjust.
* gnu-nat.c (gnu_detach): Adjust.
* inf-ptrace.c (inf_ptrace_detach): Adjust.
* infcmd.c (detach_command): Adjust
* infrun.c (follow_fork_inferior): Adjust.
(handle_vfork_child_exec_or_exit): Adjust.
* linux-fork.c (linux_fork_detach): Remove args parameter.
* linux-fork.h (linux_fork_detach): Likewise.
* linux-nat.c (linux_nat_detach): Likewise, and adjust.
* linux-thread-db.c (thread_db_detach): Likewise.
* nto-procfs.c (procfs_detach): Likewise.
* procfs.c (procfs_detach): Likewise.
(do_detach): Remove signo parameter.
* record.c (record_detach): Remove args parameter.
* record.h (record_detach): Likewise.
* remote-sim.c (gdbsim_detach): Likewise.
* remote.c (remote_detach_1): Likewise.
(remote_detach): Likewise.
(extended_remote_detach): Likewise.
* sol-thread.c (sol_thread_detach): Likewise.
* target-delegates.c: Re-generate.
* top.c (struct qt_args) <args>: Remove field.
(kill_or_detach): Don't pass args.
(quit_force): Don't set args.
* windows-nat.c (windows_detach): Remove args parameter.
Thomas Preud'homme [Fri, 19 Jan 2018 14:17:24 +0000 (14:17 +0000)]
[gas/ARM] Remove spurious comments
Remove spurious comments after the definition of ToC and ToU.
2018-01-19 Thomas Preud'homme <thomas.preudhomme@arm.com>
gas/
* config/tc-arm.c (ToC macro): Remove spurious comment.
(ToU macro): Likewise.
Andreas Arnez [Fri, 19 Jan 2018 13:14:07 +0000 (14:14 +0100)]
S390: Improve comments for s390-tdbregs test case
This adds more explanation as to why the test case must be compiled with
the -msoft-float option. It also documents the my_tbegin and my_tend
functions.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-tdbregs.c (my_tbegin): Add comment documenting the
function.
(my_tend): Likewise.
* gdb.arch/s390-tdbregs.exp: Enhance comment; explain the
rationale of avoiding FP- and vector instructions.
Nick Clifton [Fri, 19 Jan 2018 10:50:06 +0000 (10:50 +0000)]
Update French translation in bfd sub-directory
Yao Qi [Fri, 19 Jan 2018 09:16:45 +0000 (09:16 +0000)]
Don't pass -m32 to libcc1 on arm-linux
When I run gdb.compile/ tests on arm-linux, I get the following fails,
(gdb) compile code -- ;^M
arm-none-linux-gnueabihf-gcc: error: unrecognized command line option '-m32'; did you mean '-mbe32'?^M
Compilation failed.^M
(gdb) compile code (void) param^M
arm-none-linux-gnueabihf-gcc: error: unrecognized command line option '-m32'; did you mean '-mbe32'?^M
Compilation failed.^M
(gdb) FAIL: gdb.compile/compile-ops.exp: compile code (void) param
This patch fixes it by implementing gcc_target_options gdbarch method
for arm-linux to override option "-m32".
gdb:
2018-01-19 Yao Qi <yao.qi@linaro.org>
* arm-linux-tdep.c (arm_linux_gcc_target_options): New function.
(arm_linux_init_abi): Install it.
Yao Qi [Fri, 19 Jan 2018 09:08:36 +0000 (09:08 +0000)]
Find arm-linux-gnueabi(hf)?-gcc in compile
GCC for arm-linux has different names on different distros. It is
arm-linux-gnu-gcc on fedora. Debian/Ubuntu has arm-linux-gnueabihf-gcc
and arm-linux-gnueabi-gcc. So when I run gdb.compile/ tests on arm-linux,
I get,
(gdb) compile code -- ;
Could not find a compiler matching "^arm(-[^-]*)?-linux(-gnu)?-gcc$"
This patch extend the regexp to match both arm-linux-gnu-gcc and
arm-linux-gnueabihf-gcc.
gdb:
2018-01-19 Yao Qi <yao.qi@linaro.org>
* osabi.c (gdb_osabi_names): Extend the regexp for
arm-linux-gnueabihf and arm-linux-gnueabi.
Ruslan Kabatsayev [Sun, 7 Jan 2018 21:59:13 +0000 (00:59 +0300)]
Make tests expect [ \t]+ pattern instead of \t for "info reg" command
This will allow to format output of "info reg" command as we wish,
without breaking the tests. In particular, it'll let us correctly align
raw and natural values of the registers using spaces instead of current
badly-working approach with tabs.
This change is forwards- and backwards-compatible, so that the amended
tests will work in the same way before and after reformatting patches
(unless the tests check formatting, of course, but I've not come across
any such tests).
Some tests already used this expected pattern, so they didn't
even have to be modified. Others are changed by this patch.
I've checked this on a i386 system, with no noticeable differences in
test results, so at least on i386 nothing seems to be broken by this.
gdb/testsuite/ChangeLog:
* gdb.arch/powerpc-d128-regs.exp: Replace expected "\[\t\]*" from
"info reg" with "\[ \t\]*".
* gdb.arch/altivec-regs.exp: Replace expected "\t" from "info reg" with
"\[ \t\]+".
* gdb.arch/s390-multiarch.exp: Ditto.
* gdb.base/pc-fp.exp: Ditto.
* gdb.reverse/i386-precsave.exp: Ditto.
* gdb.reverse/i386-reverse.exp: Ditto.
* gdb.reverse/i387-env-reverse.exp: Ditto.
* gdb.reverse/i387-stack-reverse.exp: Ditto.
H.J. Lu [Fri, 19 Jan 2018 01:21:13 +0000 (17:21 -0800)]
Also xfail ld-elf/group1.d for Solaris
Also xfail ld-elf/group1.d for Solaris since _GLOBAL_OFFSET_TABLE_ is
always generated for Solaris as a global symbol after
.*: 0+1000 +0 +(NOTYPE|OBJECT) +WEAK +DEFAULT +. foo
instead of appending "#..." which will weaken the test.
* testsuite/ld-elf/group1.d: Also xfail Solaris.
H.J. Lu [Fri, 19 Jan 2018 00:23:33 +0000 (16:23 -0800)]
x86: Update ld-elf/linkinfo1[ab].d for Solaris/x86
Update ld-elf/linkinfo1[ab].d to accommodate slightly different PLT/GOT
order/layout for Solaris/x86 targets.
* testsuite/ld-elf/linkinfo1a.d: Updated for slightly different
PLT/GOT order/layout for Solaris/x86 targets.
* testsuite/ld-elf/linkinfo1b.d: Likewise.
H.J. Lu [Fri, 19 Jan 2018 00:21:46 +0000 (16:21 -0800)]
solaris2.em: Fold after_allocation into before_allocation
Since all ELF linkers call check_relocs after opening all inputs, we
can fold after_allocation into before_allocation so that local dynamic
symbols will be placed before global dynamic symbols in .dynsym section.
This fixed:
FAIL: Common symbol override test (auxiliary shared object build)
FAIL: ld-elf/pr19617a
FAIL: ld-elf/pr19698
for i386-solaris2.12 and x86_64-solaris2.12 targets.
PR ld/22728
* emultempl/solaris2.em (elf_solaris2_after_allocation): Fold
into ...
(elf_solaris2_before_allocation): This.
(LDEMUL_AFTER_ALLOCATION): Removed.
GDB Administrator [Fri, 19 Jan 2018 00:00:31 +0000 (00:00 +0000)]
Automatic date update in version.in
Andreas Arnez [Thu, 18 Jan 2018 18:42:46 +0000 (19:42 +0100)]
GDB testsuite: Re-enable -fdiagnostics-color=never
In August 2017 the GDB test suite was changed to always add the compile
option "-fdiagnostics-color=never", see:
https://sourceware.org/ml/gdb-patches/2017-08/msg00150.html
Since this option is not understood by rustc, a commit from 09/2017
dropped its use in that case:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=
5eb5f850
("Don't use -fdiagnostics-color=never for rustc")
But that change goes overboard and stops using the option for other
languages as well. Thus compiler diagnostics written into gdb.log may
contain colored output again. This is fixed.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_compile): Re-enable use of
universal_compile_options for languages other than Rust.
Andreas Arnez [Thu, 18 Jan 2018 18:41:16 +0000 (19:41 +0100)]
S390: Use soft float in s390-tdbregs test case
The GDB test case s390-tdbregs.exp verifies GDB's handling of the
"transaction diagnostic block". For simplicity, the test case uses the
"transaction begin" (TBEGIN) instruction with the "allow floating-point
operation" flag set to zero. But some GCC versions may indeed emit
floating point or vector instructions for this test case. If this happens
in the transaction, it aborts, and an endless loop results.
This change tells the compiler to produce a soft-float binary, so no
floating-point or vector registers are touched.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-tdbregs.exp: Add the compile option -msoft-float.
Yao Qi [Thu, 18 Jan 2018 15:29:31 +0000 (15:29 +0000)]
Make abbrev_table::abbrevs private
abbrev_table::abbrevs is only access within abbrev_table's methods, so
it can be private. Add "m_" prefix.
gdb:
2018-01-18 Yao Qi <yao.qi@linaro.org>
* dwarf2read.c (abbrev_table) <abbrevs>: Rename it to
m_abbrevs.
(abbrev_table::add_abbrev): Update.
(abbrev_table::lookup_abbrev): Update.
Yao Qi [Thu, 18 Jan 2018 12:21:01 +0000 (12:21 +0000)]
Call cooked_read in ppu2spu_prev_register
The code in ppu2spu_prev_register is in fact regcache_cooked_read,
because spu doesn't have gdbarch method pseudo_register_read_value.
gdb:
2018-01-18 Yao Qi <yao.qi@linaro.org>
* ppc-linux-tdep.c (ppu2spu_prev_register): Call cooked_read.
Alan Modra [Thu, 18 Jan 2018 11:36:40 +0000 (22:06 +1030)]
PowerPC PLT stub alignment fixes
Asking for ppc32 plt call stubs to be aligned at 32 byte boundaries
didn't quite work. For ld.bfd they were spaced 32 bytes apart, but
only started on a 16 byte boundary. ld.gold also didn't get it right.
Finding that bug made me check over the ppc64 plt stub alignment,
where I found that negative values for alignment (meaning align to
minimize boundary crossing) were not accepted. Since no one has
complained about that, I guess I could have removed the feature from
ld.bfd documentation, but I've opted instead to correct the code.
I've also added an optional alignment paramenter for ppc32
--plt-align, for some consistency with gold and ppc64 ld.bfd.
bfd/
* elf32-ppc.c (ppc_elf_create_glink): Correct alignment of .glink.
* elf64-ppc.c (ppc64_elf_size_stubs): Handle negative plt_stub_align.
(ppc64_elf_build_stubs): Likewise.
gold/
* powerpc.cc (param_plt_align): New function supplying default
--plt-align values. Use it..
(Stub_table::plt_call_align): ..here, and..
(Output_data_glink::global_entry_align): ..here.
(Stub_table::stub_align): Correct 32-bit minimum alignment.
ld/
* emultempl/ppc32elf.em: Support optional --plt-align arg.
* emultempl/ppc64elf.em: Support negative --plt-align arg.
Nick Clifton [Thu, 18 Jan 2018 09:38:59 +0000 (09:38 +0000)]
Update Bulgarian translation of the binutils sub-directory
GDB Administrator [Thu, 18 Jan 2018 00:00:24 +0000 (00:00 +0000)]
Automatic date update in version.in
Sergio Durigan Junior [Tue, 16 Jan 2018 19:41:17 +0000 (14:41 -0500)]
Fix warning on gdb/compile/compile.c (C++-ify "triplet_rx")
This fixes a GCC warning that happens when compiling
gdb/compile/compile.c on some GCC versions (e.g., "gcc (GCC) 7.2.1
20180104 (Red Hat 7.2.1-6)"):
../../gdb/compile/compile.c: In function 'void eval_compile_command(command_line*, const char*, compile_i_scope_types, void*)':
../../gdb/compile/compile.c:548:19: warning: 'triplet_rx' may be used uninitialized in this function [-Wmaybe-uninitialized]
error_message = compiler->fe->ops->set_arguments_v0 (compiler->fe, triplet_rx,
~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
argc, argv);
~~~~~~~~~~~
../../gdb/compile/compile.c:466:9: note: 'triplet_rx' was declared here
char *triplet_rx;
^~~~~~~~~~
It's a simple patch that converts "triplet_rx" from "char *" to
"std::string", thus guaranteeing that it will be always initialized.
I've regtested this patch and did not find any regressions. OK to
apply on both master and 8.1 (after creating a bug for it)?
gdb/ChangeLog:
2018-01-17 Sergio Durigan Junior <sergiodj@redhat.com>
* compile/compile.c (compile_to_object): Convert "triplet_rx"
to "std::string".
Jim Wilson [Wed, 17 Jan 2018 22:04:16 +0000 (14:04 -0800)]
RISC-V: Fix bug in prior addi/c.nop patch.
gas/
* config/tc-riscv.c (validate_riscv_insn) <'z'>: New.
(riscv_ip) <'z'>: New.
opcodes/
* riscv-opc.c (riscv_opcodes) <addi>: Use z instead of 0.
Tom Tromey [Sat, 6 Jan 2018 00:26:21 +0000 (17:26 -0700)]
Remove symbolp typedef
This removes the symbolp typedef from dwarf2read.c. It is no longer
used.
2018-01-17 Tom Tromey <tom@tromey.com>
* dwarf2read.c (symbolp): Remove typedef. Don't instantiate VEC.
Tom Tromey [Sat, 6 Jan 2018 00:26:20 +0000 (17:26 -0700)]
Remove objfile argument from add_dyn_prop
The objfile argument to add_dyn_prop is redundant, so this patch
removes it.
2018-01-17 Tom Tromey <tom@tromey.com>
* gdbtypes.h (add_dyn_prop): Remove objfile parameter.
* gdbtypes.c (add_dyn_prop): Remove objfile parameter.
(create_array_type_with_stride): Update.
* dwarf2read.c (set_die_type): Update.
This page took 0.052351 seconds and 4 git commands to generate.