The area between 0xFF00 and 0xFFC0 is unallocated in the simulator
memory map, so extend the main memory region up to 0xFFC0 to allow the
simulator to make use of the extra 192 bytes of space.
sim/msp430/ChangeLog:
* msp430-sim.c (sim_open): Increase the size of the main memory region
to 0xFAC0.
I don't really understand why `regcache_thread_ptid_changed` is a static
method of `struct regcache` instead of being a static free function in
regcache.c. And I don't understand why `current_regcache` is a static
member of `struct regcache` instead of being a static global in
regcache.c. It's not wrong per-se, but there's no other place where we
do it like this in GDB (as far as I remember) and it just exposes things
unnecessarily in the .h.
Move them to be just static in regcache.c. As a result,
registers_changed_ptid doesn't need to be friend of the regcache class
anymore.
Removing the include of forward_list in regcache.h showed that we were
missing an include for it in dwarf2/index-write.c, record-btrace.c and
sparc64-tdep.c.
gdb/ChangeLog:
* regcache.h (class regcache): Remove friend
registers_changed_ptid.
<regcache_thread_ptid_changed>: Remove.
<regcaches>: Remove.
* regcache.c (regcache::regcaches): Rename to...
(regcaches): ... this. Make static.
(get_thread_arch_aspace_regcache): Update.
(regcache::regcache_thread_ptid_changed): Rename to...
(regcache_thread_ptid_changed): ... this. Update.
(class regcache_access): Remove.
(regcaches_test): Update.
(_initialize_regcache): Update.
* sparc64-tdep.c, dwarf2/index-write.c, record-btrace.c: Include
<forward_list>.
Change-Id: Iabc25759848010cfbb7ee7e27f60eaca17d61c12
The name `current_regcache` for the list of currently-existing regcaches
sounds wrong. The name is singular, but it holds multiple regcaches, so
it could at least be `current_regcaches`.
But in other places in GDB, "current" usually means "the object we are
working with right now". For example, we swap the "current thread" when
we want to operate on a given thread. This is not the case here, this
variable just holds all regcaches that exist at any given time, not "the
regcache we are working with right now".
So, I think calling it `regcaches` is better. I also considered
`regcache_list`, but a subsequent patch will make it a map and not a
list, so it would sound wrong again. `regcaches` sounds right for any
collection of regcache, whatever the type.
Rename a few other things that were related to this `current_regcache`
field. Note that there is a `get_current_regcache` function, which
returns the regcache of the current thread. That one is fine, because
it returns the regcache for the current thread.
gdb/ChangeLog:
* regcache.h (class regcache) <current_regcache>: Rename to...
<regcaches>: ... this. Move doc here.
* regcache.c (regcache::current_regcache) Rename to...
(regcache::regcaches): ... this. Move doc to header.
(get_thread_arch_aspace_regcache): Update.
(regcache::regcache_thread_ptid_changed): Update.
(registers_changed_ptid): Update.
(class regcache_access) <current_regcache_size>: Rename to...
<regcaches_size>: ... this.
(current_regcache_test): Rename to...
(regcaches_test): ... this.
(_initialize_regcache): Update.
Change-Id: I87de67154f5fe17a1f6aee7c4f2036647ee27b99
Prior to this commit, on an input such as "88888888888:", GAS hits a
signed integer overflow and likely an assertion failure. I see:
$ echo "88888888888:" | bin/aarch64-none-elf-as
{standard input}: Assembler messages:
{standard input}:1: Internal error in fb_label_name at ../gas/symbols.c:2049.
Please report this bug.
To fix this issue, I've taken two steps:
1. Change the type used for processing local labels in
read_a_source_file() from int to long, to allow representing more
local labels, and also since all uses of this variable (temp) are
actually of type long.
2. Detect if we would overflow and bail out with an error message
instead of actually overflowing and hitting the assertion in
fb_label_name().
gas/ChangeLog:
2020-08-06 Alex Coplan <alex.coplan@arm.com>
* read.c (read_a_source_file): Use long for local labels, detect
overflow and raise an error for overly-long labels.
* testsuite/gas/all/gas.exp: Add local-label-overflow test.
* testsuite/gas/all/local-label-overflow.d: New test.
* testsuite/gas/all/local-label-overflow.l: Error output.
* testsuite/gas/all/local-label-overflow.s: Input.
The width of the instruction didn't match the size of its operands.
2020-06-23 Victor Collod <vcollod@nvidia.com>
* amd64-tdep.c (amd64_analyze_prologue): Fix incorrect comment.
Change-Id: I104ebfe0b3c24bd6a8d0f0c5a791b9676a930a54
The eBPF ELF backend was not properly recording relocation addends
during installation, nor reading and applying them when performing
the final relocation. This lead to various issues with incorrect
relocations.
These issues are fixed with a new howto special function to install
the relocations, and updates to bpf_elf_relocate_section to read and
use the addends as recorded in the input_bfd.
bfd/ChangeLog
2020-08-05 David Faust <david.faust@oracle.com>
* elf64-bpf.c (bpf_elf_generic_reloc): New function.
(bpf_elf_howto_table): Use it here.
(bpf_elf_relocate_section): Use addends recorded in input_bfd for
instruction and data relocations.
ld/ChangeLog
2020-08-05 David Faust <david.faust@oracle.com>
* testsuite/ld-bpf/call-2.s: New file.
* testsuite/ld-bpf/call-2.d: Likewise.
* testsuite/ld-bpf/reloc-data-be.d: Likewise.
* testsuite/ld-bpf/reloc-data-le.d: Likewise.
* testsuite/ld-bpf/reloc-data.s: Likewise.
* testsuite/ld-bpf/reloc-insn-external-be.d: Likewise.
* testsuite/ld-bpf/reloc-insn-external-le.d: Likewise.
* testsuite/ld-bpf/reloc-insn-external.s: Likewise.
* testsuite/ld-bpf/reloc-insn32-be.d: Likewise.
* testsuite/ld-bpf/reloc-insn32-le.d: Likewise.
* testsuite/ld-bpf/reloc-insn32.s: Likewise.
* testsuite/ld-bpf/reloc-insn64-be.d: Likewise.
* testsuite/ld-bpf/reloc-insn64-le.d: Likewise.
* testsuite/ld-bpf/reloc-insn64.s: Likewise.
The MSP430 linker shuffles input sections with names beginning with
".either" between the upper and lower memory regions, to try to avoid
one region overflowing when there is space in the other region.
However, when an ".either" input section attached to the tail of an
output section was moved to a different output section in the other
region, that tail wasn't being updated to the new section at the end
of the original output section.
This caused a bug where a shuffled section could end up in the
middle of another section in the output executable, resulting in
corrupted code or data.
When changing the output section of an input section attached to the
tail of its output section, that tail is now updated to point to
the new input section at the end of the section list.
ld/ChangeLog:
2020-08-06 Jozef Lawrynowicz <jozef.l@mittosystems.com>
* emultempl/msp430.em (change_output_section): Update the tail
of the output section statement list when moving the original
tail to a different output section.
(eval_upper_either_sections): Don't move sections from the upper
region to the lower region unless the upper region is
overflowing.
While looking into the regressions reported by Luis Machado, I noticed
that null pathnames were being output in the warnings. E.g.
warning: Can't open file (null) during file-backed mapping note processing
I've changed the warning to output the pathname found in the note,
like this:
warning: Can't open file /var/lib/docker/aufs/diff/d07c...e21/lib/x86_64-linux-gnu/libc-2.27.so during file-backed mapping note processing
(I've shortened one of the path elements above.)
gdb/ChangeLog:
* corelow.c (core_target::build_file_mappings): Don't output
null pathname in warning.
I noticed some gdb.dwarf2 tests not running on my machine because of
this:
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/dw2-single-line-discriminators.exp ...
gdb compile failed, /usr/bin/ld: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-single-line-discriminators/dw2-single-line-discriminators0.o: relocation R_X86_64_32S against
symbol `x' can not be used when making a PIE object; recompile with -fPIE
collect2: error: ld returned 1 exit status
We get this when the target toolchain produces position-independent
executables by default. These tests are built from some assembly which
produces some relocations incompatible with position-independent
executables.
Add `nopie` to the compilation flags of these tests to force the
toolchain to produce non-position-independent executables. With this,
the changed tests run successfully on my machine.
gdb/ChangeLog:
* gdb.dwarf2/clztest.exp, gdb.dwarf2/dw2-common-block.exp,
gdb.dwarf2/dw2-dup-frame.exp, gdb.dwarf2/dw2-reg-undefined.exp,
gdb.dwarf2/dw2-single-line-discriminators.exp,
dw2-undefined-ret-addr.exp: Pass nopie to compilation options.
Change-Id: Ie06c946f8e56a6030be247d1c57f416fa8b67e4c
Older Rust compilers used special field names, rather than DWARF
features, to express the variant parts of Rust enums. This is handled
in gdb through a quirk recognizer that rewrites the types.
Tom de Vries pointed out in PR rust/26197 that the variant part
rewrite regressed this code. This patch fixes the problems:
* Univariant enums were not handled properly. Now we simply call
alloc_rust_variant for these as well.
* There was an off-by-one error in the handling of ordinary enums.
* Ordinary enums should have the size of their member types reset to
match the size of the enclosing enum. (It's not clear to me if this
is truly necessary, but it placates a test, and this is just legacy
handling in any case.)
Tested with Rust 1.12.0, 1.14.0, 1.19.0, 1.36.0, and 1.45.0 on x86-64
Fedora 32. There were some unrelated failures with 1.14.0 and 1.19,0;
but considering that these are fairly old releases, I don't plan to
look into them unless someone complains.
Note that this patch will not fix all the issues in the PR. In that
PR, Tom is using a somewhat unusual build of Rust -- in particular it
uses an older (pre-DWARF variant part) LLVM with a newer Rust. I
believe this compiler doesn't correctly implement the old-style name
fallback; the details are in the bug.
gdb/ChangeLog
2020-08-05 Tom Tromey <tromey@adacore.com>
PR rust/26197:
* dwarf2/read.c (alloc_rust_variant): Handle univariant case.
(quirk_rust_enum): Call alloc_rust_variant for univariant case.
Fix off-by-one and type size errors in ordinary case.
Operand sizes used for simulation of MSP430 hardware multiply
operations are not aligned with the sizes used on the target, resulting
in the simulator storing signed operands with too much precision.
Additionally, simulation of unsigned multiplication is missing explicit
casts to prevent any implicit sign extension.
gcc.c-torture/execute/pr91450-1.c uses unsigned widening multiplication
of 32-bit operands -4 and 2, to produce a 64-bit result:
0xffff fffc * 0x2 = 0x1 ffff fff8
If -4 is stored in 64-bit precision, then the multiplication is
essentially signed and the result is -8 in 64-bit precision
(0xffff ffff ffff fffc), which is not correct.
sim/msp430/ChangeLog:
* msp430-sim.c (put_op): For unsigned multiplication, explicitly cast
operands to the unsigned type before multiplying.
* msp430-sim.h (struct msp430_cpu_state): Fix types used to store hwmult
operands.
sim/testsuite/sim/msp430/ChangeLog:
* mpyull_hwmult.s: New test.
After commit 66d6346b25 "gdb: remove TYPE_DYN_PROP_ADDR", I run into:
...
FAIL: gdb.fortran/class-allocatable-array.exp: print this%_data%b
...
(and 185 more FAILs, all for fortran test-cases).
The commit replaces "!x" by "x != 0".
Fix this by using "x == 0" instead.
Build and tested on x86_64-linux.
gdb/ChangeLog:
2020-08-05 Tom de Vries <tdevries@suse.de>
* gdbtypes.c (type_not_allocated, type_not_associated): Use
"prop->const_val () == 0" instead of "prop->const_val () != 0".
A malloc failure triggered by a fuzzed object file isn't a real
problem unless objdump doesn't exit cleanly after the failure, which
it does. However we have bfd_malloc_and_get_section to sanity check
size of uncompressed sections before allocating memory. Use it.
PR 26337
* objdump.c (load_specific_debug_section): Don't malloc space for
section contents, use bfd_malloc_and_get_section.
Problem found by Tadashi G. Takaoka.
2020-08-04 Christian Groessler <chris@groessler.org>
Tadashi G. Takaoka <tadashi.g.takaoka@gmail.com>
* z8kgen.c (opt): Fix "sout imm16,rs" and "soutb imm16,rbs"
opcodes (special "out" to absolute address).
* z8k-opc.h: Regenerate.
2020-08-04 Christian Groessler <chris@groessler.org>
* gas/testsuite/gas/z8k/inout.d: Adapt to correct encoding of
"sout/soutb #imm,reg"
Change instances of int variables and return values used as boolean
values to use the bool type.
Shorten the comments of a few functions, because I think they go a bit
too much in implementation details, which appear out of date anyway.
Make other misc changes to the functions that are already being changed,
such as using nullptr instead of NULL, dropping `struct` keywords and
declaring variables when first used.
gdb/ChangeLog:
* frame.h (frame_id_p): Return bool.
(frame_id_artificial_p): Return bool.
(frame_id_eq): Return bool.
(has_stack_frames): Return bool.
(get_selected_frame): Fix typo in comment.
(get_frame_pc_if_available): Return bool.
(get_frame_address_in_block_if_available): Return bool.
(get_frame_func_if_available): Return bool.
(read_frame_register_unsigned): Return bool.
(get_frame_register_bytes): Return bool.
(safe_frame_unwind_memory): Return bool.
(deprecated_frame_register_read): Return bool.
(frame_unwinder_is): Return bool.
* frame.c (struct frame_info) <prev_arch::p>: Change type to
bool.
<this_id::p>: Likewise.
<prev_p>: Likewise.
(frame_stash_add): Return bool.
(get_frame_id): Use bool.
(frame_id_build_special) Use bool.
(frame_id_build_unavailable_stack): Use bool.
(frame_id_build): Use bool.
(frame_id_p): Return bool, use true/false instead of 1/0.
(frame_id_artificial_p): Likewise.
(frame_id_eq): Likewise.
(frame_id_inner): Likewise.
(get_frame_func_if_available): Likewise.
(read_frame_register_unsigned): Likewise.
(deprecated_frame_register_read): Likewise.
(get_frame_register_bytes): Likewise.
(has_stack_frames): Likewise.
(inside_main_func): Likewise.
(inside_entry_func): Likewise.
(get_frame_pc_if_available): Likewise.
(get_frame_address_in_block_if_available): Likewise.
(frame_unwinder_is): Likewise.
(safe_frame_unwind_memory): Likewise.
(frame_unwind_arch): Likewise.
Change-Id: I6121fa56739b688be79d73d087d76b268ba5a46a
One might think that variable `frame_info::prev_func::p` is a simple
true/false value, but that's not the case, it can also have the value -1
to mean "unavaiable". Change it to use the `cached_copy_status` enum,
which seems designed exactly for this purpose.
Rename to `status` to be consistent with `prev_pc::status` (and be cause
`p` means `predicate`, which implies boolean, which this is not).
gdb/ChangeLog:
* frame.c (frame_info) <prev_func> <p>: Rename to status, change
type to cached_copy_status.
(fprintf_frame): Adjust.
(get_frame_func_if_available): Adjust.
(frame_cleanup_after_sniffer): Adjust.
Change-Id: I50c6ebef6c0acb076e25c741f7f417bfd101d953
This patch adds basic support for the eBPF target: tdep and build
machinery. The accompanying simulator is introduced in subsequent
patches.
gdb/ChangeLog:
2020-08-04 Weimin Pan <weimin.pan@oracle.com>
Jose E. Marchesi <jose.marchesi@oracle.com>
* configure.tgt: Add entry for bpf-*-*.
* Makefile.in (ALL_TARGET_OBS): Add bpf-tdep.o
(ALLDEPFILES): Add bpf-tdep.c.
* bpf-tdep.c: New file.
* MAINTAINERS: Add bpf target and maintainer.
gdb/doc/ChangeLog:
2020-08-04 Jose E. Marchesi <jose.marchesi@oracle.com>
* gdb.texinfo (Contributors): Add information for the eBPF
support.
(BPF): New section.
In the check-test-names.exp library 'unset' was being used to unset an
array variable. Though this seems to work fine on tcl 8.6, it was
discovered on a CentOS 7.8.2003 machine, running tcl 8.5, that this
doesn't work and 'array unset' should be used instead.
Using 'array unset' should work fine for newer and older versions of
tcl (since 8.3, releases ~2000).
gdb/testsuite/ChangeLog:
* lib/check-test-names.exp (do_reset_vars): Use 'array unset' to
unset the array variable.
For DWARF4 DW_AT_high_pc can be expressed as constant offset from
DW_AT_low_pc which saves a relocation. Use DW_FORM_udate (uleb128)
to keep the constant value as small as possible.
gas/ChangeLog:
* dwarf2dbg.c (out_debug_abbrev): When DWARF2_VERSION >= 4, use
DW_FORM_udata for DW_AT_high_pc.
(out_debug_info): Use emit_leb128_expr for DW_AT_high_pc, when
DWARF2_VERSION >= 4.
* read.c (emit_leb128_exp): No longer static.
* read.h (emit_leb128_exp): Define.
For DWARF5 the zero file list entry in the .debug_line table represents
the compile unit main file. It can be set with .file 0 when -gdwarf-5
is given. But since this directive is illegal for older versions, this
is almost never set. To make sure it is always set (so DW_AT_name of
the compile unit can be set) use file (and dir) 1 if that is defined
(otherwise fall back to pwd, to match DW_AT_comp_dir).
gas/ChangeLog:
* gas/dwarf2dbg.c (out_dir_and_file_list): For DWARF5 emit at
least one directory if there is at least one file. Use dirs[1]
if dirs[0] is not set, or if there is no dirs[1] the current
working directory. Use files[1] filename, when files[0] filename
isn't set.
DWARF5 CU headers have a new unit type field and move the abbrev offset
to the end of the header.
gas/ChangeLog:
* dwarf2dbg.c (out_debug_info): Emit unit type and abbrev offset
for DWARF5.
* gas/testsuite/gas/elf/dwarf-4-cu.d: New file.
* gas/testsuite/gas/elf/dwarf-4-cu.s: Likewise.
* gas/testsuite/gas/elf/dwarf-5-cu.d: Likewise.
* gas/testsuite/gas/elf/dwarf-5-cu.s: Likewise.
* testsuite/gas/elf/elf.exp: Run dwarf-4-cu and dwarf-5-cu.
When reverting commit 9cfd2b89bd "[gdb/testsuite] Fix
gdb.arch/amd64-entry-value-paramref.S", we run into an internal-error:
...
(gdb) file amd64-entry-value-paramref^M
Reading symbols from amd64-entry-value-paramref...^M
src/gdb/dwarf2/read.c:18903: internal-error: could not find partial DIE
0x1b7 in cache [from module amd64-entry-value-paramref]^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
...
because of invalid dwarf.
In contrast, when using -readnow, we have:
...
(gdb) file -readnow amd64-entry-value-paramref
Reading symbols from amd64-entry-value-paramref...
Expanding full symbols from amd64-entry-value-paramref...
Dwarf Error: Cannot find DIE at 0x1b7 referenced from DIE at 0x11a \
[in module amd64-entry-value-paramref]
(gdb)
...
Change the internal error into a Dwarf Error, such that we have:
...
(gdb) file amd64-entry-value-paramref^M
Reading symbols from amd64-entry-value-paramref...^M
Dwarf Error: Cannot not find DIE at 0x1b7 \
[from module amd64-entry-value-paramref]^M
^M
(No debugging symbols found in amd64-entry-value-paramref)^M
(gdb)
...
Build and tested on x86_64-linux.
gdb/ChangeLog:
2020-08-04 Tom de Vries <tdevries@suse.de>
PR symtab/23270
* dwarf2/read.c (find_partial_die): Change internal error into Dwarf
Error.
This matches the current set of system calls in the FreeBSD head
development branch as of r363367. Some of these system calls
were also included in 12.1 release.
gdb/ChangeLog:
* syscalls/freebsd.xml: Regenerate.
The MSP430 GAS option "-md" is supposed to indicate that the CRT startup
code should copy data from ROM to RAM at startup. However, this option
has no effect; GAS handles the related behaviour automatically by
looking for the presence of certain symbols in the input file.
gas/ChangeLog:
* config/tc-msp430.c (OPTION_MOVE_DATA): Remove.
(md_parse_option): Remove case for OPTION_MOVE_DATA.
(md_longopts): Remove "md" entry.
(md_show_usage): Likewise.
When reading an exec with a .debug_line section containing a vendor-specific
extended opcode, we get:
...
$ gdb -batch -iex "set complaints 10" dw2-vendor-extended-opcode
During symbol reading: mangled .debug_line section
...
and reading of the .debug_line section is abandoned.
The vendor-specific extended opcode should be ignored, as specified in the
DWARF standard (7.1 Vendor Extensibility). [ FWIW, vendor-specific
standard opcodes are already ignored. ]
Fix this by ignoring all vendor-specific extended opcodes.
Build and tested on x86_64-linux.
gdb/ChangeLog:
2020-08-03 Tom de Vries <tdevries@suse.de>
PR symtab/26333
* dwarf2/read.c (dwarf_decode_lines_1): Ignore
DW_LNE_lo_user/DW_LNE_hi_user range.
gdb/testsuite/ChangeLog:
2020-08-03 Tom de Vries <tdevries@suse.de>
PR symtab/26333
* lib/dwarf.exp (DW_LNE_user): New proc.
* gdb.dwarf2/dw2-vendor-extended-opcode.c: New test.
* gdb.dwarf2/dw2-vendor-extended-opcode.exp: New file.
As far as I can tell, the following comment is false nowadays.
/* Calls to m-alloc get turned by sed into xm-alloc. */
Remove it, and call xmalloc.
* ldlex.l (yy_create_string_buffer): Use xmalloc rather than malloc.
* lexsup.c (parse_args): Likewise.
There are compilation warnings / errors when compiling coremaker2.c
for the gdb.base/corefile2.exp tests. Here's the command to use
on x86_64 linux:
make check RUNTESTFLAGS="--target_board unix/-m32" \
TESTS="gdb.base/corefile2.exp"
These are the warnings / errors - I've shortened the paths somewhat:
gdb compile failed, gdb/testsuite/gdb.base/coremaker2.c: In function 'main':
gdb/testsuite/gdb.base/coremaker2.c:106:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
106 | addr = ((unsigned long long) buf_ro + pagesize) & ~(pagesize - 1);
| ^
gdb/testsuite/gdb.base/coremaker2.c:108:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
108 | if (addr <= (unsigned long long) buf_ro
| ^
gdb/testsuite/gdb.base/coremaker2.c:109:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
109 | || addr >= (unsigned long long) buf_ro + sizeof (buf_ro))
| ^
gdb/testsuite/gdb.base/coremaker2.c:115:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
115 | mbuf_ro = mmap ((void *) addr, pagesize, PROT_READ,
| ^
gdb/testsuite/gdb.base/coremaker2.c:130:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
130 | addr = ((unsigned long long) buf_rw + pagesize) & ~(pagesize - 1);
| ^
gdb/testsuite/gdb.base/coremaker2.c:132:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
132 | if (addr <= (unsigned long long) buf_rw
| ^
gdb/testsuite/gdb.base/coremaker2.c:133:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
133 | || addr >= (unsigned long long) buf_rw + sizeof (buf_rw))
| ^
gdb/testsuite/gdb.base/coremaker2.c:139:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
139 | mbuf_rw = mmap ((void *) addr, pagesize, PROT_READ,
| ^
These were fixed by changing unsigned long long to uintptr_t.
Tested on either rawhide or Fedora 32 with architectures: x86_64,
x86_64/-m32, aarch64, s390x, and ppc64le.
gdb/testsuite/ChangeLog:
* gdb.base/coremaker2.c: Change all uses of 'unsigned long long'
to 'uintptr_t'
(inttypes.h): Include.
