The problem is caused by the fact that gold is relocating the stubs
for an entire output section when it processes the relocations for a
particular input section that happened to be designated as the stub
table "owner". The Relocate_task for that input section may or may not
run before the Relocate_task for another input section that contains
the code that needs the erratum fix, but doesn't "own" the stub
table. If it runs before (or might even race with) that other task, it
ends up with a copy of the unrelocated original instruction.
In other words - when calling fix_errata() from
do_relocate_sections(), gold is going through the list of errata stubs
that are associated only with that object. This routine updates the
stored original instruction and replaces it in the output view with a
branch to the stub. Later, as gold is going through the object file's
input sections, it then checks for stub tables "owned" by each input
section, and writes out all the stubs from that stub table, regardless
of what object file each stub is associated with.
Fixed by relocating the erratum stub only after the corresponding
errata spot is fixed. That is to have fix_errata() call
Stub_table::relocate_erratum_stub() for each stub.
gold/ChangeLog
2017-07-06 Han Shen <shenhan@google.com>
PR gold/21491
* aarch64.cc (Erratum_stub::invalidate_erratum_stub): New method.
(Erratum_stub::is_invalidated_erratum_stub): New method.
(Stub_table::relocate_reloc_stub): Renamed from "relocate_stub".
(Stub_table::relocate_reloc_stubs): Renamed from "relocate_stubs".
(Stub_table::relocate_erratum_stub): New method.
(AArch64_relobj::fix_errata_and_relocate_erratum_stubs): Renamed from
"fix_errata".
(Target_aarch64::relocate_reloc_stub): Renamed from "relocate_stub".
Use ptrace operations to fetch and store the fs_base and gs_base registers
for FreeBSD/amd64 processes. Note that FreeBSD does not currently store the
value of these registers in core dumps, so these registers are only
available when inspecting a running process.
gdb/ChangeLog:
* amd64-bsd-nat.c (amd64bsd_fetch_inferior_registers): Use
PT_GETFSBASE and PT_GETGSBASE.
(amd64bsd_store_inferior_registers): Use PT_SETFSBASE and
PT_SETGSBASE.
On Fedora 26, "g++ -dumpversion" displays "7", instead of "7.1.1".
Update selective.exp to support single digit GCC version. Also
remove duplicated [4-9] version check.
* testsuite/ld-selective/selective.exp: Support single digit
GCC version.
Rationale behind the change instead of adding a `.init$' postfix being
that "initializer for symbol" is much more informative when inspecting D
runtime type information in gdb, which is the only place where you would
encounter references to this compiler-generated symbol.
gdb/testsuite/ChangeLog:
* gdb.dlang/demangle.exp: Update for demangling changes.
This patch supersedes
https://sourceware.org/ml/gdb-patches/2017-07/msg00009.html
---
Patch [1] broke a build on MinGW hosts, because MinGW doesn't provide POSIX
functions setenv () and unsetenv (). This can be fixed by using
implementations from gnulib.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9a6c7d9c0
gdb/ChangeLog
yyyy-mm-dd Anton Kolesov <Anton.Kolesov@synopsys.com>
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add setenv and
unsetenv.
* gnulib/aclocal.m4: Regenerate.
* gnulib/config.in: Regenerate.
* gnulib/configure: Regenerate.
* gnulib/import/Makefile.am: Regenerate.
* gnulib/import/Makefile.in: Regenerate.
* gnulib/import/m4/gnulib-cache.m4: Regenerate.
* gnulib/import/m4/gnulib-comp.m4: Regenerate.
* gnulib/import/m4/environ.m4: New file.
* gnulib/import/m4/setenv.m4: New file.
* gnulib/import/setenv.c: New file.
* gnulib/import/unsetenv.c: New file.
Compiling with clang gives this warning/error:
/home/emaisin/src/binutils-gdb/gdb/compile/compile-loc2c.c:731:6: error: variable 'uoffset' is uninitialized when used here [-Werror,-Wuninitialized]
uoffset += dwarf2_per_cu_text_offset (per_cu);
^~~~~~~
/home/emaisin/src/binutils-gdb/gdb/compile/compile-loc2c.c:669:23: note: initialize the variable 'uoffset' to silence this warning
uint64_t uoffset, reg;
^
= 0
I am really not sure if what this patch does is good, but it is my best
guess. DW_OP_addr means that there's an constant address provided by
the DWARF bytecode that should be pushed on the stack. That address is
considered skipped by the "op_ptr += addr_size", but it is never read.
uoffset is indeed read just after, without having been assigned first.
So I think the intent is to read the address, it was just omitted.
gdb/ChangeLog:
* compile/compile-loc2c.c (do_compile_dwarf_expr_to_c): Read
address when op is DW_OP_addr.
This Rust bug report:
https://github.com/rust-lang/rust/issues/41970
noted an error from gdb. What is happening here (for me, the original
report had a different error) is that a pieced DWARF expression is not
writing to every byte in the resulting value. GDB errors in this
case. However, it seems to me that it is always valid to write fewer
bytes; the issue comes from writing too many -- that is, the test is
reversed. The test was also checking the sub-object, but this also
seems incorrect, as it's expected for the expression to write the
entirety of the enclosing object. So, this patch reverses the test
and applies it to the outer type, not the subobject type.
Regtested on the buildbot.
gdb/ChangeLog
2017-07-09 Tom Tromey <tom@tromey.com>
* dwarf2loc.c (dwarf2_evaluate_loc_desc_full): Reverse size
check and apply to outer type.
gdb/testsuite/ChangeLog
2017-07-09 Tom Tromey <tom@tromey.com>
* gdb.dwarf2/shortpiece.exp: New file.
FreeBSD recently added a new ELF core note which dumps the entire LWP
info structure (the same structure returned by the ptrace PT_LWPINFO
operation) for each thread. The plan is for this note to eventually
supplant the older "thrmisc" ELF core note as it contains more
information and it permits new information to be exported via both
ptrace() and core dumps using the same structure.
For signal information, the implementation is similar to the native
implementation for FreeBSD processes. The PL_FLAG_SI flag must be
checked to determine if the embedded siginfo_t structure is valid, and
if so it is transferred into the caller's buffer.
gdb/ChangeLog:
* fbsd-tdep.c (LWPINFO_OFFSET, LWPINFO_PL_FLAGS)
(LWPINFO64_PL_SIGINFO, LWPINFO32_PL_SIGINFO, PL_FLAG_SI)
(SIZE64_SIGINFO_T, SIZE32_SIGINFO_T, fbsd_core_xfer_siginfo): New.
(fbsd_init_abi): Install gdbarch "core_xfer_siginfo" method.
This core dump note contains the same information returned by the
ptrace PT_LWPINFO operation for each LWP belonging to a process.
binutils/ChangeLog:
* readelf.c (get_freebsd_elfcore_note_type): Handle
NT_FREEBSD_PTLWPINFO.
include/ChangeLog:
* elf/common.h (NT_FREEBSD_PTLWPINFO): Define.
Previously the core_xfer_partial method used core_get_siginfo to handle
TARGET_OBJECT_SIGNAL_INFO requests. However, core_get_siginfo looked for
Linux-specific sections in the core file. To support fetching siginfo
from cores on other systems, add a new gdbarch method (`core_xfer_siginfo`)
and move the body of the existing core_get_siginfo into a
linux_core_xfer_siginfo implementation of this method in linux-tdep.c.
gdb/ChangeLog:
* corelow.c (get_core_siginfo): Remove.
(core_xfer_partial): Use the gdbarch "core_xfer_siginfo" method
instead of get_core_siginfo.
* gdbarch.sh (core_xfer_siginfo): New gdbarch callback.
* gdbarch.h: Re-generate.
* gdbarch.c: Re-generate.
* linux-tdep.c (linux_core_xfer_siginfo): New.
(linux_init_abi): Install gdbarch "core_xfer_siginfo" method.
Use the `pl_siginfo' field in the `struct ptrace_lwpinfo' object returned
by the PT_LWPINFO ptrace() request to supply the current contents of
$_siginfo for each thread. Note that FreeBSD does not supply a way to
modify the signal information for a thread, so $_siginfo is read-only for
FreeBSD.
To handle 32-bit processes on a 64-bit host, define types for 32-bit
compatible siginfo_t and convert the 64-bit siginfo_t to the 32-bit
equivalent when supplying information for a 32-bit process.
gdb/ChangeLog:
* fbsd-nat.c [PT_LWPINFO && __LP64__] (union sigval32)
(struct siginfo32): New.
[PT_LWPINFO] (fbsd_siginfo_size, fbsd_convert_siginfo): New.
(fbsd_xfer_partial) [PT_LWPINFO]: Handle TARGET_OBJECT_SIGNAL_INFO
via ptrace(PT_LWPINFO).
As with Linux architectures, cache the created type in the gdbarch when it
is first created. Currently FreeBSD uses an identical siginfo type on
all architectures, so there is no support for architecture-specific fields.
gdb/ChangeLog:
* fbsd-tdep.c (fbsd_gdbarch_data_handle, struct fbsd_gdbarch_data)
(init_fbsd_gdbarch_data, get_fbsd_gdbarch_data)
(fbsd_get_siginfo_type): New.
(fbsd_init_abi): Install gdbarch "get_siginfo_type" method.
(_initialize_fbsd_tdep): New.
Fix a commit 861fb55ab5 ("Defer allocation of R_MIPS_REL32 GOT
slots"), <https://sourceware.org/ml/binutils/2008-08/msg00096.html>,
regression and a more recent:
FAIL: ld-unique/pr21529
new LD test case failure, observed with all the relevant MIPS targets
whenever the linker is invoked with one or more ELF inputs and the
output format set to `binary'.
The culprit is a segmentation fault caused in `mips_before_allocation'
by a null pointer dereference, where an attempt is made to access the
ELF file header's `e_flags' member, for the purpose of determining
whether to produce a PLT and copy relocations, without first checking
that the output BFD is ELF. The `e_flags' member is stored in BFD's
private data pointed to by `tdep', which in the case of the `binary' BFD
is null, causing the segmentation fault. With other non-ELF BFDs such
as SREC `tdep' is not null and consequently no crash may happen and in
that case random data will be interpreted as it was `e_flags'.
Disable the access to `e_flags' then and all the associated checks and
consequently never produce a PLT and copy relocations if output is not a
MIPS ELF BFD, matching `_bfd_mips_elf_merge_private_bfd_data' that does
not process `e_flags' in that case either and therefore does not let us
decide here anyway if all the input objects included in the link are
suitable for use with a PLT and copy relocations.
ld/
* emultempl/mipself.em (mips_before_allocation): Avoid ELF
processing if not MIPS ELF.
* testsuite/ld-mips-elf/binary.d: New test.
* testsuite/ld-mips-elf/binary.ld: New test linker script.
* testsuite/ld-mips-elf/binary.s: New test source.
* testsuite/ld-mips-elf/mips-elf.exp: Run the new test.
88c1242dc0 changed some generated files rather than the source.
* cgen-dis.in: Include disassemble.h, not dis-asm.h.
* m32c-dis.c: Regenerate.
* mep-dis.c: Regenerate.
In some cases a compiler may produce a single object file (& thus single
DWO file) representing multiple source files. The most common example of
this is in whole program optimization (such as LLVM's LTO). Fission may
still be a beneficial feature to use here - to avoid the need to
read/link the debug info with system libraries and the like.
This change adds basic support for multiple CUs in a single DWO file to
support LLVM's output in this situation.
There is still outstanding work to design and implement a solution for
cross-CU references (usually using DW_FORM_ref_addr) in this scenario.
For now LLVM works around this by duplicating DIEs rather than making
cross-CU references in DWO files. This degrades debugger
behavior/quality especially for file-local entities.
2017-07-06 David Blaikie <dblaikie@gmail.com>
* dwarf2read.c (struct dwo_file): Use a htab of dwo_unit* (rather than
a singular dwo_unit*) to support multiple CUs in the same way that
multiple TUs are supported.
(create_cus_hash_table): Replace create_dwo_cu with a function for
parsing multiple CUs from a DWO file.
(open_and_init_dwo_file): Use create_cus_hash_table rather than
create_dwo_cu.
(lookup_dwo_cutu): Lookup CU in the hash table in the dwo_file with
htab_find, rather than comparing the signature to a singleton CU in
the dwo_file.
2017-07-06 David Blaikie <dblaikie@gmail.com>
* gdb.dwarf2/fission-multi-cu.S: Test containing multiple CUs in a DWO,
built from fissiont-multi-cu{1,2}.c.
* gdb.dwarf2/fission-multi-cu.exp: Test similar to fission-base.exp,
except putting 'main' and 'func' in separate CUs in the same DWO file.
* gdb.dwarf2/fission-multi-cu1.c: First CU for the multi-CU-single-DWO
test.
* gdb.dwarf2/fission-multi-cu2.c: Second CU in the multi-CU-single-DWO
test.
When setting wide_width to 1, convert 'L' to 'l'. Otherwise, %Lx/%Lu/%Ld
will be passed to fprintf which will treat the argument as long long.
* bfd.c (_doprnt): Convert 'L' to 'l' when setting wide_width
to 1.
The gdb.python/py-unwind.exp test is crashing GDB / leaving core dumps
in the test dir, even though it all passes cleanly. The crash is not
visible in gdb.sum/gdb.log because it happens as side effect of the
"quit" command, while flushing the frame cache.
The problem is simply a typo in a 'for' loop's condition, introduced
by a recent change [4fa847d78e ("Remove MAX_REGISTER_SIZE from
py-unwind.c")], resulting in infinite loop / double-free.
The new test exposes the crash, like:
Running src/gdb/testsuite/gdb.python/py-unwind.exp ...
ERROR: Process no longer exists
gdb/ChangeLog:
2017-07-06 Pedro Alves <palves@redhat.com>
* python/py-unwind.c (pyuw_dealloc_cache): Fix for loop condition.
gdb/testsuite/ChangeLog:
2017-07-06 Pedro Alves <palves@redhat.com>
* gdb.python/py-unwind.exp: Test flushregs.
Fix GCC 4.2 warnings like:
cc1: warnings being treated as errors
binutils-gdb/bfd/dwarf2.c:1844: warning: declaration of ‘time’ shadows a global declaration
/usr/include/time.h:187: warning: shadowed declaration is here
binutils-gdb/bfd/dwarf2.c: In function ‘line_info_add_file_name’:
binutils-gdb/bfd/dwarf2.c:1854: warning: declaration of ‘time’ shadows a global declaration
/usr/include/time.h:187: warning: shadowed declaration is here
bfd/
* dwarf2.c (line_info_add_include_dir_stub): Replace time with
xtime.
(line_info_add_file_name): Likewise.
(decode_line_info): Likewise.
binutils/
* dwarf.c (display_debug_names): Replace index with xindex.
This patch adds support for the ARM Cortex-A55 and
Cortex-A75 processors.
The ARM Cortex-A55 and Cortex-A75 procsessors implement the ARMv8-A
architecture, with support for the ARMv8.1-A and ARMv8.2-A extensions,
including support for the 16-bit floating point extensions.
The 16-bit floating-point extensions are optional, and we haven't defined
an option mapping straight to them thus far, so this patch first needs to
add one of those in include/opcode/arm.h, then we can simply add the CPU names
as usual in config/tc-arm.c .
Tested on arm-none-eabi.
2017-07-05 James Greenhalgh <james.greenhalgh@arm.com>
* config/tc-arm.c (arm_cpus): Add Cortex-A55 and Cortex-A75.
* doc/c-arm.texi (-mcpu): Document Cortex-A55 and Cortex-A75.
The instructions are not documented in the Intel SDM but are documented
in the AMD APM as an alias to the group 2, ModRM.reg == 4 variant.
Both AMD and Intel CPUs execute the C[0-1] and D[0-3] instructions as
expected, i.e., like the /4 aliases:
#include <stdio.h>
int main(void)
{
int a = 2;
printf ("a before: %d\n", a);
asm volatile(".byte 0xd0,0xf0" /* SHL %al */
: "+a" (a));
printf("a after : %d\n", a);
return 0;
}
$ ./a.out
a before: 2
a after : 4
This patch adds support mvfr2 control registers for armv8-a as
this was missed from the original port to armv8-a (documented
at G6.2.109 in (Issue B.a) of the ARM-ARM. This was discovered
by an internal user of the GNU toolchain.
I'd like to backport this to the binutils 2.28 and binutils 2.29
release branch if possible (with suitable testing and basically
checking removing the armv8-r parts).
Tristan - are you ok with the backports ?
Applied to trunk.
regards Ramana
2017-07-04 Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
* gas/config/tc-arm.c (arm_regs): Add MVFR2.
(do_vmrs): Constraint for MVFR2 and armv8.
(do_vmsr): Likewise.
* gas/testsuite/gas/arm/armv8-a+fp.d: Update.
* gas/testsuite/gas/arm/armv8-ar+fp.s: Likewise.
* gas/testsuite/gas/arm/armv8-r+fp.d: Likewise.
* gas/testsuite/gas/arm/vfp-bad.s: Likewise.
* gas/testsuite/gas/arm/vfp-bad.l: Likewise.
* opcodes/arm-dis.c: Support MVFR2 in disassembly
with vmrs and vmsr.
