When configuring with '--enbale-cgen-maint' the default for both the
opcodes/ and sim/ directories is to assume that the cgen source is
within the binutils-gdb source tree as binutils-gdb/cgen/.
In the old cvs days, this worked well, as cgen was just another
sub-module of the single cvs repository and could easily be checked
out within the binutils-gdb directory, and managed by cvs in the
normal way.
Now that binutils-gdb is in git, while cgen is still in cvs, placing
the cgen respository within the binutils-gdb tree is more troublesome,
and it would be nice if the two tools could be kept separate.
Luckily there is already some initial code in the configure.ac files
for both opcodes/ and sim/ to support having cgen be located outside
of the binutils-gdb tree, however, this was speculative code written
imagining a future where cgen would be built and installed to some
location.
Right now there is no install support for cgen, and so the configure
code in opcodes/ and sim/ doesn't really do anything useful. In this
commit I repurpose this code to allow binutils-gdb to be configured so
that it can make use of a cgen source directory that is outside of the
binutils-gdb tree.
With this commit applied it is now possible to configure and build
binutils-gdb like this:
/path/to/binutils-gdb/src/configure --enable-cgen-maint=/path/to/cgen/src/cgen/
make all-opcodes
make -C opcodes run-cgen-all
Just in case anyone is still using cgen inside the binutils-gdb tree,
I have left the default behaviour of '--enable-cgen-maint' (with no
parameter) unchanged, that is it looks for the cgen directory as
'binutils-gdb/cgen/'.
opcodes/ChangeLog:
* configure.ac (enable-cgen-maint): Support passing path to cgen
source tree.
* configure: Regenerate.
sim/ChangeLog:
* common/acinclude.m4 (enable-cgen-maint): Support passing path to
cgen source tree.
* cris/configure: Regenerate.
* frv/configure: Regenerate.
* iq2000/configure: Regenerate.
* lm32/configure: Regenerate.
* m32r/configure: Regenerate.
* or1k/configure: Regenerate.
* sh64/configure: Regenerate.
The RISC-V assembler generates fake labels with the name '.L0 ' as
part of the debug information (see
gas/config/tc-riscv.h:FAKE_LABEL_NAME).
The problem is that currently, when disassembling an object file, the
output looks like this (this is an example from the GDB testsuite, but
is pretty representative of anything with debug information):
000000000000001e <main>:
1e: 7179 addi sp,sp,-48
20: f406 sd ra,40(sp)
22: f022 sd s0,32(sp)
24: 1800 addi s0,sp,48
0000000000000026 <.L0 >:
26: 87aa mv a5,a0
28: feb43023 sd a1,-32(s0)
2c: fcc43c23 sd a2,-40(s0)
30: fef42623 sw a5,-20(s0)
0000000000000034 <.L0 >:
34: fec42783 lw a5,-20(s0)
38: 0007871b sext.w a4,a5
3c: 678d lui a5,0x3
3e: 03978793 addi a5,a5,57 # 3039 <.LASF30+0x2a9d>
42: 02f71463 bne a4,a5,6a <.L0 >
0000000000000046 <.L0 >:
46: 000007b7 lui a5,0x0
4a: 0007b783 ld a5,0(a5) # 0 <need_malloc>
4e: 6f9c ld a5,24(a5)
0000000000000050 <.L0 >:
50: 86be mv a3,a5
52: 466d li a2,27
54: 4585 li a1,1
56: 000007b7 lui a5,0x0
5a: 00078513 mv a0,a5
5e: 00000097 auipc ra,0x0
62: 000080e7 jalr ra # 5e <.L0 +0xe>
0000000000000066 <.L0 >:
66: 4785 li a5,1
68: a869 j 102 <.L0 >
000000000000006a <.L0 >:
6a: 000007b7 lui a5,0x0
6e: 00078513 mv a0,a5
72: 00000097 auipc ra,0x0
76: 000080e7 jalr ra # 72 <.L0 +0x8>
The frequent repeated '.L0 ' labels are pointless, as they are
non-unique there's no way to match a use of '.L0 ' to its appearence
in the output, so we'd be better off just not printing it at all.
That's what this patch does by defining a 'symbol_is_valid' method for
RISC-V. With this commit, the same disassembly now looks like this:
000000000000001e <main>:
1e: 7179 addi sp,sp,-48
20: f406 sd ra,40(sp)
22: f022 sd s0,32(sp)
24: 1800 addi s0,sp,48
26: 87aa mv a5,a0
28: feb43023 sd a1,-32(s0)
2c: fcc43c23 sd a2,-40(s0)
30: fef42623 sw a5,-20(s0)
34: fec42783 lw a5,-20(s0)
38: 0007871b sext.w a4,a5
3c: 678d lui a5,0x3
3e: 03978793 addi a5,a5,57 # 3039 <.LASF30+0x2a9d>
42: 02f71463 bne a4,a5,6a <.L4>
46: 000007b7 lui a5,0x0
4a: 0007b783 ld a5,0(a5) # 0 <need_malloc>
4e: 6f9c ld a5,24(a5)
50: 86be mv a3,a5
52: 466d li a2,27
54: 4585 li a1,1
56: 000007b7 lui a5,0x0
5a: 00078513 mv a0,a5
5e: 00000097 auipc ra,0x0
62: 000080e7 jalr ra # 5e <main+0x40>
66: 4785 li a5,1
68: a869 j 102 <.L5>
000000000000006a <.L4>:
6a: 000007b7 lui a5,0x0
6e: 00078513 mv a0,a5
72: 00000097 auipc ra,0x0
76: 000080e7 jalr ra # 72 <.L4+0x8>
In order to share the fake label between the assembler and the
libopcodes library, I've added some new defines RISCV_FAKE_LABEL_NAME
and RISCV_FAKE_LABEL_CHAR in include/opcode/riscv.h. I could have
just moved FAKE_LABEL_NAME to the include file, however, I thnk this
would be confusing, someone working on the assembler would likely not
expect to find FAKE_LABEL_NAME defined outside of the assembler source
tree. By introducing the RISCV_FAKE_LABEL_* defines I can leave the
assembler standard FAKE_LABEL_ defines in the assembler source, but
still share the RISCV_FAKE_LABEL_* with libopcodes.
gas/ChangeLog:
* config/tc-riscv.h (FAKE_LABEL_NAME): Define as
RISCV_FAKE_LABEL_NAME.
(FAKE_LABEL_CHAR): Define as RISCV_FAKE_LABEL_CHAR.
include/ChangeLog:
* dis-asm.h (riscv_symbol_is_valid): Declare.
* opcode/riscv.h (RISCV_FAKE_LABEL_NAME): Define.
(RISCV_FAKE_LABEL_CHAR): Define.
opcodes/ChangeLog:
* disassembler.c (disassemble_init_for_target): Add RISC-V
initialisation.
* riscv-dis.c (riscv_symbol_is_valid): New function.
Not all sed implementations support alternation via \| in the default
regular expressions. Instead, resort to separate sed expressions via
-e for $debugdir and $datadir. This fixes the default setting of the
auto-load directories on FreeBSD. Previously on FreeBSD the sed
invocation was a no-op causing the debugdir and datadir values to be
expanded yielding an autoload path of ':${prefix}/share/gdb'.
gdb/ChangeLog:
* configure: Re-generate.
* configure.ac: Use separate sed expressions to escape variables
in auto-load directories.
Armv8.3-A has another key used in pointer authentication called the
B-key (other than the A-key that is already supported). In order for
stack unwinders to work it is necessary to be able to identify frames
that have been signed with the B-key rather than the A-key and it was
felt that keeping this as an augmentation character in the CIE was the
best bet. The DWARF extensions for ARM therefore propose to add a new
augmentation character 'B' to the CIE augmentation string and the
corresponding cfi directive ".cfi_b_key_frame". I've made the relevant
changes to GAS and LD to add support for B-key unwinding, which required
modifying LD to check for 'B' in the augmentation string, adding the
".cfi_b_key_frame" directive to GAS and adding a "pauth_key" field to
GAS's fde_entry and cie_entry structs.
The pointer authentication instructions will behave as NOPs on
architectures that don't support them, and so a check for the
architecture being assembled for is not necessary since there will be no
behavioural difference between augmentation strings with and without the
'B' character on such architectures.
2018-12-05 Sam Tebbs <sam.tebbs@arm.com>
bfd/
* elf-eh-frame.c (_bfd_elf_parse_eh_frame): Add check for 'B'.
gas/
* dw2gencfi.c (struct cie_entry): Add tc_cie_entry_extras invocation.
(alloc_fde_entry): Add tc_fde_entry_init_extra invocation.
(output_cie): Add tc_output_cie_extra invocation.
(select_cie_for_fde): Add tc_cie_fde_equivalent_extra and
tc_cie_entry_init_extra invocation.
(frch_cfi_data, cfa_save_data): Move to dwgencfi.h.
* config/tc-aarch64.c (s_aarch64_cfi_b_key_frame): Declare.
(md_pseudo_table): Add "cfi_b_key_frame".
* config/tc-aarch64.h (tc_fde_entry_extras, tc_cie_entry_extras,
tc_fde_entry_init_extra, tc_output_cie_extra,
tc_cie_fde_equivalent_extra, tc_cie_entry_init_extra): Define.
* dw2gencfi.h (struct fde_entry): Add tc_fde_entry_extras invocation.
(pointer_auth_key): Define.
(frch_cfi_data, cfa_save_data): Move from dwgencfi.c.
* doc/c-aarch64.texi (.cfi_b_key_frame): Add documentation.
* testsuite/gas/aarch64/(pac_ab_key.d, pac_ab_key.s): New file.
Currently, if the target announces that it has floating point
registers in its target description then GDB assumes that the hardware
float ABI should be used. However, there's nothing stopping a user
compiling a program for the soft-float abi, and then trying to run
this on a target with hardware floating point registers.
This commit adjusts the logic that decides if GDB should use the
hardware float abi. The primary decision now is based on what the ELF
currently being executed says in its headers. If the file was
compiled for h/w float abi, then GDB uses h/w float abi, otherwise s/w
float is used.
If the current BFD is not an ELF then we don't currently have a
mechanism for figuring out if the file was compiled for float or not.
In this case we disable the h/w float abi. This shouldn't be a
problem as, right now, the RISC-V linker can only produce ELFs.
If there is NO current BFD (can this happen?) then we will enable h/w
float abi if the target has floating point hardware, otherwise, s/w
float abi is used.
This commit also adds some sanity checking that the features requested
in the BFD (xlen and flen) match the target description.
For testing I ran the testsuite on a target that returns a target
description containing both integer and floating point registers, but
used a compiler that didn't have floating point support. Before this
commit I would see failures on may tests that made inferior calls
using floating point arguments, after this commit, all of these issues
are resolved. One example from the testsuite is
gdb.base/infcall-nested-structs.exp.
gdb/ChangeLog:
* riscv-tdep.c (riscv_features_from_gdbarch_info): New function.
(riscv_find_default_target_description): Use new function to
extract feature from gdbarch_info.
(riscv_gdbarch_init): Add error checks for xlen and flen between
target description and bfd headers. Be smarter about when we
think the hardware floating point abi should be used.
In the config/sim.exp file two functions are defined. Both of these
functions define local timeout variables and then call gdb_expect,
which (through a call to get_largest_timeout) will find the local
definition of timeout.
However, both of these functions set the local timeout to some
arbitrary value and print a log message for this "new" timeout just
before returning.
As in both cases, the timeout is a local variable, this final setting
of the timeout has no effect and can be removed.
As having log messages about the timeout being adjusted could cause
confusion I've removed all logging related to timeouts in this
function, timeouts are adjusted throughout the testsuite without any
logging, there doesn't seem to be any good reason why these functions
should get their own logging.
With the logging gone there seems to be little need to a local timeout
variable at all, and so I've folded the local timeout directly into
the call to gdb_expect.
gdb/testsuite/ChangeLog:
* config/sim.exp (gdb_target_sim): Remove redundant adjustment of
local timeout variable before return, and remove all local timeout
variable entirely.
(gdb_load): Likewise.
On some heavily loaded AArch64 boxes, GDB will sometimes hang forever when
the inferior creates a thread. This hang happens inside the kernel during
the ptrace call to set hardware watchpoints or hardware breakpoints.
Currently, GDB will always set hw wp/bp at the start of each thread even if
there are none set in the process.
This patch works around the issue by avoiding setting hw wp/bp if there
are none set for the process.
On an effected machine, this fix drastically reduces the racy nature of the
gdb.threads test set. I ran the entire gdb test suite across all processors
for 100 iterations, then ran the results through the racy tests script.
Without the patch, 58 .exp files in gdb.threads were marked as racy. After
the patch this reduced to the same ~14 tests as the non effected boxes.
Clearly GDB will still be subject to hangs on an effect box if hw wp/bp's are
used prior to creating inferior threads on a heavily loaded system.
To enable this in gdbserver, the sequence in gdbserver add_lwp() is switched
to the same as gdb order as gdb, to ensure the thread is registered before
calling new_thread(). This allows aarch64_linux_new_thread() to read the
ptid.
gdb/ChangeLog:
* nat/aarch64-linux-hw-point.c
(aarch64_linux_any_set_debug_regs_state): New function.
* nat/aarch64-linux-hw-point.h
(aarch64_linux_any_set_debug_regs_state): New declaration.
* nat/aarch64-linux.c (aarch64_linux_new_thread): Check if any
BPs or WPs are set.
gdb/gdbserver/ChangeLog:
* linux-low.c (add_lwp): Switch ordering.
For GNU_PROPERTY_X86_COMPAT_ISA_1_USED and GNU_PROPERTY_X86_UINT32_OR_AND
properties, a bit in the output pr_data field is set if it is set in any
relocatable input pr_data fields and this property is present in all
relocatable input files. A missing property implies that its bits have
unknown values. When all bits in the the output pr_data field are zero,
this property should not be removed from output to indicate it has zero
in all bits.
bfd/
PR ld/23372
* elfxx-x86.c (_bfd_x86_elf_merge_gnu_properties): Don't remove
empty properties for GNU_PROPERTY_X86_COMPAT_ISA_1_USED and
GNU_PROPERTY_X86_UINT32_OR_AND.
(_bfd_x86_elf_link_fixup_gnu_properties): Likewise.
ld/
PR ld/23372
* testsuite/ld-i386/pr23372a.d: Updated.
* testsuite/ld-i386/pr23372c.d: Likewise.
* testsuite/ld-x86-64/pr23372a-x32.d: Likewise.
* testsuite/ld-x86-64/pr23372a.d: Likewise.
* testsuite/ld-x86-64/pr23372c-x32.d: Likewise.
* testsuite/ld-x86-64/pr23372c.d: Likewise.
gold/
PR gold/23594
* configure.ac: Add checks for link, mkdtemp.
* configure: Regenerate.
* config.in: Regenerate.
* plugin.cc (Plugin_recorder::init): Fall back to mktemp
if mkdtemp is not available.
(link_or_copy_file): Fall back to copy if link() is not available.
ARM Architecture Reference Manual for the profile ARMv8-A, Issue C.a,
states that MOV (register) is an alias of the ORR (shifted register)
iff shift == '00' && imm6 == '000000' && Rn == '11111'. However, mov
is currently preferred for a broader range of orr instructions, which
is incorrect.
2018-12-03 Egeyar Bagcioglu <egeyar.bagcioglu@oracle.com>
opcodes:
PR 23193
PR 19721
* aarch64-tbl.h (aarch64_opcode_table): Only disassemble an ORR
encoding as MOV if the shift operation is a left shift of zero.
gas:
PR 23193
PR 19721
* testsuite/gas/aarch64/pr19721.s: Add new test cases.
* testsuite/gas/aarch64/pr19721.d: Correct existing test
cases and add new ones.
The ELF compression header has a field (ch_addralign) that is set to
the alignment of the uncompressed section. This way the section itself
can have a different alignment than the decompressed section. Update
decompress_input_section to get alignment of the decompressed section
and use it when merging decompressed strings.
PR binutils/23919
* merge.cc (Output_merge_string<Char_type>::do_add_input_section):
Get addralign from decompressed_section_contents.
* object.cc (build_compressed_section_map): Set info.addralign.
(Object::decompressed_section_contents): Add a palign
argument and store p->second.addralign in *palign if it isn't
NULL.
* object.h (Compressed_section_info): Add addralign.
(section_is_compressed): Add a palign argument, default it
to NULL, store p->second.addralign in *palign if it isn't NULL.
(Object::decompressed_section_contents): Likewise.
* output.cc (Output_section::add_input_section): Get addralign
from section_is_compressed.
Delay setting its alignment until we know it is non-empty. Otherwise an
empty iplt section may change vma and lma of the following sections, which
triggers moving dot of the following section backwards, resulting in a
warning and section lma not being set properly. It later leads to a
"File truncated" error.
bfd/
PR ld/23930
* elfxx-x86.c (_bfd_x86_elf_size_dynamic_sections): Update
the iplt section alignment if it is non-empty.
(_bfd_x86_elf_link_setup_gnu_properties): Set plt.iplt_alignment
and delay setting the iplt section alignment.
* elfxx-x86.h (elf_x86_plt_layout): Add iplt_alignment.
ld/
PR ld/23930
* testsuite/ld-i386/i386.exp: Run pr23930.
* testsuite/ld-i386/pr23930.d: New file.
* testsuite/ld-x86-64/pr23930-32.t: Likewise.
* testsuite/ld-x86-64/pr23930-x32.d: Likewise.
* testsuite/ld-x86-64/pr23930.d: Likewise.
* testsuite/ld-x86-64/pr23930.t: Likewise.
* testsuite/ld-x86-64/pr23930a.s: Likewise.
* testsuite/ld-x86-64/pr23930b.s: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run pr23930 and pr23930-x32.
PR 23945
* readelf.c (slurp_ia64_unwind_table): Don't call elf_ia64_reloc_type
needlessly.
(slurp_hppa_unwind_table): Use same range checks and error messages
as slurp_ia64_unwind_table.
When caching a proc using gdb_caching_proc, it will become less likely to
be executed, and consequently it's going to be harder to detect that the
proc is racy. OTOH, in general the proc is easy to rerun. So, add a
test-case to run all uncached gdb_caching_procs a number of times and detect
inconsistent results.
The purpose of caching is to reduce runtime, so rerunning is somewhat
counter-productive in that aspect, but it's better than uncached, because the
number of reruns is constant-bounded, and the increase in runtime is bound to
this test-case, and can be disabled on slow targets.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2018-12-01 Tom de Vries <tdevries@suse.de>
* gdb.base/gdb-caching-proc.exp: New file.
This removes ineffectual and wrong code caching section names in
gas/stabs.c. Code like
seg = subseg_new (name, 0);
...
if (seg->name == name)
seg->name = xstrdup (name);
with the idea of being able to unconditionally free "name" later no
longer works. "name" is referenced by the section hash table as well
as in the section->name field. It would be possible to use
"bfd_rename_section (stdoutput, seg, xstrdup (name))", but instead I
opted for a fairly straight-forward approach of adding extra
parameters to two functions to indicate section name strings should be
freed if possible.
PR 23938
* read.h (get_stab_string_offset): Update prototype.
* stabs.c (get_stab_string_offset): Add free_stabstr_secname
parameter. Free stabstr_secname if unused as section name.
Don't xstrdup name when used.
(s_stab_generic): Remove forward declaration. Add
stab_secname_obstack_end param. Reference notes obstack via
macros. Delete cached_secname. Adjust get_stab_string_offset
call. Free stab_secname if unused as section name.
(s_stab): Adjust s_stab_generic call.
(s_xstab): Likewise. Delete saved_secname and saved_strsecname.
* config/obj-elf.c (obj_elf_init_stab_section): Adjust
get_stab_string_offset call.
* config/obj-coff.c (obj_coff_init_stab_section): Likewise.
* config/obj-som.c (obj_som_init_stab_section): Likewise.
* testsuite/gas/all/pr23938.s: New test.
* testsuite/gas/all/gas.exp: Run it.
kinfo_getfile() requires a couple of system calls to fetch the list of
open file descriptors. This can be much cheaper than invoking fstat
on all of the values from 0 to the open file resource limit maximum.
gdb/ChangeLog:
* common/filestuff.c [HAVE_KINFO_GETFILE]: Include headers.
(fdwalk) [HAVE_KINFO_GETFILE]: Use kinfo_getfile.
Valgrind reports this leak:
==798== VALGRIND_GDB_ERROR_BEGIN
==798== 32 (24 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 447 of 3,143
==798== at 0x4C2C48C: operator new(unsigned long) (vg_replace_malloc.c:334)
==798== by 0x51D401: linespec_parser_new(ls_parser*, int, language_defn const*, program_space*, symtab*, int, linespec_result*) (linespec.c:2756)
==798== by 0x524BF7: decode_line_full(event_location const*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) (linespec.c:3271)
==798== by 0x3E8893: parse_breakpoint_sals(event_location const*, linespec_result*) (breakpoint.c:9067)
==798== by 0x3E4E7F: create_breakpoint(gdbarch*, event_location const*, char const*, int, char const*, int, int, bptype, int, auto_boolean, breakpoint_ops const*, int, int, int, unsigned int) (breakpoint.c:9248)
==798== by 0x3E55F5: break_command_1(char const*, int, int) (breakpoint.c:9434)
==798== by 0x40BA68: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1888)
==798== by 0x665300: execute_command(char const*, int) (top.c:630)
...
linespec_parser_new allocates a std::vector<symtab *> at line 2756, and stores
the pointer to this vector in PARSER_RESULT (parser)->file_symtabs. At 3
different places in linespec.c, another std::vector is assigned to a
linespec->file_symtabs, without first deleting the current value.
The leak is fixed by assigning the vector itself instead of the pointer.
Everything should be moved, so there is no significant data copy
involved.
Tested on debian/amd64, + a bunch of tests re-run under valgrind
(including the test that throws an error).
gdb/ChangeLog:
* linespec.c (symtab_vector_up): Remove.
(symtabs_from_filename): Change return type to std::vector.
(collect_symtabs_from_filename): Likewise.
(create_sals_line_offset): Assign return value of
collect_symtabs_from_filename to *ls->file_symtabs.
(convert_explicit_location_to_linespec): Remove call to release.
(parse_linespec): Likewise.
(symtab_collector) <symtab_collector>: Remove initialization of
m_symtabs.
<release_symtabs>: Change return type to std::vector<symtab *>.
<operator ()>: Adjust.
Not all of the architecture-specific FreeBSD target files were
including the right headers to enable conditionals in fbsd-nat.h after
the C++ target conversion. As a result, certain operations like 'info
auxv' and 'p $_siginfo' were not working for some native targets
(noticed on RISC-V). Fix this in a couple of ways:
1) Declare fbsd_nat_target::xfer_partial unconditionally and only use
conditionals in the function body for individual target objects.
Originally this function was only used to read the ELF auxiliary
vector, so the entire function was conditional on a macro required
for that object (KERN_AUXV_PROC). However, xfer_partial has since
grown support for additional objects. Making the function
unconditional avoids needing to add the right header to fbsd-nat.h
and allows each target object to use independent requirements.
This did require using a more explicit conditional test for the
$_siginfo support. Removing the "outer" KERN_PROC_AUXV test
enabled $_siginfo for all kernels with PT_LWPINFO, but some older
kernels (FreeBSD 6.0) exposed PT_LWPINFO with a different siginfo
format. Instead use an explicit test for when the current siginfo
format was adopted (shipped in FreeBSD 7.0). This actually enables
$_siginfo on a wider range of kernels as KERN_PROC_AUXV wasn't
introduced until FreeBSD 9.1/10.0.
2) Include <sys/proc.h> in fbsd-nat.h for the definition of
TDP_RFPPWAIT that governs support for fork following.
gdb/ChangeLog:
* fbsd-nat.c [__FreeBSD_version >= 700009] (USE_SIGINFO): Macro
defined.
(union sigval32, struct siginfo32, fbsd_siginfo_size)
(fbsd_convert_siginfo): Make conditional on USE_SIGINFO instead
of KERN_PROC_AUXV and PT_LWPINFO.
(fbsd_nat_target::xfer_partial): Define method unconditionally.
Make TARGET_OBJECT_SIGNAL_INFO conditional on USE_SIGINFO.
Make TARGET_OBJECT_AUXV conditional on KERN_PROC_AUXV.
Make TARGET_OBJECT_FREEBSD_VMMAP and
TARGET_OBJECT_FREEBSD_PS_STRINGS conditional on KERN_PROC_VMMAP
and KERN_PROC_PS_STRINGS.
* fbsd-nat.h: Include <sys/proc.h>.
(fbsd_nat_target::xfer_partial): Declare method unconditionally.
`-march=r5900' already enables the R5900 short loop workaround.
However, the R5900 ISA and most other MIPS ISAs are mutually
exclusive since R5900-specific instructions are generated as well.
The `-mfix-r5900' option can be used in combination with e.g.
`-mips2' or `-mips3' to generate generic MIPS binaries that also
work with the R5900 target.
This change has been tested with `make RUNTESTFLAGS=mips.exp
check-gas' for the targets `mipsr5900el-unknown-linux-gnu',
`mipsr5900el-elf' and `mips3-unknown-linux-gnu'.
gas/
* config/tc-mips.c (mips_fix_r5900, mips_fix_r5900_explicit):
New variables.
(options): Add OPTION_FIX_R5900 and OPTION_NO_FIX_R5900
enumeration constants.
(md_longopts): Add "mfix-r5900" and "mno-fix-r5900" options.
(can_swap_branch_p, md_parse_option, mips_after_parse_args):
Handle the new options.
(md_show_usage): Document the `-mfix-r5900' option.
* doc/as.texi: Likewise.
* doc/c-mips.texi: Likewise.
* testsuite/gas/mips/mips.exp: Run R5900 dump tests.
* testsuite/gas/mips/r5900-fix.d: Test `-mfix-r5900' option.
* testsuite/gas/mips/r5900-fix.s: Likewise.
* testsuite/gas/mips/r5900-no-fix.d: Test `-mno-fix-r5900'.
* testsuite/gas/mips/r5900-no-fix.s: Likewise.
Adds riscv_linux_nat_target::read_description method to find a
suitable target description for the native linux target we are running
on.
Currently this will supply a suitably sized set of x-registers, and
will probe the kernel to see if the f-registers are readable. If they
are readable then we currently assume that the f-registers are the
same size as the x-registers as I don't know of a good way to probe
the f-register length. This will obviously need fixing in future.
As of Linux 4.19 there is no ptrace support for reading the
f-registers, this should appear in 4.20, so right now we only return
target descriptions without f-registers.
gdb/ChangeLog:
* riscv-linux-nat.c: Add 'inferior.h' and 'target-descriptions.h'
header files.
(riscv_linux_nat_target::read_description): New method.
GDB relies on the fact that if two target descriptions have the same
contents, then they will be the same object instance (having the same
address). One place where this is a requirement is in
GDBARCH_LIST_LOOKUP_BY_INFO which is used to find previously created
gdbarch objects.
In GDBARCH_LIST_LOOKUP_BY_INFO a pointer comparison is made on the
gdbarch's target description, if the pointers are different then it is
assumed the gdbarches have different, non-compatible target
descriptions.
Previously we would create duplicate target descriptions in the belief
that RISCV_GDBARCH_INIT would spot this duplication and discard the
second instance. However, this was incorrect, and instead we ended up
creating duplicate gdbarch objects.
With this commit every unique feature set will create one and only one
target description, the feature set and resulting target description
is then cached so that the same target description object can be
returned later.
Many other target avoid this problem by creating a small number of
named target descriptions, and returning one of these. However, we
currently have 8 possible target descriptions (32 vs 64 bit for x-reg
and f-reg, and h/w or s/w float abi) and creating each of these just
to avoid a dynamic cache seems pointless.
gdb/ChangeLog:
* arch/riscv.h (riscv_gdbarch_features::hash): New method.
* arch/riscv.c (struct riscv_gdbarch_features_hasher): New.
(riscv_tdesc_cache): New global.
(riscv_create_target_description): Look in the cache before
creating a new target description.
Add '==' and '!=' operators for the struct riscv_gdb_features,
allowing a small simplification.
gdb/ChangeLog:
* arch/riscv.h (riscv_gdb_features::operator==): New.
(riscv_gdb_features::operator!=): New.
* riscv-tdep.c (riscv_gdbarch_init): Make use of the inequality
operator.
Makes more of the interface related to fetching target descriptions
constant.
gdb/ChangeLog:
* arch/riscv.h (riscv_create_target_description): Make return type
const.
* arch/riscv.c (riscv_create_target_description): Likewise.
* riscv-tdep.c (riscv_find_default_target_description): Likewise.
First of all, I would like to express my gratitude to Keith Seitz, Jan
Kratochvil and Tom Tromey, who were really kind and helped a lot with
this bug. The patch itself was authored by Jan.
This all began with:
https://bugzilla.redhat.com/show_bug.cgi?id=1639242
py-bt is broken, results in exception
In summary, the error reported by the bug above is:
$ gdb -args python3
GNU gdb (GDB) Fedora 8.1.1-3.fc28
(...)
Reading symbols from python3...Reading symbols from /usr/lib/debug/usr/bin/python3.6-3.6.6-1.fc28.x86_64.debug...done.
done.
Dwarf Error: could not find partial DIE containing offset 0x316 [in module /usr/lib/debug/usr/bin/python3.6-3.6.6-1.fc28.x86_64.debug]
After a long investigation, and after thinking that the problem might
actually be on DWZ's side, we were able to determine that there's
something wrong going on when
dwarf2read.c:dwarf2_find_containing_comp_unit performs a binary search
over all of the CUs belonging to an objfile in order to find the CU
which contains a DIE at an specific offset. The current algorithm is:
static struct dwarf2_per_cu_data *
dwarf2_find_containing_comp_unit (sect_offset sect_off,
unsigned int offset_in_dwz,
struct dwarf2_per_objfile *dwarf2_per_objfile)
{
struct dwarf2_per_cu_data *this_cu;
int low, high;
const sect_offset *cu_off;
low = 0;
high = dwarf2_per_objfile->all_comp_units.size () - 1;
while (high > low)
{
struct dwarf2_per_cu_data *mid_cu;
int mid = low + (high - low) / 2;
mid_cu = dwarf2_per_objfile->all_comp_units[mid];
cu_off = &mid_cu->sect_off;
if (mid_cu->is_dwz > offset_in_dwz
|| (mid_cu->is_dwz == offset_in_dwz && *cu_off >= sect_off))
high = mid;
else
low = mid + 1;
}
For the sake of this example, let's consider that "sect_off =
0x7d".
There are a few important things going on here. First,
"dwarf2_per_objfile->all_comp_units ()" will be sorted first by
whether the CU is a DWZ CU, and then by cu->sect_off. In this
specific bug, "offset_in_dwz" is false, which means that, for the most
part of the loop, we're going to do "high = mid" (i.e, we'll work with
the lower part of the vector).
In our particular case, when we reach the part where "mid_cu->is_dwz
== offset_in_dwz" (i.e, both are false), we end up with "high = 2" and
"mid = 1". I.e., there are only 2 elements in the vector who are not
DWZ. The vector looks like this:
#0: cu->sect_off = 0; length = 114; is_dwz = false <-- low
#1: cu->sect_off = 114; length = 7796; is_dwz = false <-- mid
#2: cu->sect_off = 0; length = 28; is_dwz = true <-- high
...
The CU we want is #1, which is exactly where "mid" is. Also, #1 is
not DWZ, which is also exactly what we want. So we perform the second
comparison:
(mid_cu->is_dwz == offset_in_dwz && *cu_off >= sect_off)
^^^^^^^^^^^^^^^^^^^
Because "*cu_off = 114" and "sect_off = 0x7d", this evaluates to
false, so we end up with "low = mid + 1 = 2", which actually gives us
the wrong CU (i.e., a CU that is DWZ). Next in the code, GDB does:
gdb_assert (low == high);
this_cu = dwarf2_per_objfile->all_comp_units[low];
cu_off = &this_cu->sect_off;
if (this_cu->is_dwz != offset_in_dwz || *cu_off > sect_off)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
{
if (low == 0 || this_cu->is_dwz != offset_in_dwz)
error (_("Dwarf Error: could not find partial DIE containing "
"offset %s [in module %s]"),
sect_offset_str (sect_off),
bfd_get_filename (dwarf2_per_objfile->objfile->obfd));
...
Triggering the error we saw in the original bug report.
It's important to notice that we see the error message because the
selected CU is a DWZ one, but we're looking for a non-DWZ CU here.
However, even when the selected CU is *not* a DWZ (and we don't see
any error message), we still end up with the wrong CU. For example,
suppose that the vector had:
#0: cu->sect_off = 0; length = 114; is_dwz = false
#1: cu->sect_off = 114; length = 7796; is_dwz = false
#2: cu->sect_off = 7910; length = 28; is_dwz = false
...
I.e., #2's "is_dwz" is false instead of true. In this case, we still
want #1, because that's where the DIE is located. After the loop ends
up in #2, we have "is_dwz" as false, which is what we wanted, so we
compare offsets. In this case, "7910 >= 0x7d", so we set "mid = high
= 2". Next iteration, we have "mid = 0 + (2 - 0) / 2 = 1", and thus
we examining #1. "is_dwz" is still false, but "114 >= 0x7d" also
evaluates to false, so "low = mid + 1 = 2", which makes the loop stop.
Therefore, we end up choosing #2 as our CU, even though #1 is the
right one.
The problem here is happening because we're comparing "sect_off"
directly against "*cu_off", while we should actually be comparing
against "*cu_off + mid_cu->length" (i.e., the end offset):
...
|| (mid_cu->is_dwz == offset_in_dwz
&& *cu_off + mid_cu->length >= sect_off))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
And this is what the patch does. The idea is that if GDB is searching
for an offset that falls above the *end* of the CU being
analyzed (i.e., "mid"), then the next iteration should try a
higher-offset CU next. The previous algorithm was using
the *beginning* of the CU.
Unfortunately, I could not devise a testcase for this problem, so I am
proposing a fix with this huge explanation attached to it in the hope
that it is sufficient. After talking a bit to Keith (our testcase
guru), it seems that one would have to create an objfile with both DWZ
and non-DWZ sections, which may prove very hard to do, I think.
I ran this patch on our BuildBot, and no regressions were detected.
gdb/ChangeLog:
2018-11-30 Jan Kratochvil <jan.kratochvil@redhat.com>
Keith Seitz <keiths@redhat.com>
Tom Tromey <tom@tromey.com>
Sergio Durigan Junior <sergiodj@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1613614
* dwarf2read.c (dwarf2_find_containing_comp_unit): Add
'mid_cu->length' to '*cu_off' when checking if 'sect_off' is
inside the CU.
Given that a target's stratum is a property of the type, and not of an
instance of the type, get rid of to_stratum data field and replace it
with a virtual method.
I.e., when we have e.g., 10 target remote instances active, there's no
need for each of the instances to have their own to_stratum copy.
gdb/ChangeLog:
2018-11-30 Pedro Alves <palves@redhat.com>
* aix-thread.c (aix_thread_target) <aix_thread_target>: Delete.
<stratum>: New override.
* bfd-target.c (aix_thread_target) <aix_thread_target>: Delete.
<stratum>: New override.
* bsd-uthread.c (bsd_uthread_target) <bsd_uthread_target>: Delete.
<stratum>: New override.
* exec.c (exec_target) <exec_target>: Delete.
<stratum>: New override.
* gdbarch-selftests.c (register_to_value_test): Adjust to use the
stratum method instead of the to_stratum field.
* linux-thread-db.c (thread_db_target) <thread_db_target>: Delete.
<stratum>: New override.
(thread_db_target::thread_db_target): Delete.
* make-target-delegates (print_class): Don't print a ctor
declaration. Print a stratum method override declaration.
* process-stratum-target.h (process_stratum_target)
<process_stratum_target>: Delete.
<stratum>: New override.
* ravenscar-thread.c (ravenscar_thread_target)
<ravenscar_thread_target>: Delete.
<stratum>: New override.
* record-btrace.c (record_btrace_target)
<record_btrace_target>: Delete.
<stratum>: New override.
* record-full.c (record_full_base_target)
<record_full_base_target>: Delete.
<stratum>: New override.
* record.c (record_disconnect, record_detach)
(record_mourn_inferior, record_kill): Adjust to use the stratum
method instead of the to_stratum field.
* regcache.c (cooked_read_test, cooked_write_test): Likewise.
* sol-thread.c (sol_thread_target)
<sol_thread_target>: Delete.
<stratum>: New override.
* spu-multiarch.c (spu_multiarch_target)
<spu_multiarch_target>: Delete.
<stratum>: New override.
* target-delegates.c: Regenerate.
* target.c (target_stack::push, target_stack::unpush)
(pop_all_targets_above, pop_all_targets_at_and_above)
(info_target_command, target_require_runnable)
(target_stack::find_beneath): Adjust to use the stratum method
instead of the to_stratum field.
(dummy_target::dummy_target): Delete.
(dummy_target::stratum): New.
(debug_target::debug_target): Delete.
(debug_target::stratum): New.
(maintenance_print_target_stack): Adjust to use the stratum method
instead of the to_stratum field.
* target.h (struct target_ops) <stratum>: New method.
<to_stratum>: Delete.
<is_pushed>: Adjust to use the stratum method
instead of the to_stratum field.
This patch converts the default_child_has_foo functions to
process_stratum_target methods. This simplifies "regular"
non-inf_child process_stratum targets, since they no longer have to
override the target_ops::has_foo methods to call the default_child_foo
functions. A couple targets need to override the new defaults
(corelow and tracefiles), but it still seems like a good tradeoff,
since those are expected to be little different (target doesn't run).
gdb/ChangeLog:
2018-11-30 Pedro Alves <palves@redhat.com>
* corelow.c (core_target) <has_all_memory, has_execution>: New
overrides.
* inf-child.c (inf_child_target::has_all_memory)
(inf_child_target::has_memory, inf_child_target::has_stack)
(inf_child_target::has_registers)
(inf_child_target::has_execution): Delete.
* inf-child.h (inf_child_target) <has_all_memory, has_memory,
has_stack, has_registers, has_execution>: Delete.
* process-stratum-target.c
(process_stratum_target::has_all_memory)
(process_stratum_target::has_memory)
(process_stratum_target::has_stack)
(process_stratum_target::has_registers)
(process_stratum_target::has_execution): New.
* process-stratum-target.h (process_stratum_target)
<has_all_memory, has_memory, has_stack, has_registers,
has_execution>: New method overrides.
* ravenscar-thread.c (ravenscar_thread_target) <has_all_memory,
has_memory, has_stack, has_registers, has_execution>: Delete.
* remote-sim.c (gdbsim_target) <has_stack, has_registers,
has_execution>: Delete.
* remote.c (remote_target) <has_all_memory, has_memory, has_stack,
has_registers, has_execution>: Delete.
* target.c (default_child_has_all_memory)
(default_child_has_memory, default_child_has_stack)
(default_child_has_registers, default_child_has_execution):
Delete.
* target.h (default_child_has_all_memory)
(default_child_has_memory, default_child_has_stack)
(default_child_has_registers, default_child_has_execution):
Delete.
* tracefile.h (tracefile_target) <has_execution>: New override.
This adds a base class that all process_stratum targets inherit from.
default_thread_address_space/default_thread_architecture only make
sense for process_stratum targets, so they are transformed to
process_stratum_target methods/overrides.
gdb/ChangeLog:
2018-11-30 Pedro Alves <palves@redhat.com>
* Makefile.in (COMMON_SFILES): Add process-stratum-target.c.
* bsd-kvm.c: Include "process-stratum-target.h".
(bsd_kvm_target): Now inherits from process_stratum_target.
(bsd_kvm_target::bsd_kvm_target): Default it.
* corelow.c: Include "process-stratum-target.h".
(core_target): Now inherits from process_stratum_target.
(core_target::core_target): Don't set to_stratum here.
* inf-child.c (inf_child_target::inf_child_target): Delete.
* inf-child.h: Include "process-stratum-target.h".
(inf_child_target): Inherit from process_stratum_target.
(inf_child_target) <inf_child_target>: Default it.
<can_async_p, supports_non_stop, supports_disable_randomization>:
Delete overrides.
* process-stratum-target.c: New file.
* process-stratum-target.h: New file.
* remote-sim.c: Include "process-stratum-target.h".
(gdbsim_target): Inherit from process_stratum_target.
<gdbsim_target>: Default it.
* remote.c: Include "process-stratum-target.h".
(remote_target): Inherit from process_stratum_target.
<remote_target>: Default it.
* target.c (default_thread_address_space)
(default_thread_architecture): Delete.
* target.h (target_ops) <thread_architecture>: Now returns NULL by
default.
<thread_address_space>: Ditto.
* test-target.h: Include "process-stratum-target.h" instead of
"target.h".
(test_target_ops): Inherit from process_stratum_target.
<test_target_ops>: Default it.
* tracefile.c (tracefile_target::tracefile_target): Delete.
* tracefile.h: Include "process-stratum-target.h".
(tracefile_target): Inherit from process_stratum_target.
<tracefile_target>: Default it.
* target-delegates.c: Regenerate.
There's no need to have all target.h users seeing this type.
Also helps with a follow up patch.
gdb/ChangeLog:
2018-11-30 Pedro Alves <palves@redhat.com>
* Makefile.in (COMMON_SFILES): Add test-target.c.
* gdbarch-selftests.c: Include "test-target.h".
* regcache.c: Include "test-target.h".
* target.c (test_target_info, test_target_ops::info): Move to ...
* test-target.c: ... this new file.
* target.h (test_target_ops): Move to ...
* test-target.h: ... this new file.
PR 23932
* elf.c (IS_CONTAINED_BY_LMA): Add a check for a negative section
size.
(rewrite_elf_program_header): If no sections are mapped into a
segment return an error.
IFUNC resolvers must always be called via their global entry point.
They will be called from ld.so rather than from the local executable.
PR 23937
bfd/
* elf64-ppc.c (write_plt_relocs_for_local_syms): Don't add local
entry offset for ifuncs.
ld/
* testsuite/ld-powerpc/pr23937.d,
* testsuite/ld-powerpc/pr23937.s: New test.
* testsuite/ld-powerpc/powerpc.exp: Run it.
Valgrind reports the below leak.
Fix the leak by using xrealloc, even for the first allocation,
as buf is static.
==29158== 5,888 bytes in 23 blocks are definitely lost in loss record 3,028 of 3,149
==29158== at 0x4C2BE2D: malloc (vg_replace_malloc.c:299)
==29158== by 0x41B557: xmalloc (common-utils.c:44)
==29158== by 0x60B7D9: forward_search_command(char const*, int) (source.c:1563)
==29158== by 0x40BA68: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1888)
==29158== by 0x665300: execute_command(char const*, int) (top.c:630)
...
gdb/ChangeLog
2018-11-29 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* source.c (forward_search_command): Fix leak by using
xrealloc even for the first allocation in the loop, as buf
is static.
Commit 6b1747cd1 ("invoke_xmethod & array_view") contains this change:
- argvec = (struct value **) alloca (sizeof (struct value *) * 4);
+ value *argvec_storage[3];
+ gdb::array_view<value *> argvec = argvec_storage;
However, value_x_unop still does:
argvec[2] = value_from_longest (builtin_type (gdbarch)->builtin_int, 0);
argvec[3] = 0;
This triggers an error with -fsanitize=address from userdef.exp:
ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdcf185068 at pc 0x000000e4f912 bp 0x7ffdcf184d80 sp 0x7ffdcf184d70
WRITE of size 8 at 0x7ffdcf185068 thread T0
#0 0xe4f911 in value_x_unop(value*, exp_opcode, noside) ../../binutils-gdb/gdb/valarith.c:557
[...]
I think the two assignments to argvec[3] should just be removed, and
that this was intended in the earlier patch but just missed.
This passes userdef.exp with -fsanitize=address.
gdb/ChangeLog
2018-11-29 Tom Tromey <tom@tromey.com>
* valarith.c (value_x_unop): Don't set argvec[3].
-fsanitize=address pointed out a use-after-free in gdbserver. In
particular, handle_detach could reference "process" after it was
deleted by detach_inferior. Avoiding this also necessitated changing
target_ops::join to take a pid rather than a process_info*.
Tested by the buildbot using a few of the gdbserver builders.
gdb/gdbserver/ChangeLog
2018-11-29 Tom Tromey <tom@tromey.com>
* win32-low.c (win32_join): Take pid, not process.
* target.h (struct target_ops) <join>: Change argument type.
(join_inferior): Change argument name.
* spu-low.c (spu_join): Take pid, not process.
* server.c (handle_detach): Preserve pid before destroying
process.
* lynx-low.c (lynx_join): Take pid, not process.
* linux-low.c (linux_join): Take pid, not process.
When discovering the statement lists via their header variable
statement_list, file_chain and input_file_chain it can be confusing to
figure out what they are for. They can point to the same initial
statement and the relation between the next field they use is not
obvious from the name.
This commit adds comment for each of those statement list header to
explain what they are for and what next field they use. It also rewrite
the comment for the next fields to simply redirect the reader to the
list header to avoid duplication of documentation.
2018-11-29 Thomas Preud'homme <thomas.preudhomme@linaro.org>
ld/
* ldlang.c (statement_list): Document purpose and what next field it
uses.
(file_chain): Likewise.
(input_file_chain): Likewise.
* ldlang.h (lang_statement_header_type): Document statement list header
the next pointer correspond to.
(lang_statement_header_type): Replace comment for next and
next_real_file field to refer the reader to their corresponding
statement list header.
Andrew Burgess
GDB Administrator
John Baldwin
Sam Tebbs
Alan Hayward
Alan Modra
H.J. Lu
Alexey Neyman
wu.heng
Jim Wilson
Egeyar Bagcioglu
Nick Clifton
Tom de Vries
Simon Marchi
Fredrik Noring
Sergio Durigan Junior
Pedro Alves
Philippe Waroquiers
Rajendra SY
Tom Tromey
Thomas Preud'homme