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.
The outer caller elf_link_output_extsym in elflink.c is a traverse function on
all external symbol, and it will only call *finish_dynamic_symbol if some
conditions is meet. It is executed conditionally.
If the condition to trigger that assertion is satisified, it then won't satify
the outer check in finish_dynamic_symbol, so *finish_dynamic_symbol won't be
called that the assertion is expected to be dead code.
If elf_link_output_extsym is a traverse function that unconditionally called
on external symbols decided to be exported, then an assertion to make sure these
symbols are in sane status might make sense.
bfd/
* elfnn-aarch64.c (elfNN_aarch64_finish_dynamic_symbol): Remove the
sanity check at the head of this function.
bfd/ChangeLog:
2017-07-03 Egeyar Bagcioglu <egeyar.bagcioglu@oracle.com>
* elfxx-sparc.c (_bfd_sparc_elf_finish_dynamic_symbol): Remove the
abort statement that was put for symbols that are not dynamic.
This reverts most of 0680331375, 2005-07-05 Dmitry V. Levin change
adding a check that section size doesn't exceed file size. As we've
seen recently with mmo tests, decoded section size can easily exceed
file size with formats that encode section data.
I've also changed "strings" to use bfd_malloc_and_get_section, so that
"strings" won't die on a malloc failure. I think it's better to
continue on looking at other sections after failing to dump a section
with fuzzed size.
The testcases at https://bugzilla.altlinux.org/show_bug.cgi?id=5871
on a 32-bit host now produce
$ strings -d --target=a.out-i386 /tmp/bfdkiller.dat
strings: error: /tmp/bfdkiller.dat(.text) is too large (0xffffffff bytes)
strings: /tmp/bfdkiller.dat: Reading section .text failed: Memory exhausted
strings: /tmp/bfdkiller.dat: Reading section .data failed: File truncated
org.ec
$ strings -d --target=a.out-i386 /tmp/eclipse-state
strings: /tmp/eclipse-state: Reading section .text failed: File truncated
org.eclipse.osgi
System Bundle
[snip]
* strings.c (filename_and_size_t): Delete.
(strings_a_section): Don't check section size against file size.
Use bdf_malloc_and_get_section. Report an error on failures.
Replace arg param with filename and got_a_section param.
(got_a_section): Move to..
(strings_object_file): ..an auto var here. Iterate over sections
rather than calling bfd_map_over_sections. Adjust strings_a_section
call.
One way to print 64-bit bfd_vma or bfd_size_type values on 32-bit
hosts is to cast the value to long long and use the 'll' modifier in
printf format strings. However, that's awkward because we also
support the Microsoft C library printf that uses 'I64' as a modifier
instead, and having variants of translated strings would not endear us
to the translation project. So, rewrite the 'll' modifier in
_doprint for Microsoft. Even with that capability it's not so nice
for 32-bit code to need casts to long long, so this patch makes 'L' a
modifier for bfd_vma rather than an alias for 'll'.
I've then used the new 'L' modifier to fix selected format strings.
* bfd.c (_doprnt): Rewrite "ll" and "L" modifiers to "I64" for
__MSVCRT__. Support "L" modifier for bfd_vma. Formatting.
* elf.c (setup_group): Use "Lx" to print sh_size.
(_bfd_elf_setup_sections): Remove unnecessary cast and print
unknown section type in hex.
(copy_special_section_fields): Style fix.
(bfd_section_from_shdr): Correct format for sh_link. Use a
common error message for all the variants of unrecognized
section types.
(assign_file_positions_for_load_sections): Use "Lx" for lma
adjust error message.
(assign_file_positions_for_non_load_sections): Formatting.
(rewrite_elf_program_header): Formatting. Use "Lx" for
bfd_vma values in error messages.
* elfcode.h (elf_slurp_reloc_table_from_section): Cast
ELF_R_SYM value to type expected by format.
* elflink.c (elf_link_read_relocs_from_section): Use "Lx"
in error messages.
(elf_link_add_object_symbols): Use "Lu" for symbol sizes.
(elf_link_input_bfd): Use "Lx" for r_info.
(bfd_elf_gc_record_vtinherit): Use "Lx" for offset.
long long isn't supposed to be used without a configure test, to
support ancient compilers. Probably not terribly important nowadays.
* bfd.c (bfd_scan_vma): Don't use long long unless HAVE_LONG_LONG.
* coff-rs6000.c (FMT20): Handle hosts with 64-bit long and
Microsoft C library variant of long long format specifier.
(PRINT20): Cast value to bfd_uint64_t not long long.
* coffcode.h (coff_print_aux): Use BFD_VMA_FMT.
* coff-x86_64.c (coff_amd64_reloc): Use bfd_uint64_t rather than
long long. Don't cast to bfd_vma.
* elf32-score.c (score3_bfd_getl48): Likewise.
* vms-alpha.c (_bfd_vms_slurp_eisd): Likewise.
This function uses HAVE_LONG_LONG and HAVE_LONG_DOUBLE
* configure.ac: Invoke AC_CHECK_TYPES for long long. Invoke
AC_TYPE_LONG_DOUBLE.
* configure: Regenerate.
* config.in: Regenerate.
GDB Administrator
Anton Kolesov
Nick Clifton
Yao Qi
Jan Kratochvil
Simon Marchi
Tom Tromey
John Baldwin
Maciej W. Rozycki
Alan Modra
David Blaikie
H.J. Lu
Pedro Alves
James Greenhalgh
Borislav Petkov
Ramana Radhakrishnan
Tristan Gingold
Jiong Wang
Egeyar Bagcioglu
Tristan Gingold