Remove code relevant for printing C/C++ Integer values in a
Fortran specific file to unify printing of Fortran values.
This does not change the output.
Printing the prefix "PTR TO -> (" resp. "REF TO ->(" ignored the active
indentation level. This caused inconsistent appearance of user-defined
Fortran types containing pointers. Fix by using "fprintfi_filtered" with the
current indentation level for outputting the prefix string. Add test case
ptr-indentation.
Example using 'ptype' on object of type:
type TypeWithPointer
integer i
integer, pointer:: p
end type TypeWithPointer
Before:
type = Type typewithpointer
integer(kind=4) :: i
PTR TO -> ( integer(kind=4) :: p)
End Type typewithpointer
After:
type = Type typewithpointer
integer(kind=4) :: i
PTR TO -> ( integer(kind=4) :: p)
End Type typewithpointer
Don't set r_info and r_sym fields in _bfd_x86_elf_link_hash_table_create.
Instead, set them in _bfd_x86_elf_link_setup_gnu_properties. We can
avoid adding elf64-x86-64.lo and elf64.lo together with elfxx-x86.lo to
bfd_backends.
* configure.ac (bfd_backends): Don't add elf64-x86-64.lo nor
elf64.lo together with elfxx-x86.lo for 64-bit BFD.
* configure: Regenerated.
* elf32-i386.c (elf_i386_link_setup_gnu_properties): Set r_info
and r_sym fields of plt_layout.
* elf64-x86-64.c (elf_x86_64_link_setup_gnu_properties):
Likewise.
* elfxx-x86.c (elf_x86_64_is_reloc_section): Remove BFD64 check.
(_bfd_x86_elf_link_hash_table_create): Likewise. Don't set
r_info nor r_sym fields.
(_bfd_x86_elf_link_setup_gnu_properties): Set r_info and r_sym
fields of htab.
* elfxx-x86.h (elf_x86_plt_layout_table): Add r_info and r_sym.
When linking the following code
.global _prog_start
_prog_start:
mv x1, x1
mv x2, x2
.align 2
rvc_boundry:
.option norvc
.align 3
mv x3, x3
we currently emit an invalid two-byte 0 instruction. The actual output
code looks like
0000000080000000 <_prog_start>:
80000000: 8086 mv ra,ra
80000002: 810a mv sp,sp
0000000080000004 <rvc_boundry>:
80000004: 0000 unimp
80000006: 0001 nop
80000008: 00018193 mv gp,gp
This ends up manifesting due to the two-byte compressed NOP that's
pessimisticly emitted by the ".align 2", which results in "rvc_boundry"
being 2-byte aligned. frag_align_code() then goes and outputs a 2-byte
NOP (which is invalid in no-RVC mode) to align the code back to a 4-byte
boundry, which can't be relaxed away by the linker as it's not part of
the R_RISCV_RELAX relocation.
The fix is to just always emit the worst case possible alignment into
the output as a single R_RISCV_RELAX, which the linker will then fix up.
With this patch I get the expected code generation
0000000080000000 <_prog_start>:
80000000: 8086 mv ra,ra
80000002: 810a mv sp,sp
0000000080000004 <rvc_boundry>:
80000004: 00000013 nop
80000008: 00018193 mv gp,gp
gas/ChangeLog
2017-09-07 Palmer Dabbelt <palmer@dabbelt.com>
* config/tc-riscv.c (riscv_frag_align_code): Emit the entire
alignment sequence inside R_RISCV_ALIGN.
This used to just print "can't relax section: Success", which is a silly
error message.
bfd/ChangeLog
2017-09-07 Palmer Dabbelt <palmer@dabbelt.com>
* elfnn-riscv.c (_bfd_riscv_relax_align): Call bfd_set_error and
print an error message when unable to relax a .align directive.
I recently modified our Linux port's base address such the absolute
address 0 is no longer addressable as a 32-bit PC-relative offset.
Since Linux links a weak undefined symbol in an intermediate binary, it
needs to be able to reference absolute address 0.
This patch changes R_RISCV_PCREL_* relocations to absolute relocations
while resolving them in order to allow these symbols to be referenced in
PC-relative programs linked at high addresses. Note that this doesn't
apply to PIC, which also uses PC-relative relocations, just to
position-dependent objects, which we use to allow programs to be linked
at high addresses.
In case some of our embedded users are using R_RISCV_PCREL_* as a hacked
up method of getting position-independent binaries (which can work if
you have very simple programs), we only convert the relocations when the
PC-relative version would overflow.
bfd/ChangeLog:
2017-09-07 Palmer Dabbelt <palmer@dabbelt.com>
* elfnn-riscv.c (riscv_zero_pcrel_hi_reloc): New function.
(riscv_record_pcrel_hi_reloc): Add absolute argument.
(riscv_elf_relocate_section): Call riscv_zero_pcrel_hi_reloc for
R_RISCV_PCREL_HI20 relocs, and pass the result to
riscv_record_pcrel_hi_reloc.
This entry was added twice within the same commit, back in Dec 2017
by the following change:
commit aefd8b33d9
Date: Thu Dec 22 22:14:02 2016 -0500
Subject: Implement proper "startup-with-shell" support on gdbserver
I think the second entry is just a rebase/merge oversight, and it wasn't
meant to be added there, particularly since the 7.11 branch was no longer
active at that time anymore.
This patch just removes the entry.
gdb/ChangeLog:
* NEWS (Changes in GDB 7.11): Remove entry for QStartupWithShell.
Instead of converting GOT relocations when sizing dynamic sections, we
convert GOT relocations during relocation check. Add a field, local_ref,
to elf_x86_link_hash_entry to indicate if symbol references are always
local with a new function to check if symbol references are always local,
which works in check_relocs.
* elf32-i386.c (elf_i386_convert_load_reloc): Add an argument,
r_type_p. Remove the converted argument. Replace
SYMBOL_REFERENCES_LOCAL with SYMBOL_REFERENCES_LOCAL_P. Return
the new relocation type via r_type_p.
(elf_i386_relocate_section): Likewise.
(elf_i386_finish_dynamic_symbol): Likewise.
(need_convert_load): Removed.
(check_relocs_failed): Updated.
(elf_i386_check_relocs): Call elf_i386_convert_load_reloc,
instead of setting need_convert_load.
(_bfd_i386_elf_convert_load): Removed.
* elf64-x86-64.c (need_convert_load): Removed.
(check_relocs_failed): Updated.
(elf_x86_64_convert_load_reloc): Add an argument, r_type_p.
Replace SYMBOL_REFERENCES_LOCAL with SYMBOL_REFERENCES_LOCAL_P.
Return the new relocation type via r_type_p.
(elf_x86_64_check_relocs): Call elf_x86_64_convert_load_reloc,
instead of setting need_convert_load.
(elf_x86_64_check_relocs): Don't check PIC if relocation has
been converted.
(_bfd_x86_64_elf_convert_load): Removed.
(elf_x86_64_relocate_section): Replace SYMBOL_REFERENCES_LOCAL
with SYMBOL_REFERENCES_LOCAL_P.
(elf_x86_64_finish_dynamic_symbol): Likewise.
* elfxx-x86.c (_bfd_x86_elf_link_hash_table_create): Don't
set convert_load.
(_bfd_x86_elf_size_dynamic_sections): Don't call convert_load.
(_bfd_x86_elf_link_symbol_references_local): New function.
* elfxx-x86.h (SYMBOL_REFERENCES_LOCAL_P): New.
(UNDEFINED_WEAK_RESOLVED_TO_ZERO): Replace elf.forced_local with
SYMBOL_REFERENCES_LOCAL_P.
(elf_x86_link_hash_entry): Add local_ref.
(elf_x86_link_hash_table): Remove convert_load.
(_bfd_i386_elf_convert_load): Removed.
(_bfd_x86_64_elf_convert_load): Likewise.
(_bfd_x86_elf_link_symbol_references_local): New.
This simplifies the handling of funcall_chain, by changing it to be a
std::vector<int> and then fixing the users. This allows the removal
of a cleanup.
It would be even cleaner to replace this with better logic in the
parsers; but a baby step seemed ok.
gdb/ChangeLog
2017-09-05 Tom Tromey <tom@tromey.com>
* parse.c (funcall_chain): Now a std::vector.
(start_arglist, end_arglist): Simplify.
(free_funcalls): Remove.
(parse_exp_in_context_1): Remove cleanup.
This removes the last remaining cleanups from d-exp.y.
2017-09-05 Tom Tromey <tom@tromey.com>
* d-exp.y (PrimaryExpression): Use std::string.
(d_parse): Don't create a cleanup.
The DWARF reader is littered with the following idiom to read a linkage name
from the debug info:
mangled = dwarf2_string_attr (die, DW_AT_linkage_name, cu);
if (mangled == NULL)
mangled = dwarf2_string_attr (die, DW_AT_MIPS_linkage_name, cu);
This patch introduces functions to simplify this to:
mangled = dw2_linkage_name (die, cu);
or
attr = dw2_linkage_name_attr (die, cu);
gdb/ChangeLog:
* dwarf2read.c (dw2_linkage_name_attr): New function.
(dw2_linkage_name): New function.
(dwarf2_compute_name, dwarf2_physname, read_call_site_scope)
(guess_full_die_structure_name, dwarf2_name): Use dw2_linkage_name.
(anonymous_struct_prefix, dwarf2_name): Use dw2_linkage_name_attr.
PR gdb/22010 concerns a regression I introduced with the scalar
printing changes. The bug is that this code in sizeof.exp:
set signof_byte [get_integer_valueof "'\\377'" -1]
can incorrectly compute sizeof_byte. One underlying problem here is
that gdb's C parser doesn't treat a char constant as an int (this is
PR 19973).
However, it seems good to have an immediate fix for the regression.
The simplest is to cast to an int here.
testsuite/ChangeLog
2017-09-05 Tom Tromey <tom@tromey.com>
PR gdb/22010:
* gdb.base/sizeof.exp (check_valueof): Cast char constant to int.
String comparison of in a POSIX bourne shell must be done
with '=', not '=='. For example the NetBSD sh(1) does not
support it.
gdb/ChangeLog
2017-09-06 Kamil Rytarowski <n54@gmx.com>
* config/djgpp/djconfig.sh: Correct shell portability issue.
Tests in gdb.arch/thumb2-it.exp call functions defined in assembly
without type debugging information. Since
7022349d5c ("Stop assuming no-debug-info
functions return int") this triggers an error which leads to many tests
to FAIL. This patch cast the call to indicate the return type of the
functions when calling them.
2017-09-06 Thomas Preud'homme <thomas.preudhomme@arm.com>
gdb/testsuite/
* gdb.arch/thumb2-it.exp: Cast call to assembly defined function.
NetBSD ships with gcore(1) againg since the version 2.0.
This tool is functional and actively maintained.
gdb/ChangeLog
2017-09-06 Kamil Rytarowski <n54@gmx.com>
* configure.nat: Define HAVE_NATIVE_GCORE_HOST on NetBSD.
Support for collecting and supplying general purpose and floating point
register sets is provided along with signal frame unwinding.
gdb/ChangeLog:
* Makefile.in (ALL_64_TARGET_OBS): Add aarch64-fbsd-tdep.o.
(ALLDEPFILES): Add aarch64-fbsd-tdep.c.
* NEWS: Mention new FreeBSD/aarch64 target.
* configure.tgt: Add aarch64*-*-freebsd*.
* aarch64-fbsd-tdep.c: New file.
* aarch64-fbsd-tdep.h: New file.
Add R_X86_64_converted_reloc_bit to relocation type to indicate if a
relocation is converted from a GOTPCREL relocation. Linker now generates
failed to convert GOTPCREL relocation; relink with --no-relax
for all cases, including relocations against local symbols.
bfd/
* elf64-x86-64.c (R_X86_64_converted_reloc_bit): New.
(elf_x86_64_info_to_howto): Get the real relocation type by
masking out R_X86_64_converted_reloc_bit.
(elf_x86_64_check_tls_transition): Get the real relocation type
by masking out R_X86_64_converted_reloc_bit.
(elf_x86_64_convert_load_reloc): Set R_X86_64_converted_reloc_bit
instead of setting converted_reloc.
(elf_x86_64_relocate_section): Check R_X86_64_converted_reloc_bit
instead of converted_reloc. Get the real relocation type by
masking out R_X86_64_converted_reloc_bit.
(elf_x86_64_link_setup_gnu_properties): Verify that the value of
R_X86_64_converted_reloc_bit is valid.
* elfxx-x86.h (converted_reloc): Removed.
ld/
* testsuite/ld-x86-64/pr19609-2a.d: Updated.
* testsuite/ld-x86-64/pr19609-2b.d: Likewise.
* testsuite/ld-x86-64/pr19609-4a.d: Likewise.
* testsuite/ld-x86-64/pr19609-4c.d: Likewise.
Don't change r_type when performing TLS transitions to avoid getting
the relocation type with ELF32_R_TYPE again.
* elf32-i386.c (elf_i386_relocate_section): Don't change r_type
when calling elf_i386_tls_transition. Don't use ELF32_R_TYPE
to get the relocation type again.
* elf64-x86-64.c (elf_x86_64_relocate_section): Don't change
r_type when calling elf_x86_64_tls_transition. Don't use
ELF32_R_TYPE to get the relocation type again.
Since 2273f0ac95 ("change minsyms not to be relocated at
read-time"), printing TLS symbols of objfiles with a non-zero base
address, without debug info, fails.
E.g., with:
$ mv /usr/lib/debug /usr/lib/debug-x
to get debug info out of the way, we get:
$ echo 'int main(){}' | gcc -pthread -x c -
$ ./gdb -q -ex start -ex 'p (int) errno' ./a.out
Cannot access memory at address 0xffffef7c0698
instead of the expected:
$1 = 0
The regression is not visible with glibc debuginfo installed.
The problem is that we compute the address of TLS minsyms incorrectly.
To trigger the problem, it is important that the variable is in an
objfile with a non-zero base address. While glibc is a shared library
for 'errno', it's easier for the testcase to use PIE instead of a
shlib. For TLS variables in PT_EXEC the regression obviously does not
happen.
gdb/ChangeLog
2017-09-06 Jan Kratochvil <jan.kratochvil@redhat.com>
* parse.c (find_minsym_type_and_address): Don't relocate addresses
of TLS symbols.
gdb/testsuite/ChangeLog
2017-09-06 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.threads/tls-nodebug-pie.c: New file.
* gdb.threads/tls-nodebug-pie.exp: New file.
commit 23732b1e32
Author: Pedro Alves <palves@redhat.com>
Date: Tue Jun 27 16:22:08 2017 +0100
changed objfile_per_bfd_storage->storage_obstack
from 'struct obstack storage_obstack;'
to 'auto_obstack storage_obstack;'
So the obstack is auto allocated when the objfile_per_bfd_storage ctor is
manually called by get_objfile_bfd_data).
However, the ctor call was still followed by a manual call to
obstack_init (&storage->storage_obstack);
This results in a bunch of leaks detected by valgrind, such as:
==24665== 4,064 bytes in 1 blocks are definitely lost in loss record 11,469 of 11,590
==24665== at 0x4C27BF5: malloc (vg_replace_malloc.c:299)
==24665== by 0x5437B7: xmalloc (common-utils.c:44)
==24665== by 0x77CAA7: _obstack_begin_worker (obstack.c:141)
==24665== by 0x60168F: auto_obstack (gdb_obstack.h:70)
==24665== by 0x60168F: get_objfile_bfd_data(objfile*, bfd*) (objfiles.h:188)
==24665== by 0x601DB6: allocate_objfile(bfd*, char const*, enum_flags<objfile_flag>) (objfiles.c:423)
==24665== by 0x647753: symbol_file_add_with_addrs(bfd*, char const*, enum_flags<symfile_add_flag>, section_addr_info*, enum_flags<objfile_flag>, objfile*) (symfile.c:1158)
==24665== by 0x647C7B: symbol_file_add_separate(bfd*, char const*, enum_flags<symfile_add_flag>, objfile*) (symfile.c:1252)
==24665== by 0x4C7D79: elf_symfile_read(objfile*, enum_flags<symfile_add_flag>) (elfread.c:1270)
==24665== by 0x647CB4: read_symbols(objfile*, enum_flags<symfile_add_flag>) (symfile.c:861)
==24665== by 0x647809: syms_from_objfile_1 (symfile.c:1062)
-> remove the manual call to obstack_init.
Reg-tested on Debian 8/amd64, tests results are the same before/after the patch.
valgrind still show some leaks, but less.
gdb/ChangeLog
2017-09-05 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* objfiles.c (get_objfile_bfd_data): Remove useless obstack_init
call.
When GOTPCREL relocation conversion leads to relocation overflow, we
may get a mysterious linker message, like
relocation truncated to fit: R_X86_64_32S against symbol `foo'
This patch changes the linker message to
failed to convert GOTPCREL relocation; relink with --no-relax
bfd/
* elf64-x86-64.c (elf_x86_64_convert_load_reloc): Remove the sec
argument. Don't check relocation overflow. Avoid relocation
overflow if --no-relax is used. Set converted_reloc on symbol
if a GOTPCREL relocation is converted.
(elf_x86_64_relocate_section): Issue a fatal error and suggest
--no-relax if GOTPCREL relocation conversion leads to relocation
overflow.
* elfxx-x86.h (elf_x86_link_hash_entry): Add converted_reloc.
ld/
* testsuite/ld-x86-64/pr19609-4e.d: Updated.
* testsuite/ld-x86-64/pr19609-6a.d: Likewise.
I noticed that the gdb.rust tests fail because the test suite passes
-fdiagnostics-color=never to rustc. This is not a recognized rustc
option, and the test suite already handles passing the appropriate
option to the Rust compiler.
This patch fixes the problem.
testsuite/ChangeLog
2017-09-05 Tom Tromey <tom@tromey.com>
* lib/gdb.exp (gdb_compile): Don't use universal_compile_options
for rust.
Using follow-exec-mode "new" takes a different code path than "same", so
it's interesting to test this path in combination with a change in
architecture of the inferior. This test fails if you remove the
previous patch.
gdb/testsuite/ChangeLog:
* gdb.multi/multi-arch-exec.exp: Test with different
"follow-exec-mode" settings.
(do_test): New procedure.
As mentioned in the previous patch, we should avoid doing register reads
after a process does an exec and before we've updated that inferior's
gdbarch. Otherwise, we may interpret the registers using the wrong
architecture. When a process does an exec with "follow-exec-mode new",
a new inferior is added by follow_exec. The gdbarch of that new
inferior is at first set to some default value, probably specific to the
gdb build (I get "i386" here), which may not be the right one. It is
updated later by the call to target_find_description. Before that
point, if we try to read the inferior's registers, we may not interpret
them correctly. This has been exposed by a failure in
gdb.base/foll-exec-mode.exp after the previous patch, with:
Remote 'g' packet reply is too long (expected 312 bytes, got 816 bytes)
The call to "add_thread" done just after adding the inferior is
problematic, because it ends up reading the registers (because the ptid
is re-used, we end up doing a switch_to_thread to it, which tries to
update stop_pc). The registers returned by gdbserver are the x86-64
ones, while we try to interpret them using the "i386" gdbarch.
Postponing the call to add_thread to until the target
description/gdbarch has been updated seems to fix the issue.
As to why this issue was uncovered by the previous patch: what I think
happened before that patch is that since we were updating stop_pc before
switching to the new inferior, we were filling the regcache associated
to the ptid (this worked fine as long as the architectures of the
previous and new process images were the same). The call to
switch_to_thread then worked, because the register read hit the
regcache. Now, it triggers a register read, while the gdbarch is not
set correctly, leading to the "reply is too long" error. If this is
right, it sounds wrong that we delete and re-add a thread with the same
ptid, and are able to access the registers from the deleted thread.
When we delete a thread, should we clear the regcache associated to that
ptid, so that the new thread starts with a fresh/empty regcache?
gdb/ChangeLog:
* infrun.c (follow_exec): Call add_thread after
target_find_description.
When an inferior execs and changes architecture (e.g. 64 bits to 32
bits), the gdbarch associated to the inferior is updated by the
follow_exec call in handle_inferior_event_1. We should avoid doing any
register read before that point, because the registers sent by the
remote side will be those of the new architecture, but we would
interpret them using the old architecture. We do just that by setting
stop_pc during this window, which obviously requires reading the
registers. This results in gdb.multi/multi-arch-exec.exp failing, GDB
outputting the following error:
Truncated register 50 in remote 'g' packet
This patch fixes that by postponing the setting of stop_pc to after
we've updated the inferior gdbarch.
This bug was hiding another problem, and as such introduces some
failures in gdb.base/foll-exec-mode.exp. The following patch takes care
of that.
gdb/ChangeLog:
* infrun.c (handle_inferior_event_1): When exec'ing, read
stop_pc after follow_exec.
... by adding the expected size, and the received size. I found this
useful when debugging gdbarch/remote issues, since it gives a hint of
what gdb expects and what the remote sent.
gdb/ChangeLog:
* remote.c (process_g_packet): Update error message.
This patch fixes the build failure caused by 22916b0
(Convert the rest x86 target descriptions).
gdb:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* configure.tgt (gdb_target_obs): Add i386.o for x86_64-*
targets.
While working on the no-debug-info debugging improvements, I found
evaluate_subexp_standard's function call code unnecessarily long and
hard to navigate and debug. The use of goto doesn't help either.
This commit tries to improve things by factoring out the
function-call-related code to separate helper functions.
gdb/ChangeLog:
2017-09-05 Pedro Alves <palves@redhat.com>
* eval.c (eval_call, evaluate_funcall): New functions, factored
out from ...
(evaluate_subexp_standard): ... this.
GDBserver now is able to generate target descriptions from features, so
don't need to remember these target description files.
Note that it should be i386/amd64-avx-avx512-linux.xml instead of
i386/amd64-avx-avx512.xml in $srv_amd64_linux_xmlfiles. This patch
removes it anyway.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* configure.srv (srv_amd64_linux_xmlfiles): Remove
i386/amd64-XXX-linux from it.
Now, all these amd64-linux pre-generated tdesc can be used as test, so
don't need to build them if $development is false.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* configure.srv: Empty srv_amd64_linux_regobj if $development is
false.
(ipa_amd64_linux_regobj): Remove.
(ipa_x32_linux_regobj): Remove.
This patch changes amd64-linux target descriptions so that they can be
dynamically generated in both GDB and GDBserver.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* Makefile.in (arch-amd64.o): New rule.
* configure.srv: Append arch-amd64.o.
* linux-amd64-ipa.c: Include common/x86-xstate.h.
(get_ipa_tdesc): Call amd64_linux_read_description.
(initialize_low_tracepoint): Don't call init_registers_x32_XXX
and init_registers_amd64_XXX.
* linux-x86-low.c (x86_linux_read_description): Call
amd64_linux_read_description.
(x86_get_ipa_tdesc_idx): Call amd64_get_ipa_tdesc_idx.
(initialize_low_arch): Don't call init_registers_x32_XXX and
init_registers_amd64_XXX.
* linux-x86-tdesc-selftest.c: Declare init_registers_amd64_XXX
and tdesc_amd64_XXX.
[__x86_64__] (amd64_tdesc_test): New function.
(initialize_low_tdesc) [__x86_64__]: Call init_registers_x32_XXX
and init_registers_amd64_XXX.
* linux-x86-tdesc.c: Include arch/amd64.h.
(xcr0_to_tdesc_idx): New function.
(i386_linux_read_description): New function.
(amd64_get_ipa_tdesc_idx): New function.
* linux-x86-tdesc.h (amd64_get_ipa_tdesc_idx): Declare.
(amd64_get_ipa_tdesc): Declare.
gdb:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* amd64-linux-tdep.c: Include arch/amd64.h. Don't include
features/i386/*.c.
(amd64_linux_read_description): Call
amd64_create_target_description.
* arch/amd64.c: New file.
* arch/amd64.h: New file.
* configure.tgt (x86_64-*-linux*): Append amd64.o.
* Makefile.in (ALL_64_TARGET_OBS): Append amd64.o.
This patch adds a new function amd64_linux_read_description, which
creates amd64-linux target descriptions according to its two
arguments, xcr0 and is_x32.
gdb:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* amd64-linux-tdep.c (amd64_linux_read_description): New
function.
(amd64_linux_core_read_description): Call
amd64_linux_read_description.
(amd64_linux_init_abi): Likewise.
(amd64_x32_linux_init_abi): Likewise.
* amd64-linux-tdep.h (amd64_linux_read_description): Declare.
* x86-linux-nat.c (x86_linux_read_description): Call
amd64_linux_read_description.
