Tom Tromey [Mon, 5 Apr 2021 12:53:35 +0000 (06:53 -0600)]
Adjust location of readline in sim/erc32
sim/erc32 uses an obsolete path to the in-tree build of readline.
readline was moved into a subdirectory some time ago. This patch
fixes the problem. Tested by rebuilding.
sim/erc32/ChangeLog
2021-04-05 Tom Tromey <tromey@adacore.com>
Alan Modra [Mon, 5 Apr 2021 05:57:37 +0000 (15:27 +0930)]
C99 bfd configury
Certain library headers and functions are required by C99. This
removes configure tests for them. The patch also removes AC_ISC_POSIX
and AC_HEADER_DIRENT, which the autoconf manual states are obsolescent.
sys/time.h is no longer tangled up with time.h so it can be handled by
the gprof configure.
* configure.ac: Don't check for long long or long double type.
Don't check for alloca.h, limits.h, stddef.h, stdlib.h, string.h,
strings.h, time.h, wchar.h, wctype.h or sys/time.h. Don't check
for strtoull, free, malloc, realloc, getenv, strstr, snprintf,
vsnprintf, strlen or setitimer. Sort AC_CHECK_DECLS.
(AC_ISC_POSIX): Don't invoke.
(AC_HEADER_TIME, AC_HEADER_DIRENT, ACX_HEADER_STRING): Likewise.
* sysdep.h: Remove many HAVE_*_H checks and fallback declarations.
Do test HAVE_SYS_TYPES_H. Don't include sys/time.h. Reorder
header order as per automake AC_INCLUDES_DEFAULT.
* bfd-in.h: Include inttypes.h unconditionally.
* bfd.c (_bfd_doprnt, _bfd_doprnt_scan): Assume long long and
long double are available.
(bfd_scan_vma): Assume long long and strtoull are available.
* elflink.c: Include limits.h unconditionally.
* elfnn-riscv.c: Likewise.
* wasm-module.c: Likewise.
* hpux-core.c: Include dirent.h unconditionally.
* trad-core.c: Likewise.
* hosts/x86-64linux.h: Include stdlib.h unconditionally.
* peXXigen.c: Remove HAVE_WCHAR_H and HAVE_WCTYPE_H checks.
* elf32-m68hc1x.c: Don't include alloca-conf.h.
* elf64-hppa.c: Likewise.
* som.c: Likewise.
* wasm-module.c: Likewise.
* xsym.c: Likewise.
* bfd-in2.h: Regenerate.
* config.in: Regenerate.
* configure: Regenerate.
Alan Modra [Mon, 5 Apr 2021 05:57:02 +0000 (15:27 +0930)]
C99 gprof configury
Given C99 we don't need to check for setlocale. The patch also
adds setitimer checks so that they can be removed from bfd where they
aren't needed. According to the automake manual AC_ISC_POSIX is
obsolete, so that is removed. HAVE_SETMODE isn't checked anywhere,
so it is pointless to have a configure test for setmode.
* configure.ac: Check for sys/time.h and setitimer. Don't invoke
AC_ISC_POSIX. Don't check for setmode.
* gprof.c: Don't test HAVE_SETLOCALE.
* gprof.h: Include sys/time.h.
* configure: Regenerate.
* gconfig.in: Regenerate.
This is likely coming from the trad-frame refactor in 098caef485a4
("Refactor struct trad_frame_saved_regs"). Here's an example of how to
reproduce it:
$ ./gdb -q -nx --data-directory=data-directory a.out -ex "tar rem :1234" -ex "b foo" -ex c -ex bt
Reading symbols from a.out...
Remote debugging using :1234
0x00000000 in __vectors ()
Breakpoint 1 at 0x110: file test.c, line 3.
Note: automatically using hardware breakpoints for read-only addresses.
Continuing.
Breakpoint 1, foo (x=2) at test.c:3
3 return x * 7;
#0 foo (x=2) at test.c:3
/home/simark/src/wt/avr/gdb/trad-frame.h:143: internal-error: LONGEST trad_frame_saved_reg::addr() const: Assertion `m_kind == trad_frame_saved_reg_kind::ADDR' failed.
What the AVR code does is:
1. In avr_scan_prologue, in the block that says "First stage of the
prologue scanning.", look for "push rX" instructions and note that rX
is saved on the stack. But instead of putting the actual stack
address directly, it puts an offset (from the previous frame's sp).
2. Back in avr_frame_unwind_cache, in the block that says "Adjust all
the saved registers", adjust all these values to be real stack
addresses.
To check whether a register was assigned an address (and therefore if it
needs adjustment), the code does:
if (info->saved_regs[i].addr () > 0)
Since commit 098caef485a4, it's invalid to call the `addr` getter of
trad_frame_saved_reg if the register hasn't been assigned an address.
Instead, the code could use the `is_addr` getter to verify if the
register has been assigned an address. This is what this patch does.
gdb/ChangeLog:
* avr-tdep.c (avr_frame_unwind_cache): Use
trad_frame_saved_reg::is_addr.
Mike Frysinger [Thu, 10 Dec 2020 03:26:30 +0000 (22:26 -0500)]
sim: example-synacor: a simple implementation for reference
Provide a simple example simulator for people porting to new targets
to use as a reference. This one has the advantage of being used by
people and having a fun program available for it.
It doesn't require a special target -- the example simulators can be
built for any existing port.
Mike Frysinger [Sun, 14 Mar 2021 01:54:49 +0000 (20:54 -0500)]
sim: testsuite: integrate common tests into build
Now that we have the common automake build with support for build-time
programs working, we can integrate the common tests into the default
`make check` flow.
Mike Frysinger [Sat, 16 Jan 2021 07:27:38 +0000 (02:27 -0500)]
sim: add preliminary support for --enable-targets
This doesn't actually create one `run` program like other projects,
but creates multiple `run-$arch` targets. While it might not seem
that useful initially, this has some nice properties:
- Allows us to quickly build all sim targets in a single tree.
- Positions us better for converting targets over to a proper
multitarget build+install.
We don't have the ability to actually run tests against them, but
that's due to a limitation in gas: it doesn't support multitarget.
If that ever changes, we should be able to turn on our tests too.
We can improve the test framework to fallback to a system toolchain
if available to help mitigate that.
Mike Frysinger [Mon, 22 Feb 2021 04:35:46 +0000 (23:35 -0500)]
sim: igen: merge build into top level
This simplifies the build a bit (especially for deps in port subdirs),
and avoids recursive make. This in turn speeds up the build, and sets
us up for multi-target.
Simon Marchi [Fri, 2 Apr 2021 15:50:45 +0000 (11:50 -0400)]
gdb: remove objfile parameter from get_objfile_bfd_data
I noticed it was unused. I think that makes sense, as it shows that
objfile_per_bfd_storage is not specific to one objfile (it can be shared
by multiple objfiles that have the same bfd).
There is one thing I wonder though, maybe I'm missing something. If
the BFD doesn't require relocation, get_objfile_bfd_data stores the
newly allocated object in objfiles_bfd_data, so we can assume that
objfiles_bfd_data is the owner of the object. When the bfd's refcount
drops to 0, the corresponding objfile_per_bfd_storage object in
objfiles_bfd_data is deleted.
But if the BFD requires relocation, get_objfile_bfd_data returns a newly
allocated object that isn't kept anywhere else (and isn't shared). So
the objfile becomes the owner of the objfile_per_bfd_storage object. In
objfile::~objfile, we have this:
if (obfd)
gdb_bfd_unref (obfd);
else
delete per_bfd;
I'm thinking that obfd could be non-nullptr, and it could require
relocation. In that case, it would never be freed. Anyway, that's not
really connected to this patch.
Simon Marchi [Fri, 2 Apr 2021 15:45:25 +0000 (11:45 -0400)]
gdb: pass objfile_per_bfd_storage instead of objfile to partial_symtab
Since partial_symtab is supposed to be objfile-independent (since series
[1]), I think it would make sense for partial_symtab to not take an
objfile as a parameter in its constructor.
This patch replaces that parameter with an objfile_per_bfd_storage
parameter.
The objfile is used for two things:
- to get the objfile_name, for debug messages. We can get that name
from the bfd instead.
- to intern the partial symtab filename. Even though it goes through
an objfile method, the request is actually forwarded to the
underlying objfile_per_bfd_storage. So we can ask the new
objfile_per_bfd_storage instead.
In order to get a reference to the BFD from the objfile_per_bfd_storage,
the BFD is saved in the objfile_per_bfd_storage object.
Simon Marchi [Fri, 2 Apr 2021 15:23:52 +0000 (11:23 -0400)]
gdb: add intern methods to objfile_per_bfd_storage
This allows keeping the objfile_per_bfd_storage implementation details
into objfile_per_bfd_storage, instead of into objfile. And this makes
the intern methods usable for code that only has an
objfile_per_bfd_storage to work with.
gdb/ChangeLog:
* objfiles.h (struct objfile_per_bfd_storage) <intern>: New
methods.
(struct objfile) <intern>: Use
objfile::objfile_per_bfd_storage::intern.
Add the `is_flag_enum` and `set_is_flag_enum` methods on `struct type`,
in order to remove the `TYPE_FLAG_ENUM` macro. In this patch, the macro
is changed to use the getter, so all the call sites of the macro that
are used as a setter are changed to use the setter method directly. The
next patch will remove the macro completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <is_flag_enum,
set_is_flag_enum>: New methods.
(TYPE_FLAG_ENUM): Use type::is_flag_enum, change all
write call sites to use type::set_is_flag_enum.
Add the `is_declared_class` and `set_is_declared_class` methods on
`struct type`, in order to remove the `TYPE_DECLARED_CLASS` macro. In
this patch, the macro is changed to use the getter, so all the call
sites of the macro that are used as a setter are changed to use the
setter method directly. The next patch will remove the macro
completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <is_declared_class,
set_is_declared_class>: New methods.
(TYPE_DECLARED_CLASS): Use type::is_declared_class, change all
write call sites to use type::set_is_declared_class.
Boris Staletic [Thu, 1 Apr 2021 18:09:27 +0000 (12:09 -0600)]
Use importlib instead of imp module on python 3.4+
Python 3.4 has deprecated the imp module in favour of importlib. This
patch avoids the DeprecationWarning. This warning is visible to users
whose libpython.so has been compiled with --with-pydebug.
Considering that even python 3.5 has reached end of life, would it be
better to just use importlib and drop support for python 3.0 to 3.3?
2021-02-28 Boris Staletic <boris.staletic@gmail.com>
* gdb/python/lib/gdb/__init__.py: Use importlib on python 3.4+
to avoid deprecation warnings.
Tamar Christina [Thu, 1 Apr 2021 16:10:38 +0000 (17:10 +0100)]
PE/Windows x86_64: Fix weak undef symbols after image base change
The change in PR19011 changed the image load address from being in the lower
32-bit address space to the higher 64-bit address space.
However when you have a weak undef symbol which stays undef at the end of
linking the linker has to resolve this (Windows loader does not support undef
symbols). As such typically these would resolve to 0.
The relocation used for these weak symbols are the normal 32-bit PC_REL call
relocs. So when doing the overflow check LD checks if the distance between the
symbol and the call is within range. However now that the load address is
> 32-bits and the symbol val is 0 this overflow check will always fail.
As such the linker gives a bogus error. This patch makes the linker not emit
the overflow failure but chooses to still let the check be performed (as it's
mid-end code).
One down side of this is that it does break the common convention that the call
be to sym at 0x0. i.e. before you'd get
401015: 74 05 je 40101c
401017: e8 e4 ef bf ff callq 0
since the call is PC_REL there's no way to get the range large enough to
resolve to 0. As such I have chosen to leave it as the furthest simple range
that we can still represent.
By only ignoring the error we leave the symbol value itself to still be 0
such that the if(<symbol>) checks still work correctly.
bfd/ChangeLog:
2021-04-01 Tamar Christina <tamar.christina@arm.com>
Martin Liska [Thu, 1 Apr 2021 05:17:14 +0000 (07:17 +0200)]
Fix microblaze sim build error
I see the following error for --target=microblaze-elf:
../../../sim/microblaze/interp.c: In function 'sim_engine_run':
../../../sim/microblaze/interp.c:147:39: error: passing argument 2 of 'get_insn_microblaze' from incompatible pointer type [-Werror=incompatible-pointer-types]
147 | op = get_insn_microblaze (inst, &imm_unsigned, &insn_type,
| ^~~~~~~~~~~~~
| |
| int *
In file included from ../../bfd/bfd.h:45,
from ../../../sim/microblaze/interp.c:24:
../../../sim/microblaze/../../opcodes/microblaze-dis.h:34:57: note: expected '_Bool *' but argument is of type 'int *'
34 | extern enum microblaze_instr get_insn_microblaze (long, bool *,
| ^
sim/microblaze/ChangeLog:
* interp.c (sim_engine_run): Use bool instead of int.
Tom de Vries [Thu, 1 Apr 2021 06:24:13 +0000 (08:24 +0200)]
[gdb/testsuite] Fix unset of DEBUGINFOD_URLS in default_gdb_init
In commit cfcbd506fb0 "[gdb/testsuite] Ignore DEBUGINFOD_URLS" I added
unsetting of env(DEBUGINFOD_URLS), but it doesn't work because I forgot to
add :: in front.
Fix this, and rewrite using "unset -nocomplain" instead of unsetenv, which
allows us to drop the "info exists" test.
2021-04-01 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (default_gdb_init): Use ::env. Use unset
-nocomplain ::env(V) instead of unsetenv V.
Tom Tromey [Thu, 1 Apr 2021 00:28:28 +0000 (18:28 -0600)]
Remove two trivial functions from dwarf2/read.c
This removes dw2_map_matching_symbols and dw2_expand_symtabs_matching,
merging them with their sole trivial callers.
gdb/ChangeLog
2021-03-31 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf2_gdb_index::map_matching_symbols): Merge
with dw2_map_matching_symbols.
(dwarf2_gdb_index::expand_symtabs_matching): Merge with
dw2_expand_symtabs_matching.
Tom Tromey [Wed, 31 Mar 2021 15:17:23 +0000 (09:17 -0600)]
Add some error checking to DWARF assembler
I had written a DWARF location expression like
DW_OP_const1u
DW_OP_stack_value
... and was surprised to see that the DW_OP_stack_value didn't appear
in the "readelf" output.
The problem here is that DW_OP_const1u requires an operand, but
neither the DWARF assembler nor gas diagnosed this problem.
This patch adds some checking to Dwarf::_location to try to avoid this
in the future. The checking is done via a helper proc that also
dissects the argument list and sets an array in the caller's frame.
gdb/testsuite/ChangeLog
2021-03-31 Tom Tromey <tromey@adacore.com>
* lib/dwarf.exp (Dwarf::_get_args): New proc.
(Dwarf::_location): Use it.
Tom de Vries [Wed, 31 Mar 2021 13:17:19 +0000 (15:17 +0200)]
[gdb/testsuite] Ignore DEBUGINFOD_URLS
On openSUSE Tumbleweed, DEBUGINFOD_URLS is now defined by default:
...
$ echo $DEBUGINFOD_URLS
https://debuginfod.opensuse.org/
...
With DEBUGINFOD_URLS defined we run into:
...
FAIL: gdb.mi/mi-sym-info.exp: List all functions from debug information only \
(timeout)
...
as reported in PR27667.
There's a latency of ~0.5s per request, which is ok-ish for interactive usage.
But the symbol-info-functions command ends up issuing 21 source requests,
which means we easily run into the 10s timeout.
Fix this by unsetting DEBUGINFOD_URLS in default_gdb_init.
Alan Modra [Tue, 30 Mar 2021 23:32:08 +0000 (10:02 +1030)]
Include string.h in bfd.h and delete LITMEMCPY, LITSTRCPY
This fixes the issue that startswith depends on strncpy being
declared, and not all projects using bfd.h include string.h before
bfd.h. I've also deleted some macros that don't find much use
anywhere.
bfd/
* bfd-in.h: Include string.h.
(LITMEMCPY, LITSTRCPY): Delete.
* bfd-in2.h: Regenerate.
binutils/
* prdbg.c (pr_function_type): Replace LITSTTCPY with strcpy.
This is a recurring problem that exposes a design issue in the DWARF
per-BFD sharing feature. Things work well when loading a binary with
the same method (with/without index, with/without readnow) twice in a
row. But they don't work so well when loading a binary with different
methods. See this previous fix, for example:
efb763a5ea35 ("gdb: check for partial symtab presence in dwarf2_initialize_objfile")
That one handled the case where the first load is normal (uses partial
symbols) and the second load uses an index.
The problem is that when loading an objfile with a method A, we create a
dwarf2_per_bfd and some dwarf2_per_cu_data and initialize them with the
data belonging to that method. When loading another obfile sharing the
same BFD but with a different method B, it's not clear how to re-use the
dwarf2_per_bfd/dwarf2_per_cu_data previously created, because they
contain the data specific to method A.
I think the most sensible fix would be to not share a dwarf2_per_bfd
between two objfiles loaded with different methods. That means that two
objfiles sharing the same BFD and loaded the same way would share a
dwarf2_per_bfd. Two objfiles sharing the same BFD but loaded with
different methods would use two different dwarf2_per_bfd structures.
However, this isn't a trivial change. So to fix the known issue quickly
(including in the gdb 10 branch), this patch just disables all
dwarf2_per_bfd sharing for objfiles using READNOW.
Generalize the gdb.base/index-cache-load-twice.exp test to test all
the possible combinations of loading a file with partial symtabs, index
and readnow. Move it to gdb.dwarf2, since it really exercises features
of the DWARF reader.
gdb/ChangeLog:
PR gdb/27541
* dwarf2/read.c (dwarf2_has_info): Don't share dwarf2_per_bfd
with objfiles using READNOW.
Tom de Vries [Tue, 30 Mar 2021 13:16:26 +0000 (15:16 +0200)]
[gdb/testsuite] Add missing .debug_abbrev terminator in dw2-cu-size.S
Since commit 27012aba8a6 "Remove Irix 6 workaround from DWARF abbrev reader"
we have:
...
(gdb) file dw2-cu-size^M
Reading symbols from dw2-cu-size...^M
DW_FORM_strp pointing outside of .debug_str section [in module dw2-cu-size]^M
(No debugging symbols found in dw2-cu-size)^M
(gdb) ptype noloc^M
No symbol table is loaded. Use the "file" command.^M
(gdb) FAIL: gdb.dwarf2/dw2-cu-size.exp: ptype noloc
...
The problem is a missing .debug_abbrev terminator in dw2-cu-size.S, which
causes the .debug_abbrev contribution to be merged with the next:
...
Number TAG (0x9b)
1 DW_TAG_compile_unit [has children]
DW_AT_name DW_FORM_string
DW_AT_producer DW_FORM_string
DW_AT_language DW_FORM_data1
DW_AT value: 0 DW_FORM value: 0
2 DW_TAG_variable [no children]
DW_AT_name DW_FORM_string
DW_AT_type DW_FORM_ref4
DW_AT_external DW_FORM_flag
DW_AT value: 0 DW_FORM value: 0
3 DW_TAG_base_type [no children]
DW_AT_name DW_FORM_string
DW_AT_byte_size DW_FORM_data1
DW_AT_encoding DW_FORM_data1
DW_AT value: 0 DW_FORM value: 0
4 DW_TAG_const_type [no children]
DW_AT_type DW_FORM_ref_udata
DW_AT value: 0 DW_FORM value: 0
1 DW_TAG_compile_unit [has children]
DW_AT_producer DW_FORM_strp
DW_AT_language DW_FORM_data1
DW_AT_name DW_FORM_strp
DW_AT_comp_dir DW_FORM_strp
DW_AT_low_pc DW_FORM_addr
DW_AT_high_pc DW_FORM_data8
DW_AT_stmt_list DW_FORM_sec_offset
DW_AT value: 0 DW_FORM value: 0
...
and consequently, abbreviation code 1 no longer refers to a unique entry.
The eventually causes us to access the first attribute of this DIE:
...
<0><124>: Abbrev Number: 1 (DW_TAG_compile_unit)
<125> DW_AT_name : file1.txt
<12f> DW_AT_producer : GNU C 3.3.3
<13b> DW_AT_language : 1 (ANSI C)
...
which has form DW_FORM_string, using DW_FORM_strp.
Fix this by adding the missing .debug_abbrev terminator in dw2-cu-size.S.
Luis Machado [Mon, 29 Mar 2021 16:48:43 +0000 (13:48 -0300)]
Fix inverted logic bug
During reviews, I changed the success/failure variables from int to bool, but
missed updating the code in a couple spots. Given the logic inversion, the
gdbserver code fails instead of succeeding.
Fixed with the following patch. Seems fairly obvious, so I'll push it soon.
gdbserver/ChangeLog:
2021-03-30 Luis Machado <luis.machado@linaro.org>
* server.cc (handle_general_set, handle_query): Update variable
to bool and fix verification logic.
Jan Beulich [Tue, 30 Mar 2021 12:08:48 +0000 (14:08 +0200)]
x86: drop REGNAM_{AL,AX,EAX}
The former two are unused anyway. And having such constants isn't very
helpful either, when they live in a place where updating the register
table wouldn't even allow noticing the need to adjust these constants.
Jan Beulich [Tue, 30 Mar 2021 12:08:11 +0000 (14:08 +0200)]
x86: adjust st(<N>) parsing
st(1) ... st(7) will never be looked up in the hash table, so there's no
point inserting the entries. It's also not really necessary to do a 2nd
hash lookup after parsing the register number, nor is there a real
reason for having both st and st(0) entries. Plus we can easily do away
with the need for st to be first in the table.
Jan Beulich [Tue, 30 Mar 2021 12:06:37 +0000 (14:06 +0200)]
x86: integrate rc_op into struct _i386_insn
There's no need for the extra level of indirection and the extra storage
needed for the pointer, pointing from one piece of static data to
another. Key checking of rounding being in effect off of the type field
of the structure instead.
Jan Beulich [Tue, 30 Mar 2021 12:06:09 +0000 (14:06 +0200)]
x86: integrate broadcast_op into struct _i386_insn
There's no need for the extra level of indirection and the extra storage
needed for the pointer, pointing from one piece of static data to
another. Key checking of broadcast being in effect off of the type field
of the structure instead.
Jan Beulich [Tue, 30 Mar 2021 12:05:42 +0000 (14:05 +0200)]
x86: integrate mask_op into struct _i386_insn
There's no need for the extra level of indirection and the extra storage
needed for the pointer, pointing from one piece of static data to
another. Key checking of masking being in effect off of the register
field of the structure instead.
Jan Beulich [Tue, 30 Mar 2021 12:05:10 +0000 (14:05 +0200)]
x86: make swap_2_operands() have unsigned parameters
All callers pass unsigned values (in some cases by virtue of passing
non-negative literal numbers).
This in turn requires struct {Mask,RC,Broadcast}_Operation's "operand"
fields to become unsigned, in turn allowing to reduce the amount of
casting needed (the two new casts that are necessary cast _to_
"unsigned" instead of _from_, as that's the form that'll never case
undefined behavior).
Alan Modra [Tue, 30 Mar 2021 02:33:30 +0000 (13:03 +1030)]
asan: linker.c:2294:8: runtime error: load of value 253
Seen after converting bfd_boolean to bool.
mmix +FAIL: ld-mmix/zeroehmmo
./ld-new -L/home/alan/src/binutils-gdb/ld/testsuite/ld-mmix -m mmo -Ttext 0xa00 -T /home/alan/src/binutils-gdb/ld/testsuite/ld-mmix/zeroeh.ld -o tmpdir/dump tmpdir/x.o tmpdir/y.o
/home/alan/src/binutils-gdb/bfd/linker.c:2294:8: runtime error: load of value 253, which is not a valid value for type '_Bool'
* elflink.c (elf_link_add_object_symbols): Don't set h->indx
unless is_elf_hash_table.
Alan Modra [Tue, 30 Mar 2021 01:55:03 +0000 (12:25 +1030)]
PR27625, powerpc64 gold __tls_get_addr calls
This patch supports linking powerpc64 glibc with gold, specifically
the __tls_get_addr call in elf/dl-sym.c. That call lacks marker
relocations tying it to the arg setup instructions, but the arg setup
insns are also contructed lacking the usual relocations on a Global
Dynamic TLS code sequence. So there is no chance that anything in
that sequence might be wrongly edited by the linker.
In fact, the aim of linking glibc could have been supported by simply
omitting the error whenever TLS optimisation is disabled, as it is
when linking a shared library. The patch goes further than that,
disabling TLS GD and LD sequence optimisation on a per-object basis
for object files lacking marker relocs.
PR gold/27625
* powerpc.cc (Powerpc_relobj): Add no_tls_marker_, tls_marker_,
and tls_opt_error_ variables and accessors.
(Target_powerpc::Scan::local, global): Call set_tls_marker and
set_no_tls_marker for GD and LD code sequence relocations.
(Target_powerpc::Relocate::relocate): Downgrade the "lacks marker
reloc" error to a warning when safe to do so, and omit the error
entirely if not optimising TLS sequences. Do not optimise GD and
LD sequences for objects lacking marker relocs.
(Target_powerpc::relocate_relocs): Heed no_tls_marker here too.
Luis Machado [Wed, 24 Mar 2021 14:12:46 +0000 (11:12 -0300)]
Don't pass empty options to GCC
On aarch64-linux, I noticed the compile command didn't work at all. It
always gave the following error:
aarch64-linux-gnu-g++: error: : No such file or directory
Turns out we're passing an empty argv entry to GCC (because aarch64 doesn't
have a -m64 option), and GCC's behavior is to think that is a file it needs
to open. One can reproduce it like so:
gcc "" "" "" ""
gcc: error: : No such file or directory
gcc: error: : No such file or directory
gcc: error: : No such file or directory
gcc: error: : No such file or directory
gcc: fatal error: no input files
compilation terminated.
The solution is to check for an empty string and skip adding that to argv.
Regression tested on aarch64-linux/Ubuntu 18.04/20.04.
Luis Machado [Fri, 26 Mar 2021 12:37:56 +0000 (09:37 -0300)]
Fix memory tagging section type
It was reported to me that on Ubuntu 14.04 (fairly old) the documentation
fails to build with the following:
gdb/doc/gdb.texinfo:10888: warning: node `Memory' is up for `Memory Tagging' in sectioning but not in menu
gdb/doc/gdb.texinfo:10693: node `Memory' lacks menu item for `Memory Tagging' despite being its Up target
Makefile:491: recipe for target 'gdb.info' failed
make[3]: *** [gdb.info] Error 1
This doesn't seem to happen on Ubuntu 18.04/20.04, but it does make sense.
Fix this by turning @subsection into a @section and adding the
"Memory Tagging" entry to the menu.
gdb/doc/ChangeLog:
2021-03-29 Luis Machado <luis.machado@linaro.org>
* gdb.textinfo (Memory Tagging): Make it a @section.
So, the real loop is the instruction at address 0x4004d9. But a
breakpoint that's defined at the loop line (assume line 30 in this
case) is inserted at address 0x4004d4.
(gdb) break 30
Breakpoint 1 at 0x4004d4: file test.c, line 30.
Therefore, continuing a thread that was spinning on the loop does not hit
the breakpoint. The bug is reported at
https://bugs.llvm.org/show_bug.cgi?id=49614
Tweak the infinite loop to spin on a variable to avoid this bug. The
test is unrelated to the bug.
gdb/testsuite/ChangeLog:
2021-03-29 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.mi/user-selected-context-sync.exp: Spin on a variable in
the infinite loop to avoid a Clang bug.
Rainer Orth [Mon, 29 Mar 2021 11:26:35 +0000 (13:26 +0200)]
Restore procfs.c compilation
Since c8fbd44a018a9923f906bfd2be5489caa87b602a (gdb: remove
target_is_pushed free function), procfs.c compilation is broken, which
went unnoticed for lack of functioning buildbots:
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function 'virtual void procfs_target::attach(const char*, int)':
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:1772:8: error: 'inf' was not declared in this scope; did you mean 'info'?
1772 | if (!inf->target_is_pushed (this))
| ^~~
| info
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function 'virtual void procfs_target::create_inferior(const char*, const string&, char**, int)':
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2865:8: error: 'inf' was not declared in this scope; did you mean 'info'?
2865 | if (!inf->target_is_pushed (this))
| ^~~
| info
Fixed by defining inf. Tested on amd64-pc-solaris2.11 and
sparcv9-sun-solaris2.11.
Jan Beulich [Mon, 29 Mar 2021 10:06:43 +0000 (12:06 +0200)]
x86: move some opcode table entries
For a long time there hasn't been a need anymore to keep together all
templates with identical mnemonics. Move the MOVQ and MOVABS ones next
to their MOV counterparts. Move the string forms of CMPSD and MOVSD next
to their CMPS / MOVS counterparts. Re-arrange what so fgar was the SSE3
section.
This makes reasonably obvious that MONITOR/MWAIT aren't suitable to
cover by CpuSSE3, but adjusting this is left for another time.
Jan Beulich [Mon, 29 Mar 2021 10:06:09 +0000 (12:06 +0200)]
x86: VPSADBW's source operands are also commutative
In commit 79dec6b7baa2 ("x86-64: optimize certain commutative
VEX-encoded insns") I missed the fact that there being subtraction
involved here doesn't matter, as absolute differences get summed up.
Jan Beulich [Mon, 29 Mar 2021 10:05:25 +0000 (12:05 +0200)]
x86: fold SSE2AVX and their base MMX/SSE templates
This way not only the overall (source) table size shrinks by quite a
bit and the risk of related templates going out of sync with one another
gets lowered, but also (dis)similarities between neighboring templates
become easier to spot.
Note that for certain SSE2AVX templates this results in benign attribute
changes:
- LDMXCSR and STMXCSR: NoAVX gets set,
- MOVMSKPS, PMOVMSKB, PEXTR{B,W} (register destination), and PINSR{B,W}
(register source): IgnoreSize and NoRex64 get set,
- CVT{DQ,PS}2PD, CVTSD2SS, MOVMSKPD, MOVDDUP, PMOV{S,Z}X{BW,WD,DQ}, and
ROUNDSD: NoRex64 gets set,
- CVTSS2SD, INSERTPS, PEXTRW (memory destination), PINSRW (memory
source), and PMOV{S,Z}X{BD,WQ,BQ}: IgnoreSize gets set.
Similarly the "normal" (non-SSE2AVX)
- non-64-bit CVTS{I,S}2SD forms get NoRex64 set,
- CMP{EQ,ORD,NEQ,UNORD}{P,S}{S,D} forms get C set,
all again in a benign way.
The remaining differences in the generated table are due to re-ordering
of entries in the course of being folded into templates.
Jan Beulich [Mon, 29 Mar 2021 10:04:03 +0000 (12:04 +0200)]
x86: undo Prefix_0X<nn> use in opcode table
The table entries are more natural to read (and slightly shorter) when
the prefixes, like is the case for VEX/XOP/EVEX-encoded entries, are
specified as part of the opcode. This is particularly noticable for
side-by-side legacy and SSE2AVX entries.
An implication is that we now need to use "unsigned long long" for the
initially parsed opcode in i386-gen. I don't expect this to be an issue.
Jan Beulich [Mon, 29 Mar 2021 10:03:31 +0000 (12:03 +0200)]
x86: shrink some struct insn_template fields
Now that all base opcodes are only at most 2 bytes in size, shrink its
template field to just as much. By also shrinking extension_opcode and
operands to just what they really need, we can free up an entire 32-bit
slot (plus 4 left bits past the bitfields themselves).
At present this alters sizeof(struct insn_template) only for 32-bit
builds. In 64-bit builds it instead leaves a padding hole that will
allow to buffer future growth of other fields (opcode_modifier,
cpu_flags, operand_types[]).
Jan Beulich [Mon, 29 Mar 2021 10:02:50 +0000 (12:02 +0200)]
x86: derive opcode encoding space attribute from base opcode
Just like is already done for VEX/XOP/EVEX encoded insns, record the
encoding space information in the respective opcode modifier field. Do
this again without changing the source table, but rather by deriving the
values from their existing source representation.
Alan Modra [Sun, 28 Mar 2021 23:22:56 +0000 (09:52 +1030)]
TRUE/FALSE simplification
There is really no need to write code like "foo != 0 ? TRUE : FALSE"
unless we had stupidly defined FALSE as something other than 0 or TRUE
as something other than 1. The simpler "foo != 0" does just as well.
Similarly "(condition == TRUE)" or "(condition == FALSE) can be
simplified to "(condition)" and "(!condition)" respectively.
I'll note that there is reason to use "integer_expression != 0" when
assigning a bfd_boolean rather than the simpler "integer_expression",
if you expect the variable to have 0 or 1 value. It's probably even a
good idea to not rely on implicit conversion if bfd_boolean were _Bool.
Alan Modra [Sun, 28 Mar 2021 23:17:16 +0000 (09:47 +1030)]
binutils int vs bfd_boolean fixes
* objdump.c (process_links): Use type int.
* readelf.c (request_dump): Don't increment do_dump, set it.
* windint.h (target_is_bigendian): Use type bfd_boolean.
* windmc.c (target_is_bigendian): Likewise.
* windres.c (target_is_bigendian): Likewise.
Alan Modra [Sun, 28 Mar 2021 23:11:01 +0000 (09:41 +1030)]
hash table iterator callback functions int vs. bfd_boolean
Correct return type of callbacks invoked by htab_traverse and other
hashtab.h functions to int, and one case of a callback invoked by
elf_link_hash_traverse to bfd_boolean.
Alan Modra [Sun, 28 Mar 2021 23:09:15 +0000 (09:39 +1030)]
ELF output symbol hooks int vs. bfd_boolean
elf_backend_link_output_symbol_hook and elf_link_output_symstrtab may
return 2 when a symbol is to be discarded. Update places that use
bfd_boolean rather than int for these functions.
* elflink.c (elf_link_output_symstrtab): Make flinfo parameter
a void pointer.
(bfd_elf_final_link): Delete out_sym_func typedef and don't cast
elf_link_output_symstrtab when calling output_arch_syms and
output_arch_local_syms.
* elf-bfd.h (struct elf_backend_data <elf_backend_output_arch_syms,
elf_backend_output_arch_local_syms>): Change return type of func
arg to match elf_link_output_symstrtab.
* elf-vxworks.h (elf_vxworks_link_output_symbol_hook): Correct
return type.
* elf32-nds32.c (nds32_elf_output_symbol_hook): Correct return type.
(nds32_elf_output_arch_syms): Correct func return type.
Alan Modra [Sun, 28 Mar 2021 23:08:15 +0000 (09:38 +1030)]
elf_backend_relocate_section int vs. bfd_boolean
This functions was changed to return an int in commit ece5ef60797f but
since bfd_boolean was an int typedef I lazily left all the ELF
relocate_section functions as returning bfd_boolean, except the SPU
one. In order to use _Bool or bool in place of bfd_boolean we need to
be fussy about the return types.
Tom Tromey [Sun, 28 Mar 2021 16:43:15 +0000 (10:43 -0600)]
Simplify DWARF reader initialization
Now that the quick functions are separate from the object file format,
there's no need to have elfread.c push a new entry on the objfile 'qf'
list. Instead, this detail can be pushed into the DWARF reader. That
is what this patch implements.
I wasn't sure whether lazy reading still makes sense or not. It's
still only used by ELF, and only in certain situations (like vfork, I
think). It may not be carrying its weight, so we may want to consider
removing this in the future.
Also, I'm unclear on why the various indices are only used for ELF.
This seems sub-optimal. However, I haven't tried to address that
here.
gdb/ChangeLog
2021-03-28 Tom Tromey <tom@tromey.com>
* elfread.c (can_lazily_read_symbols): Move to dwarf2/read.c.
(elf_symfile_read): Simplify.
* dwarf2/read.c (struct lazy_dwarf_reader): Move from elfread.c.
(make_lazy_dwarf_reader): New function.
(make_dwarf_gdb_index, make_dwarf_debug_names): Now static.
(dwarf2_initialize_objfile): Return void. Remove index_kind
parameter. Push on 'qf' list.
* dwarf2/public.h (dwarf2_initialize_objfile): Change return
type. Remove 'index_kind' parameter.
(make_dwarf_gdb_index, make_dwarf_debug_names): Don't declare.
Tom Tromey [Sat, 27 Mar 2021 22:41:53 +0000 (16:41 -0600)]
Don't clear 'qf' in elf_symfile_read
I noticed that I forgot to make a change in my series to make it
possible to attach multiple debug readers to an objfile. In one spot,
elf_symfile_read still clears the 'qf' list. However, this should
have been removed toward the end of that series.
This patch fixes the offending spot. Tested on x86-64 Fedora 32.
gdb/ChangeLog
2021-03-27 Tom Tromey <tom@tromey.com>
Will Schmidt [Sat, 27 Mar 2021 14:31:27 +0000 (14:31 +0000)]
gdb/testsuite: make some test names unique in gdb.arch/powerpc-*.exp
Resolve some duplicate test name warnings in gdb.arch/powerpc-*.exp
tests by either extending the existing test names, or providing a new
test name.
gdb/testsuite/ChangeLog:
* gdb.arch/powerpc-disassembler-options.exp: Extend some test
names for uniqueness.
* gdb.arch/powerpc-fpscr-gcore.exp: Add more test names for
uniqueness.
Lancelot SIX [Fri, 26 Mar 2021 16:46:57 +0000 (16:46 +0000)]
gdb-add-index.sh: Remove use of non posix 'local'
While working on gdb-add-index.sh, it appeared that it uses the non
POSIX 'local' keyword. Instead of using local to allow variable
shadowing, I rename the local one to avoid name conflicts altogether.
This commit gets rid of the following shellcheck warning:
In gdb-add-index.sh line 63:
local file="$1"
^--------^ SC2039: In POSIX sh, 'local' is undefined.
gdb/ChangeLog:
* contrib/gdb-add-index.sh: Avoid variable shadowing and get
rid of 'local'.
Tom Tromey [Fri, 26 Mar 2021 19:44:24 +0000 (13:44 -0600)]
Use function view in quick_symbol_functions::map_symbol_filenames
This changes quick_symbol_functions::map_symbol_filenames to use a
function_view, and updates all the uses. It also changes the final
parameter to 'bool'. A couple of spots are further updated to use
operator() rather than a lambda.
gdb/ChangeLog
2021-03-26 Tom Tromey <tom@tromey.com>
* symtab.c (struct output_source_filename_data): Add 'output'
method and operator().
(output_source_filename_data::output): Rename from
output_source_filename.
(output_partial_symbol_filename): Remove.
(info_sources_command): Update.
(struct add_partial_filename_data): Add operator().
(add_partial_filename_data::operator()): Rename from
maybe_add_partial_symtab_filename.
(make_source_files_completion_list): Update.
* symfile.c (quick_symbol_functions): Update.
* symfile-debug.c (objfile::map_symbol_filenames): Update.
* quick-symbol.h (symbol_filename_ftype): Change type of 'fun' and
'need_fullname'. Remove 'data' parameter.
(struct quick_symbol_functions) <map_symbol_filenames>: Likewise.
* psymtab.c (psymbol_functions::map_symbol_filenames): Update.
* psympriv.h (struct psymbol_functions) <map_symbol_filenames>:
Change type of 'fun' and 'need_fullname'. Remove 'data'
parameter.
* objfiles.h (struct objfile) <map_symbol_filenames>: Change type
of 'fun' and 'need_fullname'. Remove 'data' parameter.
* mi/mi-cmd-file.c (print_partial_file_name): Remove 'ignore'
parameter.
(mi_cmd_file_list_exec_source_files): Update.
* dwarf2/read.c
(dwarf2_base_index_functions::map_symbol_filenames): Update.
Tom Tromey [Fri, 26 Mar 2021 19:44:24 +0000 (13:44 -0600)]
Simplify use of map_matching_symbols in ada-lang.c
I noticed that ada-lang.c creates a lambda to call
aux_add_nonlocal_symbols. However, this code can be simplified a bit
by changing match_data to implement operator(), and then simply
passing the object as the callback. That is what this patch
implements.
gdb/ChangeLog
2021-03-26 Tom Tromey <tom@tromey.com>
I noticed that psymbol_functions::expand_symtabs_matching calls
make_ignore_params once per psymtab that is matched. This seems
possibly expensive, so this patch hoists the call out of the loop.
gdb/ChangeLog
2021-03-26 Tom Tromey <tom@tromey.com>
* psymtab.c (psymbol_functions::expand_symtabs_matching): Only
call make_ignore_params once.
Tom Tromey [Fri, 26 Mar 2021 19:28:03 +0000 (13:28 -0600)]
Allow expand_symtabs_matching to examine imported psymtabs
Currently the psymtab variant of expand_symtabs_matching has this
check:
/* We skip shared psymtabs because file-matching doesn't apply
to them; but we search them later in the loop. */
if (ps->user != NULL)
continue;
In a larger series I'm working on, it's convenient to remove this
check. And, I noticed that a similar check is not done for
expand_symtabs_with_fullname. So, it made sense to me to remove the
check here as well.
gdb/ChangeLog
2021-03-26 Tom Tromey <tom@tromey.com>