PyFile_FromString and PyFile_AsFile have been removed in Python 3.
There is no obvious replacement that works here, and we can't just
pass our FILE* to a DLL in Windows because it may use a different
C runtime.
So we just call a Python function which reads and executes file
contents. Care must be taken to execute it in the context of
__main__.
Tested by inverting the ifdef and running the testsuite on Debian
Linux (even without the patch, I failed at running the testsuite
on Windows). I did test with both Python 2 and 3.
gdb/ChangeLog:
2019-08-22 Christian Biesinger <cbiesinger@google.com>
* python/lib/gdb/__init__.py (_execute_file): New function.
* python/python.c (python_run_simple_file): Call gdb._execute_file
on Windows.
Tom de Vries [Thu, 22 Aug 2019 14:54:59 +0000 (16:54 +0200)]
[gdb/testsuite] Make gdb_test message more informative in multi-term-settings.exp
This racy fail message, reported in PR24929:
...
FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: \
stop with control-c
...
does not make clear which gdb_test fails here:
...
if {$expect_ttou} {
gdb_test "" "Quit" "stop with control-c"
} else {
gdb_test "" "received signal SIGINT.*" "stop with control-c"
}
...
Fix this by making the gdb_test message argument more informative.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-22 Tom de Vries <tdevries@suse.de>
* gdb.multi/multi-term-settings.exp (coretest): Make gdb_test messages
more informative.
Dennis Zhang [Thu, 22 Aug 2019 14:21:32 +0000 (15:21 +0100)]
Arm: Add support for missing CPUs
This patch adds support for following CPUs:
Cortex-M35P, Cortex-A77, Cortex-A76AE.
Related specifications can be found at https://developer.arm.com/ip-products/processors.
gas/ChangeLog:
* config/tc-arm.c: New entries for Cortex-M35P, Cortex-A77,
and Cortex-A76AE.
* doc/c-arm.texi: Document new processors.
* testsuite/gas/arm/cpu-cortex-a76ae.d: New test.
* testsuite/gas/arm/cpu-cortex-a77.d: New test.
* testsuite/gas/arm/cpu-cortex-m35p.d: New test.
bfd/ChangeLog:
* cpu-arm.c: New entries for Cortex-M35P, Cortex-A77, Cortex-A76AE.
Bosco Garc?a [Thu, 22 Aug 2019 11:54:06 +0000 (12:54 +0100)]
Fix the assembler's floating point number parser so that it can correctly handle numbers encoded as a leading decimal point, followed by zeroes, followed by a non-zero sequence.
* atof-generic.c (atof_generic): Do not ignore leading zeros if
they appear after a decimal point.
* testsuite/gas/all/float.s: Extend test to include a number with
a leading decimal point followed by several zeroes.
* testsuite/gas/i386/fp.s: Likewise.
* testsuite/gas/i386/fp.d: Update expected output.
Andrew Burgess [Thu, 22 Aug 2019 09:07:00 +0000 (10:07 +0100)]
gdb/fortran: Remove some dead code from the parser
The Fortran parser contains some code that looks like it was probably
inherited from the C/C++ parser as it checks to see if the current
language is C++, which should never be true when we're in the Fortran
parser.
gdb/ChangeLog:
* f-exp.y (yylex): Remove is_a_field_of_this local variable, and
all uses as this was never set to anything but a zero value.
Tamar Christina [Thu, 22 Aug 2019 10:35:35 +0000 (11:35 +0100)]
AArch64: Fix LD crash on weak and undefined TLS symbols. (PR/24602).
This patch fixes a few linker crashes due to TLS code reaching an assert when it
shouldn't.
The first scenario is with weak TLS symbols that remain weak during linking. In
this case the mid-end would not have seen a TLS symbol and so wouldn't have
allocated the TLS section. We currently assert here and the linker crashes with
a not very useful message.
This patch changes this to return the value 0 for the TLS symbol in question
emulating what lld and gold and other BFD targets do. However because weak TLS
is implementation defined and we don't define any behavior for it I also emit a
warning to the user to inform them of such.
Secondly when a strong TLS reference is undefined. The linker crashes even after
it correctly reported that there is an undefined reference. This changes it so
that it gracefully exits and reports a useful error.
bfd/ChangeLog:
PR ld/24601
* elfnn-aarch64.c (aarch64_relocate): Handle weak TLS and undefined TLS.
Also Pass input_bfd to _bfd_aarch64_elf_resolve_relocation.
* elfxx-aarch64.c (_bfd_aarch64_elf_resolve_relocation): Use it.
* elfxx-aarch64.h (_bfd_aarch64_elf_resolve_relocation): Emit warning
for weak TLS.
ld/ChangeLog:
PR ld/24601
* testsuite/ld-aarch64/aarch64-elf.exp (undef-tls, weak-tls): New.
* testsuite/ld-aarch64/undef-tls.d: New test.
* testsuite/ld-aarch64/undef-tls.s: New test.
* testsuite/ld-aarch64/weak-tls.d: New test.
* testsuite/ld-aarch64/weak-tls.s: New test.
The floats will always be encoded using the binary16 format as described in the
IEEE 754-2008 standard. There is no need to support Arm's alternative half-precision
format since AArch64 only supports the IEEE format.
gas * config/tc-aarch64.c: Add float16 directive and add "Hh" to
acceptable float characters.
* doc/c-aarch64.texi: Documentation for float16 directive.
* testsuite/gas/aarch64/float16-be.d: New test.
* testsuite/gas/aarch64/float16-le.d: New test.
* testsuite/gas/aarch64/float16.s: New test.
* NEWS: Add NEWS entry.
Kyrylo Tkachov [Thu, 22 Aug 2019 09:20:01 +0000 (10:20 +0100)]
[AArch64][gas] Update MTE system register encodings
The MTE specification adjusted the encoding of the TFSRE0_EL1, TFSR_EL1, TFSR_EL2, TFSR_EL3, TFSR_EL12 system registers.
This patch brings binutils up to date.
The references for the encodings are at:
https://developer.arm.com/docs/ddi0595/latest/aarch64-system-registers/tfsre0_el1 (also contains TFSR_EL12 description)
https://developer.arm.com/docs/ddi0595/latest/aarch64-system-registers/tfsr_el1
https://developer.arm.com/docs/ddi0595/latest/aarch64-system-registers/tfsr_el2
https://developer.arm.com/docs/ddi0595/latest/aarch64-system-registers/tfsr_el3
Tested check-gas for aarch64-none-elf.
opcodes/
* aarch64-opc.c (aarch64_sys_regs): Update encoding of tfsre0_el1,
tfsr_el1, tfsr_el2, tfsr_el3, tfsr_el12.
(aarch64_sys_reg_supported_p): Update checks for the above.
gas/
* testsuite/gas/aarch64/sysreg-4.d: Update expected disassembly for
tfsre0_el1, tfsr_el1, tfsr_el2, tfsr_el3, tfsr_el12 system registers.
Alan Modra [Thu, 22 Aug 2019 01:51:48 +0000 (11:21 +0930)]
ARM CMSE symbols
This patch removes use of st_target_internal to cache the result of
comparing symbol names against CMSE_PREFIX. The problem with setting
a bit in st_target_internal in swap_symbol_in is that calling
bfd_elf_sym_name from swap_symbol_in requires symtab_hdr, and you
don't know for sure whether swap_symbol_in is operating on dynsyms
(and thus elf_tdata (abfd)->dynsymtab_hdr should be used) or on the
normal symtab (thus elf_tdata (abfd)->symtab_hdr). You can make an
educated guess based on abfd->flags & DYNAMIC but that relies on
knowing a lot about calls to bfd_elf_get_elf_syms, and is fragile in
the face of possible future changes.
include/
* elf/arm.h (ARM_GET_SYM_CMSE_SPCL, ARM_SET_SYM_CMSE_SPCL): Delete.
bfd/
* elf32-arm.c (cmse_scan): Don't use ARM_GET_SYM_CMSE_SPCL,
instead recognize CMSE_PREFIX in symbol name.
(elf32_arm_gc_mark_extra_sections): Likewise.
(elf32_arm_filter_cmse_symbols): Don't test ARM_GET_SYM_CMSE_SPCL.
(elf32_arm_swap_symbol_in): Don't invoke ARM_SET_SYM_CMSE_SPCL.
Jinke Fan [Wed, 15 May 2019 09:34:57 +0000 (17:34 +0800)]
gdb/djgpp: Add Hygon Dhyana processor support
Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture between
AMD and Haiguang Information Technology Co.,Ltd., which aims at
providing high performance x86 processors for the China server market.
Its first generation processor codename is Dhyana, which originates
from AMD technology and shares most of the architecture with AMD's
family 17h, but with different CPU Vendor ID("HygonGenuine")/Family
series number(Family 18h).
gdb/ChangeLog:
2019-08-21 Jinke Fan <fanjinke51@yeah.net>
Tom de Vries [Wed, 21 Aug 2019 09:49:33 +0000 (11:49 +0200)]
[gdb/testsuite] Stabilize gdb-caching-proc.exp test order
The test-case gdb-caching-proc.exp tests each gdb_caching_proc in
gdb/testsuite/lib/*.exp. However, the order of .exp file being tested can
change from run to run, because of using glob.
Tom Tromey [Sat, 13 Jul 2019 22:47:31 +0000 (16:47 -0600)]
Change tui_make_window to be a method
I combined several small changes into one patch here. I believe I
started by noticing that the "title" is not needed by tui_gen_win_info
and could be self-managing (i.e. std::string). Moving this revealed
that "can_box" is also a property of tui_win_info and not
tui_gen_win_info; and this in turn caused the changes to
tui_make_window and box_win.
Tom Tromey [Sat, 13 Jul 2019 22:36:07 +0000 (16:36 -0600)]
Remove tui_data_window::display_regs
There's no need for tui_data_window::display_regs any more (if there
ever was). All the paths through data window construction will end up
setting this to true. This patch removes the member.
Tom Tromey [Sat, 13 Jul 2019 22:24:48 +0000 (16:24 -0600)]
Remove indirection from tui_data_window::regs_content
tui_data_window::regs_content is currently a vector of unique_ptr.
However, due to the way this is managed now, there is no need to keep
the pointers -- it can simply be a vector of the objects themselves.
This patch removes this extra layer of indirection.
Tom Tromey [Sat, 13 Jul 2019 22:15:30 +0000 (16:15 -0600)]
Change tui_check_register_values to be a method
This changes tui_check_register_values to be a method on
tui_data_window. An additional check in tui_register_changed is
needed, because TUI_DATA_WIN could be NULL at this point.
Tom Tromey [Sat, 13 Jul 2019 22:01:34 +0000 (16:01 -0600)]
Change tui_data_item_window::content to be a unique_xmalloc_ptr
This changes tui_data_item_window::content to be a unique_xmalloc_ptr
and fixes up the fallout. It also removes a parameter from
tui_expand_tabs, as it was only ever given one value.
This also removes some tab-handling code from
tui_data_window::display_registers_from. Because the content can only
be set by tui_register_format, and because that calls tui_expand_tabs,
it's not possible to see a tab here.
gdb/ChangeLog
2019-08-20 Tom Tromey <tom@tromey.com>
* tui/tui-regs.h (struct tui_data_item_window)
<~tui_data_item_window>: Remove.
<content>: Now a unique_xmalloc_ptr.
* tui/tui-regs.c (tui_register_format): Return a
unique_xmalloc_ptr.
(tui_get_register): Update.
(~tui_data_item_window): Remove.
(tui_data_window::display_registers_from, tui_display_register):
Update.
* tui/tui-io.h (tui_expand_tabs): Update.
* tui/tui-io.c (tui_expand_tabs): Return a unique_xmalloc_ptr.
Remove "col" parameter.
Tom Tromey [Sat, 13 Jul 2019 21:55:02 +0000 (15:55 -0600)]
Minor rearrangement in tui-regs.c
This moves a couple of functions earlier in tui-regs.c. Previously
they were in the "command" section of the file, but really they belong
in the "window implementation" section.
gdb/ChangeLog
2019-08-20 Tom Tromey <tom@tromey.com>
Tom Tromey [Sat, 13 Jul 2019 21:45:14 +0000 (15:45 -0600)]
Some i18n fixes for the TUI
The TUI has a few #defines that hold user-visible strings. As these
are only used in a single spot, this patch removes the defines,
preferring direct use of the string where needed. Furthermore, now
the strings are wrapped in _(), which is friendlier for i18n purposes.
gdb/ChangeLog
2019-08-20 Tom Tromey <tom@tromey.com>
Dennis Zhang [Tue, 20 Aug 2019 16:13:29 +0000 (17:13 +0100)]
Adds support for following CPUs to the ARM and Aarch64 assemblers: Cortex-A77, Cortex-A76AE, Cortex-A34, Cortex-A65, and Cortex-A65AE.
Related specifications can be found at
https://developer.arm.com/ip-products/processors.
gas * NEWS: Mention the Arm and AArch64 new processors.
* config/tc-aarch64.c: New entries for Cortex-A34, Cortex-A65,
Cortex-A77, cortex-A65AE, and Cortex-A76AE.
* doc/c-aarch64.texi: Document new CPUs.
* testsuite/gas/aarch64/cpu-cortex-a34.d: New test.
* testsuite/gas/aarch64/cpu-cortex-a65.d: New test.
* testsuite/gas/aarch64/cpu-cortex-a65ae.d: New test.
* testsuite/gas/aarch64/cpu-cortex-a76ae.d: New test.
* testsuite/gas/aarch64/cpu-cortex-a77.d: New test.
* testsuite/gas/aarch64/nop-asm.s: New test.
bfd * cpu-aarch64.c: New entries for Cortex-A34, Cortex-A65,
Cortex-A77, cortex-A65AE, and Cortex-A76AE.
Tamar Christina [Tue, 20 Aug 2019 15:34:26 +0000 (16:34 +0100)]
Arm: Fix performance issue with thumb-2 tailcalls
We currently use a padding NOP after a Thumb to Arm interworking veneer (BX pc).
The NOP is never executed but may result in a performance penalty on some cores.
For this reason this patch changes the NOPs after Thumb to Arm veneers into B .-2
and adds a note to this in the source code for future reference.
bfd/ChangeLog:
* elf32-arm.c (elf32_thumb2_plt_entry, elf32_arm_plt_thumb_stub,
elf32_arm_stub_long_branch_v4t_thumb_thumb,
elf32_arm_stub_long_branch_v4t_thumb_arm,
elf32_arm_stub_short_branch_v4t_thumb_arm,
elf32_arm_stub_long_branch_v4t_thumb_arm_pic,
elf32_arm_stub_long_branch_v4t_thumb_thumb_pic,
elf32_arm_stub_long_branch_v4t_thumb_tls_pic): Change nop to branch to
previous instruction.
Tom de Vries [Tue, 20 Aug 2019 15:18:09 +0000 (17:18 +0200)]
[gdb/testsuite] Clean up stale exec in gdb_compile_pascal
When running a pascal test with the stabs target board:
...
$ test=gdb.pascal/case-insensitive-symbols.exp
$ cd build/gdb/testsuite
$ make check RUNTESTFLAGS="$test --target_board=stabs"
...
we get:
...
nr of untested testcases 1
nr of unsupported tests 1
...
due to:
...
Error: Illegal parameter: -gstabs+^M
Error: /usr/bin/ppcx64 returned an error exitcode^M
...
OTOH, when running the same pascal test without the stabs target board:
...
$ make check RUNTESTFLAGS="$test"
...
we get:
...
nr of expected passes 20
...
But when subsequently again running with the stabs target board:
...
$ make check RUNTESTFLAGS="$test --target_board=stabs"
...
we now get:
...
nr of expected passes 20
...
The problem is that gdb_compile_pascal determines success based on existence
of the exec after compilation:
...
if ![file exists $destfile] {
unsupported "Pascal compilation failed: $result"
return "Pascal compilation failed."
}
...
without removing the exec before compilation, which allows a stale exec to
make it seem as if compilation has succeeded.
Fix this by removing the stale exec before compilation.
gdb/testsuite/ChangeLog:
2019-08-20 Tom de Vries <tdevries@suse.de>
* lib/pascal.exp (gdb_compile_pascal): Remove $destfile before
compilation.
Conrad Meyer [Mon, 19 Aug 2019 07:02:19 +0000 (00:02 -0700)]
Improve remote attach round-trips without btrace
For remotes which do not support btrace at all, we can save several
round trips for each thread. This is especially significant when your
remote is a kernel with 100s or 1000s of threads and latency is
intercontinental.
Previously, with target, remote, and infrun debugging enabled, one
might see:
MIPS/gas: Retain ISA mode bit for labels with .insn annotation
gas/
* config/tc-mips.c (mips_move_labels): Retain ISA mode bit
when moving labels in text segments.
(mips_align): Indicate text mode when aligning labels in
text segments.
* gas/testsuite/gas/mips/insn-isa-mode.d: New test.
* gas/testsuite/gas/mips/insn-isa-mode.s: New test source.
* gas/testsuite/gas/mips/mips.exp: Run the new test.
Tom Tromey [Tue, 13 Aug 2019 17:39:58 +0000 (11:39 -0600)]
Fix Fortran regression with variables in nested functions
Sergio pointed out that commit commit aa3b6533 ("Allow nested function
displays") regressed a few gdb.fortran tests. I was able to reproduce
these failures with gcc head.
The bug is that some spots calling contained_in will in fact do the
wrong thing if nested functions are considered as contained. In the
particular case of the Fortran regression, it was the call in
block_innermost_frame, being called from get_hosting_frame -- in this
case, the caller is specifically trying to avoid the nested case.
This patch fixes the problem by adding an "allow_nested" parameter to
contained_in, essentially reverting the change for most callers.
gdb/ChangeLog
2019-08-19 Tom Tromey <tromey@adacore.com>
Tom Tromey [Mon, 24 Jun 2019 22:02:47 +0000 (16:02 -0600)]
Add Rust support to source highlighting
Currently, no release of GNU Source Highlight supports Rust. However,
I've checked in a patch to do so there, and I plan to make a new
release sometime this summer.
This patch prepares gdb for that by adding support for Rust to the
source highlighting code.
Because Source Highlight will throw an exception if the language is
unrecognized, this also changes gdb to ignore exceptions here. This
will cause gdb to fall back to un-highlighted source text.
This updates gdb's configure script to reject the combination of
Source Highlight and -static-libstdc++. This is done because it's not
possible to use -static-libstdc++ and then catch exceptions from a
shared library.
Tested with the current and development versions of Source Highlight.
gdb/ChangeLog
2019-08-19 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* configure.ac: Disallow the combination of -static-libstdc++ and
source highlight.
* source-cache.c (get_language_name): Handle rust.
(source_cache::get_source_lines): Ignore highlighting exceptions.
Tom Tromey [Fri, 26 Jul 2019 21:42:25 +0000 (15:42 -0600)]
Add --with-static-standard-libraries to the top level
gdb should normally not be linked with -static-libstdc++. Currently
this has not caused problems, but it's incompatible with catching an
exception thrown from a shared library -- and a subsequent patch
changes gdb to do just this.
This patch adds a new --with-static-standard-libraries flag to the
top-level configure. It defaults to "auto", which means enabled if
gcc is being built, and disabled otherwise.
Tom Tromey [Thu, 15 Aug 2019 13:33:20 +0000 (07:33 -0600)]
Fix N^2 behavior in _bfd_dwarf2_find_symbol_bias
A customer reported a case where addr2line was very slow. We tracked
this down to some N^2 behavior in _bfd_dwarf2_find_symbol_bias in the
unusual case where no function can be found.
This patch fixes the bug, and reduces the runtime for a particular
request from 127 seconds to 1 second.
bfd/ChangeLog
2019-08-19 Tom Tromey <tromey@adacore.com>
Alan Modra [Mon, 19 Aug 2019 10:54:35 +0000 (20:24 +0930)]
PR24898, An out-of-bounds read occured in display_data
Given 32-bit pointers and a 64-bit bfd_size_type, it is relatively
easy to construct a value of augmentation_data_len (eg. 0x100000000)
that won't fail pointer checks but will print without bounds.
PR 24898
* dwarf.c (display_debug_frames): Use the read_cie check and error
for augmentation data length.
Alan Modra [Mon, 19 Aug 2019 08:04:03 +0000 (17:34 +0930)]
PowerPC64 ha/lo insn checks
These are done in ppc64_elf_edit_toc, which now also garbage collects
unused GOT entries. The checks for legitimate instructions weren't
being done for the GOT relocs, unless the file also happened to have a
toc section.
* elf64-ppc.c (struct ppc64_elf_obj_tdata): Rename has_gotrel
to has_optrel.
(struct _ppc64_elf_section_data): Likewise.
(ppc64_elf_check_relocs): Set has_optrel for more relocs.
(ppc64_elf_edit_toc): Do ha/lo insn checks in GOT loop rather
than TOC loop. Check PLT16 insns too.
Barnaby Wilks [Thu, 15 Aug 2019 16:21:59 +0000 (16:21 +0000)]
Float16: Fix test failures for non ELF targets
The tests were failing due to md_atof trying to do word-wise endian
switching on the float16 (for little-endian targets sometimes
multi word values have their word order changed).
However since a float16 is only 1 word wide, it would end up writing
incorrect data, as you cannot switch the word order of just one word.
Tom de Vries [Fri, 16 Aug 2019 21:48:28 +0000 (23:48 +0200)]
[gdb/testsuite] Fix compare-sections.exp with -fPIE/-pie
When running gdb.base/compare-sections.exp with target board -fPIE/-pie, we
get:
...
FAIL: gdb.base/compare-sections.exp: after run to main: compare-sections -r
...
The test expects the read-only sections to have the same contents as in the
file:
...
# Assume startup code doesn't change read-only sections.
compare_sections "-r"
...
but that's not the case for PIE executables.
Fix this by allowing mismatched read-only sections for PIE executables.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-16 Tom de Vries <tdevries@suse.de>
* gdb.base/compare-sections.exp ("after run to main"): Allow
mismatched read-only sections for PIE executables.
x86-64: Restore PIC check for PCREL reloc against protected symbol
moved PIC check for PC-relative relocations to elf_x86_64_check_relocs.
Since linker defined symbols may not be processed at the time, we need
to move the check back to elf_x86_64_relocate_section.
bfd/
PR ld/24905
* elf64-x86-64.c (elf_x86_64_check_relocs): Move PIC check for
PC-relative relocations back to ...
(elf_x86_64_relocate_section): Here.
ld/
PR ld/24905
* testsuite/ld-x86-64/pr24905-x32.d: New file.
* testsuite/ld-x86-64/pr24905.d: Likewise.
* testsuite/ld-x86-64/pr24905.s: Likewise.
* testsuite/ld-x86-64/pr24905.t: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run pr24905 and pr24905-x32.
Tom Tromey [Sat, 13 Jul 2019 00:18:10 +0000 (18:18 -0600)]
Remove the TUI execution info window
The TUI execution info window is unusual in that it is always linked
to a source or disassembly window. Even updates of its content are
handled by the source window, so it really has no life of its own.
This patch removes this window entirely and puts its functionality
directly into the source window. This simplifies the code somewhat.
This is a user-visible change, because now the box around the source
(or disassembly) window encloses the execution info as well. I
consider this an improvement as well, though.
Note that this patch caused ncurses to start emitting the "CSI Z"
sequence, so I've added this to the test suite terminal
implementation.
gdb/ChangeLog
2019-08-16 Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 12 Jul 2019 00:19:28 +0000 (18:19 -0600)]
Remove "noerror" parameter from some TUI functions
A few TUI functions take a "noerror" parameter. This is only checked
in one spot: in tui_set_source_content, if noerror is false, and if an
error occurs, then the function will call print_sys_errmsg.
This seems misguided to me, so this patch removes that code and this
parameter.
gdb/ChangeLog
2019-08-16 Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 12 Jul 2019 00:03:45 +0000 (18:03 -0600)]
Remove separate visibility flag
TUI windows keep track of their visibility in a boolean field.
However, this is not needed, because a window is visible if and only
if it has an underlying curses handle. So, we can remove this
separate field.
gdb/ChangeLog
2019-08-16 Tom Tromey <tom@tromey.com>
Martin Liska [Fri, 16 Aug 2019 11:14:36 +0000 (13:14 +0200)]
Fix detection of missing plugin for LTO objects.
2019-08-16 Martin Liska <mliska@suse.cz>
PR ld/24912
* elflink.c: Report error only for not relocatable.
* linker.c (_bfd_generic_link_add_one_symbol): Do not handle
here lto_slim_object as it's handled in caller.
2019-08-16 Martin Liska <mliska@suse.cz>
PR ld/24912
* object.cc (big_endian>::do_layout): Do not report error,
but only set a flag.
(big_endian>::do_add_symbols): Report error only for when
relocatable.
Alan Hayward [Fri, 16 Aug 2019 09:19:18 +0000 (10:19 +0100)]
Move [PAC] into a new MI field addr_flags
Add a new print_pc which prints both the PC and a new field addr_flags.
Call this wherever the PC is printed in stack.c.
Add a new gdbarch method get_pc_address_flags to obtain the addr_flag
contents. By default returns an empty string, on AArch64 this returns
PAC if the address has been masked in the frame.
Document this in the manual and NEWS file.
gdb/ChangeLog:
* NEWS (Other MI changes): New subsection.
* aarch64-tdep.c (aarch64_get_pc_address_flags): New function.
(aarch64_gdbarch_init): Add aarch64_get_pc_address_flags.
* arch-utils.c (default_get_pc_address_flags): New function.
* arch-utils.h (default_get_pc_address_flags): New declaration.
* gdbarch.sh: Add get_pc_address_flags.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* stack.c (print_pc): New function.
(print_frame_info) (print_frame): Call print_pc.
Alan Modra [Fri, 16 Aug 2019 03:50:28 +0000 (13:20 +0930)]
PowerPC gcc bootstrap fail with bss-plt
git commit 3e04d7655b introduced a bug by sizing output sections
earlier in ppc_before_allocation. That meant PLT (and GOT) sizes were
not included when calculating total executable section sizes.
* emultempl/ppc32elf.em (ppc_before_allocation): Force running
prelim_size_sections before deciding whether branch trampolines
might be needed.
Alan Modra [Wed, 14 Aug 2019 07:01:05 +0000 (16:31 +0930)]
Aligned vs. unaligned ppc32 relocs
Given R_PPC_ADDR32 or R_PPC_UADDR32 relocs, this patch generates
R_PPC_ADDR32 or R_PPC_UADDR32 dynamic relocs from either type
depending on whether r_offset is 4-byte aligned, and similarly for
R_PPC_ADDR16/R_PPC_UADDR16.
Sandra Loosemore [Fri, 16 Aug 2019 01:15:16 +0000 (18:15 -0700)]
Fix paste-o in examine-backward.exp.
This patch fixes a paste-o that was introduced in commit c8ad9b9a31aa3e6039567fc1f152dd454c946d5f. Previously the regexp for
the "examine 3 bytes backward from ${address_zero}" test correctly
matched 3 "${byte}" patterns, but in that commit the 6-byte regexp
from the previous test was mistakenly repeated here instead.
Tom de Vries [Thu, 15 Aug 2019 22:25:14 +0000 (00:25 +0200)]
[gdb] Make maint info sections print relocated addresses
When running gdb.base/compare-sections.exp with -fPIE/-pie, we get:
...
print /u *(unsigned char *) 0x00000238^M
Cannot access memory at address 0x238^M
(gdb) FAIL: gdb.base/compare-sections.exp: read-only: get value of read-only section
...
The problem is that that "maint info sections" prints an unrelocated address:
...
[0] 0x00000238->0x00000254 at 0x00000238: .interp ALLOC LOAD READONLY \
DATA HAS_CONTENTS
...
while the test expects a relocated address.
Given that the documentation states that the command displays "the section
information displayed by info files", and that info files shows relocated
addresses:
...
0x0000555555554238 - 0x0000555555554254 is .interp
...
fix this by showing relocated addresses for maint info sections as
well.
Build and tested on x86_64-linux.
gdb/ChangeLog:
2019-08-16 Tom de Vries <tdevries@suse.de>
* maint.c (maintenance_info_sections): Also handle !ALLOBJ case using
print_objfile_section_info.
Tom Tromey [Tue, 9 Jul 2019 23:29:13 +0000 (17:29 -0600)]
TUI resize unification
The TUI currently has two different ways to resize a window: the
resize method, and the methods make_invisible_and_set_new_height and
make_visible_with_new_height.
There's no deep reason to have two different ways to resize a window,
so this patch unifies them, leaving just the "resize" method.
This also changes the locator to be handled more like an ordinary
window and less like an adjunct of the associated source window.
gdb/ChangeLog
2019-08-15 Tom Tromey <tom@tromey.com>
Tom Tromey [Thu, 1 Aug 2019 17:41:32 +0000 (11:41 -0600)]
Fix bug with character enumeration literal
gnat encodes character enumeration literals using a few different
schemes. The gnat compiler documented the "QU" and "QW" encodings,
but failed to document that a simpler encoding was used for certain
characters.
This patch updates gdb to handle this simple Q encoding. Note that
wide character literals are still not handled.
gdb/ChangeLog
2019-08-15 Tom Tromey <tromey@adacore.com>
Rename internal Python functions to start with an underscore
I could not tell if GdbSetPythonDirectory is internal or not because
I could not find any references to it, so I left it as-is.
Tested by running the testsuite on gdb.python/*.exp; everything still
passes.
2019-08-15 Christian Biesinger <cbiesinger@google.com>
* python/lib/gdb/__init__.py (GdbOutputFile): Rename to have a
leading underscore.
(GdbOutputErrorFile): Likewise.
(global scope): Adjust constructor calls to GdbOutput{,Error}File
accordingly.
(execute_unwinders): Rename to have a leading underscore.
(auto_load_packages): Likewise.
(global scope): Adjust call to auto_load_packages accordingly.
(GdbSetPythonDirectory): Likewise.
* python/py-unwind.c (pyuw_sniffer): Call _execute_unwinders
instead of execute_unwinders.
gdb/testsuite/ChangeLog:
2019-08-15 Christian Biesinger <cbiesinger@google.com>
* gdb.python/python.exp: Expect a leading underscore on
GdbOutput{,Error}File.
Jim Wilson [Thu, 15 Aug 2019 19:01:13 +0000 (12:01 -0700)]
RISC-V: Fix lui relaxation issue with code at address 0.
This fixes a problem originally reported at
https://github.com/riscv/riscv-binutils-gdb/issues/173
If you have code linked at address zero, you can have a lui instruction
loading a value 0x800 which gets relaxed to a c.lui which is valid (c.lui 0x1
followed by addi -0x800). Relaxation can reduce the value below 0x800 at which
point the c.lui 0x0 is no longer valid. We can fix this by converting the
c.lui to a c.li which can load 0.
bfd/
* elfnn-riscv.c (perform_relocation) <R_RISCV_RVC_LUI>: If
RISCV_CONST_HIGH_PART (value) is zero, then convert c.lui instruction
to c.li instruction, and use ENCODE_RVC_IMM to set value.
ld/
* testsuite/ld-riscv-elf/c-lui-2.d: New.
* testsuite/ld-riscv-elf/c-lui-2.ld: New.
* testsuite/ld-riscv-elf/c-lui-2.s: New.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Run the c-lui-2 test.
Tom Tromey [Tue, 9 Jul 2019 21:35:17 +0000 (15:35 -0600)]
TUI window resize should not need invisibility
When resizing a window, the TUI currently first makes it invisible,
then changes the size, and then restores its visibility.
I think this is done because curses doesn't truly support resizing a
window -- there is a "wresize" extension, but the man page says it
isn't available in all versions of curses.
First, this is probably not a major problem any more. I imagine most
of those old systems are gone now.
Second, I think it's a better API to have this detail hidden inside of
the resize method.
This patch changes the code to follow this idea, and changes the
ordinary resize method to use wresize when it is available. The
special case for the command window is also moved to methods on the
command window.
gdb/ChangeLog
2019-08-15 Tom Tromey <tom@tromey.com>
* tui/tui-layout.c (show_layout, show_source_disasm_command)
(show_data): Don't change window visibility.
(tui_gen_win_info::resize): Remove special case for command
window. Use wresize, when available.
(show_source_or_disasm_and_command): Don't change window
visibility.
* tui/tui-command.h (struct tui_cmd_window) <resize>: Declare.
<make_visible>: New method.
* tui/tui-command.c (tui_cmd_window::resize): New method.
Tom Tromey [Sun, 7 Jul 2019 03:19:45 +0000 (21:19 -0600)]
Change TUI source window iteration
Currently the TUI does separate bookkeeping to track which source
windows exist. It seems better to me to just refer to the list of
windows for this, so this patch removes the special handling and
instead adds a new iterator.
gdb/ChangeLog
2019-08-15 Tom Tromey <tom@tromey.com>
Tom Tromey [Sat, 6 Jul 2019 21:57:53 +0000 (15:57 -0600)]
Turn tui_erase_source_content into a method
This changes tui_erase_source_content into a method on
tui_source_window_base. The bulk of the work is moved into a helper
method, so that the callers can each pass the string appropriate to
the particular window class.
gdb/ChangeLog
2019-08-15 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.h (struct tui_source_window_base)
<do_erase_source_content>: New method.
<erase_source_content>: New method.
(tui_erase_source_content): Don't declare.
* tui/tui-winsource.c (tui_clear_source_content): Update.
(tui_source_window_base::do_erase_source_content): Rename from
tui_erase_source_content.
(tui_source_window_base::show_source_content): Update.
* tui/tui-win.c (tui_resize_all, tui_adjust_win_heights): Update.
* tui/tui-source.h (struct tui_source_window)
<erase_source_content>: New method.
* tui/tui-disasm.h (struct tui_disasm_window)
<erase_source_content>: New method.
Tom Tromey [Sat, 6 Jul 2019 21:52:13 +0000 (15:52 -0600)]
Remove tui_alloc_source_buffer
There is no longer any need for tui_alloc_source_buffer. The two
callers of this function immediately change the contents of the
window, undoing the work done by this function.
This required adding a move constructor to tui_source_element -- a
mildly surprising find, but without this, resizing the vector will
cause crashes. This issue was masked earlier because
tui_alloc_source_buffer handled this.
Note that a patch for this bug was submitted here:
Tom Tromey [Sat, 6 Jul 2019 14:23:34 +0000 (08:23 -0600)]
Remove FIXMEs from tui-layout.c
An earlier patch added a couple of FIXME comments to tui-layout.c.
This removes them. This is possible due to the previous patch that
changed how boxing works in the TUI -- now, no special case for the
command window is needed in box_win.
gdb/ChangeLog
2019-08-15 Tom Tromey <tom@tromey.com>
* tui/tui-layout.c (show_source_disasm_command)
(show_source_or_disasm_and_command): Use make_visible method, not
tui_make_window.
* tui/tui-command.h (struct tui_cmd_window) <make_visible>:
Remove.
Tom Tromey [Sat, 6 Jul 2019 14:21:38 +0000 (08:21 -0600)]
Simplify TUI boxing
In the TUI, whether or not a window can be boxed is a property of the
window's type. This adds a can_box method to the window classes, and
changes tui_make_window to defer to this, removing the "box_it"
paramter. This also lets us remove "enum tui_box", as it is no longer
used.
gdb/ChangeLog
2019-08-15 Tom Tromey <tom@tromey.com>
Sandra Loosemore [Thu, 15 Aug 2019 17:23:18 +0000 (10:23 -0700)]
Disable dw2-dir-file-name.exp on remote and/or Windows host.
This test has many hardwired assumptions that pathnames on build and
host are the same, and that POSIX pathname syntax is used. This
results in dozens of failures on a remote Windows host. Fixing these
assumptions would involve nontrivial rewrites; meanwhile, let's make
the test results reflect the reality that this testcase isn't supported
on remote host.
Sandra Loosemore [Thu, 15 Aug 2019 17:17:54 +0000 (10:17 -0700)]
Skip batch-preserve-term-settings.exp tests that cannot work on Windows.
This group of tests assume that the gdb "shell" command launches a
POSIX-compliant shell supporting the PPID environment variable, which
is used to get gdb's pid for killing it from a remote_exec shell. But
on Windows host "shell" launches cmd.exe, which doesn't have an
equivalent query.
Tom Tromey [Wed, 14 Aug 2019 15:18:21 +0000 (09:18 -0600)]
Replace write_inferior_memory with target_write_memory
target_write_memory is just a simple wrapper for
write_inferior_memory. Because target_write_memory is needed for
gdbsupport, and because gdb uses the name "target_write_memory"
everywhere, this patch renames write_inferior_memory and removes the
wrapper. I think this brings gdb and gdbserver slightly more in sync.
gdb/gdbserver/ChangeLog
2019-08-15 Tom Tromey <tromey@adacore.com>
Tom Tromey [Wed, 14 Aug 2019 15:11:28 +0000 (09:11 -0600)]
Simplify write_inferior_memory
gdbserver's write_inferior_memory uses a static variable to avoid
memory leaks, and has a comment referring to the lack of cleanups.
This patch removes this comment and the code in favor of a
straightforward use of std::vector.
gdb/gdbserver/ChangeLog
2019-08-15 Tom Tromey <tromey@adacore.com>
* target.c (write_inferior_memory): Use std::vector.
projects / thirdparty / binutils-gdb.git / log
