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.
Tom Tromey [Sat, 6 Jan 2018 00:26:19 +0000 (17:26 -0700)]
Change dwarf2_cu::method_info to be a std::vector
This changes the type of dwarf2_cu::method_info and fixes up the uses.
In order to remove cleanups from process_full_comp_unit and
process_full_type_unit, psymtab_include_file_name also had to be
changed to avoid leaving dangling cleanups.
2018-01-17 Tom Tromey <tom@tromey.com>
* dwarf2read.c (delayed_method_info): Remove typedef.
(dwarf2_cu::method_info): Now a std::vector.
(add_to_method_list): Update.
(free_delayed_list): Remove.
(compute_delayed_physnames): Update.
(process_full_comp_unit, process_full_type_unit): Clear the method
list. Remove cleanups.
(psymtab_include_file_name): Add name_holder parameter. Use
unique_xmalloc_ptr.
(dwarf_decode_lines): Update.
Simon Marchi [Sun, 7 Jan 2018 16:41:09 +0000 (11:41 -0500)]
Allocate dwarf2_cu with new
This changes dwarf2_cu to be allocated with new, and fixes up the
users.
2018-01-17 Tom Tromey <tom@tromey.com>
Simon Marchi <simon.marchi@ericsson.com>
* dwarf2read.c (struct dwarf2_cu): Add constructor, destructor.
(dwarf2_per_objfile::free_cached_comp_units)
(init_tu_and_read_dwo_dies, init_cutu_and_read_dies)
(init_cutu_and_read_dies_no_follow): Update.
(dwarf2_cu::dwarf2_cu): Rename from init_one_comp_unit.
(dwarf2_cu::~dwarf2_cu): New.
(free_heap_comp_unit, free_stack_comp_unit): Remove.
(age_cached_comp_units, free_one_cached_comp_unit): Update.
Tom Tromey [Sat, 6 Jan 2018 00:26:17 +0000 (17:26 -0700)]
Allocate abbrev_table with new
This changes dwarf2read.c to allocate abbrev tables using "new", and
then updates the users.
This version of the patch incorporates the changes that Simon
implemented. These changes simplify the ownership rules for abbrev
tables.
2018-01-17 Tom Tromey <tom@tromey.com>
Simon Marchi <simon.marchi@ericsson.com>
* dwarf2read.c (struct dwarf2_cu) <abbrev_table>: Remove.
(struct die_reader_specs) <abbrev_table>: New member.
(struct abbrev_table): Add constructor.
<alloc_abbrev, add_abbrev, lookup_abbrev>: Declare.
<abbrev_obstack>: Now an auto_obstack.
(abbrev_table_up): New typedef.
(init_cu_die_reader): Add abbrev_table parameter.
(read_cutu_die_from_dwo): Remove abbrev_table_provided parameter.
Add result_dwo_abbrev_table.
(init_tu_and_read_dwo_dies, init_cutu_and_read_dies)
(init_cutu_and_read_dies_no_follow, build_type_psymtabs_1):
Update.
(peek_die_abbrev): Take die_reader_specs, not dwarf_cu as
parameter.
(skip_children): Update.
(abbrev_table::alloc_abbrev): Rename from
abbrev_table_alloc_abbrev.
(abbrev_table::add_abbrev): Rename from abbrev_table_add_abbrev.
(abbrev_table::lookup_abbrev): Rename from
abbrev_table_lookup_abbrev.
(abbrev_table_read_table): Return abbrev_table_up.
(abbrev_table_free, abbrev_table_free_cleanup)
(dwarf2_read_abbrevs, dwarf2_free_abbrev_table): Remove.
(load_partial_dies): Update.
Tom Tromey [Sat, 6 Jan 2018 00:26:16 +0000 (17:26 -0700)]
Unify new_symbol and new_symbol_full
This patch unifies new_symbol with new_symbol_full, replacing a
wrapper function with a default parameter.
2018-01-17 Tom Tromey <tom@tromey.com>
* dwarf2read.c (dwarf2_compute_name): Update comment.
(read_func_scope, read_variable): Update.
(new_symbol): Remove.
(new_symbol_full): Rename to new_symbol.
Simon Marchi [Wed, 17 Jan 2018 17:59:51 +0000 (12:59 -0500)]
Fix ChangeLog dates of previous commit
Mike Gulick [Mon, 30 Oct 2017 22:13:44 +0000 (18:13 -0400)]
Fix gdb segv when objfile can't be opened
This fixes PR 16577.
This patch changes gdb_bfd_map_section to issue a warning rather than an error
if it is unable to read the object file, and sets the size of the section/frame
that it attempted to read to 0 on error.
The description of gdb_bfd_map_section states that it will try to read or map
the contents of the section SECT, and if successful, the section data is
returned and *SIZE is set to the size of the section data. This function was
throwing an error and leaving *SIZE as-is. Setting the section size to 0
indicates to dwarf2_build_frame_info that there is no data to read, otherwise
it will try to read from an invalid frame pointer.
Changing the error to a warning allows this to be handled gracefully.
Additionally, the error was clobbering the breakpoint output indicating the
current frame (function name, arguments, source file, and line number). E.g.
Thread 3 "foo" hit Breakpoint 1, BFD: reopening /tmp/jna-
1013829440/jna2973250704389291330.tmp: No such file or directory
BFD: reopening /tmp/jna-
1013829440/jna2973250704389291330.tmp: No such file or directory
(gdb)
While the "BFD: reopening ..." messages will still appear interspersed in the
breakpoint output, the current frame info is now displayed:
Thread 3 "foo" hit Breakpoint 1, BFD: reopening /tmp/jna-
1013829440/jna1875755897659885075.tmp: No such file or directory
BFD: reopening /tmp/jna-
1013829440/jna1875755897659885075.tmp: No such file or directory
warning: Can't read data for section '.eh_frame' in file '/tmp/jna-
1013829440/jna1875755897659885075.tmp'
do_something () at file.cpp:80
80 {
(gdb)
Simon Marchi [Wed, 17 Jan 2018 17:33:57 +0000 (12:33 -0500)]
Make linux_ptrace_attach_fail_reason return an std::string
This patch makes linux_ptrace_attach_fail_reason and
linux_ptrace_attach_fail_reason_string return std::string. It also
replaces usages of struct buffer with std::string. This allows getting
rid of a cleanup in in linux_ptrace_attach_fail_reason_string and
simplifies the code in general.
Something that looks odd to me is that in
linux_ptrace_attach_fail_reason, if the two messages are appended, there
is no separating space or \n, so the result won't be very nice. I left
it as-is for now though.
gdb/ChangeLog:
* nat/linux-ptrace.h (linux_ptrace_attach_fail_reason): Return
std::string.
(linux_ptrace_attach_fail_reason_string): Likewise.
* nat/linux-ptrace.c (linux_ptrace_attach_fail_reason):
Likewise.
(linux_ptrace_attach_fail_reason_string): Likewise.
* linux-nat.c (attach_proc_task_lwp_callback): Adjust.
gdb/gdbserver/ChangeLog:
* linux-low.c (attach_proc_task_lwp_callback): Adjust to
linux_ptrace_attach_fail_reason_string now returning an
std::string.
(linux_attach): Likewise.
* thread-db.c (attach_thread): Likewise.
Simon Marchi [Wed, 17 Jan 2018 17:33:45 +0000 (12:33 -0500)]
linux-nat: Remove unnecessary xstrdup
I think this xstrdup is not useful. We can pass ex.message directly to
throw_error instead.
gdb/ChangeLog:
* linux-nat.c (linux_nat_attach): Remove xstrdup.
Igor Tsimbalist [Wed, 17 Jan 2018 16:45:52 +0000 (19:45 +0300)]
Replace CET bit with IBT and SHSTK bits.
The latest specification for Intel CET technology defined two
new bits instead of previously used CET bit. These are IBT and
SHSTK bits. The patch replaces CET bit with IBT and SHSTK bits.
gas/
* config/tc-i386.c (cpu_arch): Delete .cet. Add .ibt, .shstk.
(cpu_noarch): Add noibt, noshstk.
(parse_insn): Change cpucet to cpuibt.
* doc/c-i386.texi: Delete .cet. Add .ibt, .shstk.
* testsuite/gas/i386/cet-ibt-inval.l: New test.
* testsuite/gas/i386/cet-ibt-inval.s: Likewise.
* testsuite/gas/i386/cet-shstk-inval.l: Likewise.
* testsuite/gas/i386/cet-shstk-inval.s: Likewise.
* testsuite/gas/i386/x86-64-cet-ibt-inval.l: Likewise.
* testsuite/gas/i386/x86-64-cet-ibt-inval.s: Likewise.
* testsuite/gas/i386/x86-64-cet-shstk-inval.l: Likewise.
* testsuite/gas/i386/x86-64-cet-shstk-inval.s: Likewise.
opcodes/
* i386-gen.c (cpu_flag_init): Delete CPU_CET_FLAGS,
CpuCET. Add CPU_IBT_FLAGS, CPU_SHSTK_FLAGS, CPY_ANY_IBT_FLAGS,
CPU_ANY_SHSTK_FLAGS, CpuIBT, CpuSHSTK.
(cpu_flags): Add CpuIBT, CpuSHSTK.
* i386-opc.h (enum): Add CpuIBT, CpuSHSTK.
(i386_cpu_flags): Add cpuibt, cpushstk.
* i386-opc.tbl: Change CpuCET to CpuSHSTK and CpuIBT.
* i386-init.h: Regenerate.
* i386-tbl.h: Likewise.
Nick Clifton [Wed, 17 Jan 2018 15:52:37 +0000 (15:52 +0000)]
Update Ukranian and Russian translations in bfd library
Eldar Abusalimov [Mon, 15 Jan 2018 13:57:42 +0000 (16:57 +0300)]
configure: Fix test for fs_base/gs_base in <sys/user.h>
Make <sys/types.h> be included prior to including <sys/user.h>.
glibc versions older than 2.14 use __uintNN_t types within certain
structures defined in <sys/user.h> probably assuming these types are
defined prior to including the header. This results in the following
`configure` feature test compilation error that makes it think that
`struct user_regs_struct` doesn't have `fs_base`/`gs_base` fields,
althouh it does.
configure:13617: checking for struct user_regs_struct.fs_base
configure:13617: gcc -c -g -O2 -I/linux/include conftest.c >&5
In file included from conftest.c:158:0:
/usr/include/sys/user.h:32:3: error: unknown type name '__uint16_t'
__uint16_t cwd;
^
/usr/include/sys/user.h:33:3: error: unknown type name '__uint16_t'
__uint16_t swd;
^
/usr/include/sys/user.h:34:3: error: unknown type name '__uint16_t'
__uint16_t ftw;
^
/usr/include/sys/user.h:35:3: error: unknown type name '__uint16_t'
__uint16_t fop;
^
/usr/include/sys/user.h:36:3: error: unknown type name '__uint64_t'
__uint64_t rip;
^
/usr/include/sys/user.h:37:3: error: unknown type name '__uint64_t'
__uint64_t rdp;
^
/usr/include/sys/user.h:38:3: error: unknown type name '__uint32_t'
__uint32_t mxcsr;
^
/usr/include/sys/user.h:39:3: error: unknown type name '__uint32_t'
__uint32_t mxcr_mask;
^
/usr/include/sys/user.h:40:3: error: unknown type name '__uint32_t'
__uint32_t st_space[32]; /* 8*16 bytes for each FP-reg = 128 bytes */
^
/usr/include/sys/user.h:41:3: error: unknown type name '__uint32_t'
__uint32_t xmm_space[64]; /* 16*16 bytes for each XMM-reg = 256 bytes */
^
/usr/include/sys/user.h:42:3: error: unknown type name '__uint32_t'
__uint32_t padding[24];
^
configure:13617: $? = 1
configure: failed program was:
| /* confdefs.h */
...
| /* end confdefs.h. */
| #include <sys/user.h>
|
| int
| main ()
| {
| static struct user_regs_struct ac_aggr;
| if (ac_aggr.fs_base)
| return 0;
| ;
| return 0;
| }
Recent glibc versions don't use typedef'ed int types in <sys/user.h>,
thus allowing it to be included as is
(glibc commit
d79a9c949c84e7f0ba33e87447c47af833e9f11a).
However there're still some distros alive that use older glibc,
for instance, RHEL/CentOS 6 package glibc 2.12.
Also affects PR gdb/21559:
../../gdb/regcache.c:1087: internal-error: void regcache_raw_supply(regcache, int, const void): Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.
As noted by Andrew Paprocki, who submitted the PR
(https://sourceware.org/bugzilla/show_bug.cgi?id=21559#c3):
> It should be noted that modifying `configure` to force on
> `HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE` and
> `HAVE_STRUCT_USER_REGS_STRUCT_GS_BASE` fixes this issue. For some
> reason the `configure` tests for `fs_base` and `gs_base` fail
> even though `sys/user.h` on RHEL5 has the fields defined in
> `user_regs_struct`.
Note that this patch does NOT fix the root cause of PR gdb/21559,
although now that `configure` properly detects the presence of the
fields and sets HAVE_XXX accordingly, the execution takes another
path, which doesn't lead to the assertion failure in question.
gdb/ChangeLog:
2018-01-17 Eldar Abusalimov <eldar.abusalimov@jetbrains.com>
PR gdb/21559
* configure.ac: Include <sys/types.h> prior to <sys/user.h> when
checking for fs_base/gs_base fields in struct user_regs_struct.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
2018-01-17 Eldar Abusalimov <eldar.abusalimov@jetbrains.com>
PR gdb/21559
* configure.ac: Include <sys/types.h> prior to <sys/user.h> when
checking for fs_base/gs_base fields in struct user_regs_struct.
* configure: Regenerate.
Yao Qi [Wed, 17 Jan 2018 12:48:52 +0000 (12:48 +0000)]
Don't pass -m64 to libcc1 on aarch64-linux.
Nowadays, if we use "compile" on aarch64-linux, we'll get the following
error,
(gdb) compile code -- ;
aarch64-none-linux-gnu-gcc: error: unrecognized command line option '-m64'
because the default gcc_target_options returns "-m64" and
"-mcmodel=large", neither is useful to aarch64-linux.
gdb:
2018-01-17 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-tdep.c (aarch64_linux_gcc_target_options): New
function.
(aarch64_linux_init_abi): Install it to gdbarch hook
gcc_target_options.
projects / binutils-gdb.git / log