There are a number of issues with 734dfd1cc966 ("x86: pack CPU flags in
opcode table"):
- the condition when two array slots need writing wasn't correct (with
enough new Cpu* added an out of bounds array access would validly have
been complained about by the compiler),
- table generation didn't take into account CpuAttrUnused and CpuUnused
being independent, and hence there not always (not) being an "unused"
bitfield member in both structures,
- cpu_flags_from_attr() wasn't ready for use on big-endian hosts,
- there were two style violations.
Various targets have / had overrides for .bss. Make sure that in such
cases
- .previous still works correctly (requiring such targets to invoke
obj_elf_section_change_hook() from their overriding handlers),
- sub-section specifiers are accepted as far as feasible (mandated by
the doc).
It doesn't look to be a good idea to override the custom handlers that
ELF and COFF have; afaict doing so broke .previous on ELF, and a sub-
section specifier wasn't accepted either.
The comment in s_bss() looks bogus (perhaps simply stale, or wrongly
copied from another target). It also doesn't look to be a good idea to
override the custom handler that ELF has (afaict doing so broke
.previous as well as sub-section specification).
The override for .skip is simply pointless, for read.c having exactly
the same.
While there also drop two adjacent redundant (with read.h) declarations
(which would be outright dangerous if read.h wasn't included anyway).
While there doesn't look to be anything wrong with this override,
there's also no apparent reason why this override would be needed. Drop
it, reducing overall size a tiny bit.
The comment looks bogus (perhaps simply stale, or wrongly copied from
another target). It also doesn't look to be a good idea to override the
custom handler that ELF has (afaict doing so broke .previous as well as
sub-section specification).
While there also fold the identical handlers for .text (there likely is
more room for such folding).
The comment looks bogus (perhaps simply stale), and there are also no
other precautions against subsections being used on ELF with .bss. It
also doesn't look to be a good idea to override the custom handler that
ELF has (afaict doing so further broke .previous).
While only ELF is supported right now, (stub) code generally is in place
for the non-ELF case as well. Don't override .bss for ELF - that's
unlikely to be a good idea anyway and prevented the sub-section
specifier from being usable. Don't override .text and .data at all - for
.data and ELF for the same reason, while for .text and ELF obj-elf.c's is
all we need, and for (hypothetical) non-ELF read.c's identical handling
would have been invoked anyway.
The comment looks bogus (perhaps simply stale), and there are also no
other precautions against subsections being used on ELF with .bss. It
also doesn't look to be a good idea to override the custom handler that
ELF has (afaict doing so further broke .previous).
It doesn't look to be a good idea to override the custom handlers that
ELF and COFF have. While in this case interaction with ELF's .previous
wasn't screwed, the sub-section specifier wasn't permitted.
The comment looks bogus (perhaps simply stale, perhaps wrongly copied
from Arm in the first place), and there are also no other precautions
against subsections being used on ELF with .bss. It also doesn't look
to be a good idea to override the custom handlers that ELF and COFF
have (afaict doing so further broke .previous on ELF).
As to the mapping state update - such also doesn't appear to be done
for other section switching, so its original purpose was at best
questionable as well.
The comment looks bogus (perhaps simply stale), and there are also no
other precautions against subsections being used on ELF with .bss. It
also doesn't look to be a good idea to override the custom handlers that
ELF and COFF have (afaict doing so further broke .previous on ELF).
The attempt in 5e9091dab885 to correct gold for modern LLVM has broken
gold for older compilers. This commit introduced C++11 types without
changing the build system to require a C++ compiler. More importantly
it depends on the compiler having at least C++11 as the default
language. Older compilers which support C++11 but not as the default
language needlessly break. Fix that.
PR gold/30867
* configure.ac (AX_CXX_COMPILE_STDCXX): Require C++11.
* Makefile.in: Regenerate.
* aclocal.m4: Regenerate.
* config.in: Regenerate.
* configure: Regenerate.
* testsuite/Makefile.in: Regenerate.
In commit 83c79df86bf4 I removed configure tests for strtoull among
other library functions part of C99, but didn't remove what is now
dead code.
* bfd.c (bfd_scan_vma): Delete fall-back for strtoull.
The ld lexer converts strings to integers without overflow checking,
so I don't think there is any problem in truncating an integer that
exceeds the size of a bfd_vma rather than using (bfd_vma) -1.
PR 31120
* ldlex.l: Don't use bfd_scan_vma for integer conversion, use
strtoull.
Since the particularity of "th.vsetvli" was not taken into account in the
initial support patches for XTheadVector, the program operation failed
due to instruction coding errors. According to T-Head SPEC ([1]), the
"vsetvl" in the XTheadVector extension consists of SEW, LMUL and EDIV,
which is quite different from the "V" extension. Therefore, we cannot
simply reuse the processing of vsetvl in V extension.
We have set up tens of thousands of test cases to ensure that no
further encoding issues are there, and and execute all compiled test
files on real HW and make sure they don't trigger SIGILL.
Ref:
[1] https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
gas/ChangeLog:
* config/tc-riscv.c (validate_riscv_insn): Add handling for
th.vsetvli.
(my_getThVsetvliExpression): New function.
(riscv_ip): Likewise.
* testsuite/gas/riscv/x-thead-vector.d: Likewise.
* testsuite/gas/riscv/x-thead-vector.s: Likewise.
include/ChangeLog:
* opcode/riscv.h (OP_MASK_XTHEADVLMUL): New macro.
(OP_SH_XTHEADVLMUL): Likewise.
(OP_MASK_XTHEADVSEW): Likewise.
(OP_SH_XTHEADVSEW): Likewise.
(OP_MASK_XTHEADVEDIV): Likewise.
(OP_SH_XTHEADVEDIV): Likewise.
(OP_MASK_XTHEADVTYPE_RES): Likewise.
(OP_SH_XTHEADVTYPE_RES): Likewise.
opcodes/ChangeLog:
* riscv-dis.c (print_insn_args): Likewise.
* riscv-opc.c: Likewise.
On aarch64-linux, I run into:
...
FAIL: gdb.base/annota1.exp: backtrace from shlibrary (timeout)
...
due to the PAC marker showing up:
...
^Z^Zframe-address^M
0x000000000041025c [PAC]^M
^Z^Zframe-address-end^M
...
In the docs the marker is documented as follows:
...
When GDB is debugging the AArch64 architecture, and the program is using the
v8.3-A feature Pointer Authentication (PAC), then whenever the link register
$lr is pointing to an PAC function its value will be masked. When GDB prints
a backtrace, any addresses that required unmasking will be postfixed with the
marker [PAC]. When using the MI, this is printed as part of the addr_flags
field.
...
Update the test-case to allow the PAC marker.
Likewise in a few other test-cases.
While we're at it, rewrite the affected pattern pat_begin in annota1.exp into
a more readable form. Likewise for the corresponding pat_end.
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR testsuite/31202
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31202
Adds two new external authors to etc/update-copyright.py to cover
bfd/ax_tls.m4, and adds gprofng to dirs handled automatically, then
updates copyright messages as follows:
1) Update cgen/utils.scm emitted copyrights.
2) Run "etc/update-copyright.py --this-year" with an extra external
author I haven't committed, 'Kalray SA.', to cover gas testsuite
files (which should have their copyright message removed).
3) Build with --enable-maintainer-mode --enable-cgen-maint=yes.
4) Check out */po/*.pot which we don't update frequently.
With old "medium" code model, we call a function with a pair of PCALAU12I
and JIRL instructions. The assembler produces something like:
8: 1a00000c pcalau12i $t0, 0
8: R_LARCH_PCALA_HI20 g
c: 4c000181 jirl $ra, $t0, 0
c: R_LARCH_PCALA_LO12 g
The linker generates a "PLT entry" for data without any diagnostic.
If "g" is a data symbol and ld with -shared option, it may load two
instructions in the PLT.
Without -shared option, loongarch_elf_adjust_dynamic_symbol can delete PLT
entry.
For R_LARCH_PCALA_HI20 relocation, linker only generate PLT entry for STT_FUNC
and STT_GNU_IFUNC symbols.
This commits changes how errors are reported from the expression
parser. Previously, parser errors were reported like this:
(gdb) p a1 +}= 432
A syntax error in expression, near `}= 432'.
(gdb) p a1 +
A syntax error in expression, near `'.
The first case is fine, a user can figure out what's going wrong, but
the second case is a little confusing; as the error occurred at the
end of the expression GDB just reports the empty string to the user.
After this commit the first case is unchanged, but the second case now
reports like this:
(gdb) p a1 +
A syntax error in expression, near the end of `a1 +'.
Which I think is clearer. There is a possible issue if the expression
being parsed is very long, GDB will repeat the whole expression. But
this issue already exists in the standard case; if the error occurs
early in a long expression GDB will repeat everything after the syntax
error. So I've not worried about this case in my new code either,
which keeps things simpler.
I did consider trying to have multi-line errors here, in the style
that gcc produces, with some kind of '~~~~~^' marker on the second
line to indicate where the error occurred; but I rejected this due to
the places in GDB where we catch an error and repackage the message
within some longer string, I don't think multi-line error messages
would work well in that case. At a minimum it would require some
significant work in order to make all our error handling multi-line
aware.
I've added a couple of extra tests in gdb.base/exprs.exp.
Approved-By: John Baldwin <jhb@FreeBSD.org>
Many (all?) of the expression parsers implement yyerror to handle
parser errors, and all of these functions are basically identical.
This commit adds a new parser_state::parse_error() function, which
implements the common error handling code, this function can then be
called from all the different yyerror functions.
The benefit of this is that (in a future commit) I can improve the
error output, and all the expression parsers will benefit.
This commit is pure refactoring though, and so, there should be no
user visible changes after this commit.
Approved-By: John Baldwin <jhb@FreeBSD.org>
While working on a later commit in this series I realised that the
error() function doesn't support output styling. Due to the way that
output from error() calls is passed around within the exception
object and often combined with other output, it's not immediately
obvious to me if we should be trying to support styling in this
context or not.
On inspection, I found one place in GDB where we apparently try to
apply styling within the error() output (in procfs.c). I suspect this
error() call might not be tested.
Rather than try to implement styling in the error() output, right now
I'm proposing to just remove the attempt to style error() output.
This doesn't mean that someone shouldn't add error() styling in the
future, but right now, I'm not planning to do that, I just wanted to
fix this in passing.
Approved-By: John Baldwin <jhb@FreeBSD.org>
Suppose we want to use la.got to generate 32 pcrel and
32 abs instruction sequences respectively. According to
the existing conditions, to generate 32 pcrel sequences
use -mabi=ilp32*, and to generate 32 abs use -mabi=ilp32*
and -mla-global-with-abs.
Due to the fact that the conditions for generating 32 abs
also satisfy 32 pcrel, using -mabi=ilp32* and -mla-global-with-abs
will result in only generating instruction sequences of 32 pcrel.
By modifying the conditions for macro expansion and adjusting
the matching order of macro instructions, it is ensured that
the correct sequence of instructions can be generated.
The common igen code was forked from the ppc long ago. The filter
module is still pretty similar in API, so we can unfork them with
a little bit of effort.
The filter.c module is still here because of the unique it_is API.
The common igen code doesn't seem to have an equiv API as this only
operates on two strings and not an actual filter object, and it's
easy enough to leave behind to unfork the rest.
The common igen code was forked from the ppc long ago. The lf module
is still pretty similar in API, so we can unfork them with a little
bit of effort.
Some of the generated ppc code is now slightly different, but that's
because of fixes the common igen code has gained, but not the ppc igen
code (e.g. fixing of #line numbers).
The ppc code retains lf_print__c_code because the common igen code
rewrote the logic to a new table.c API. Let's delay that in the ppc
code to at least unfork all this code.
Add standard multiple inclusion protection, and add a few missing
local includes when one header uses another. This isn't complete,
but fixes some short comings seen when merging the ppc igen.
The common sim-endian is a forked & updated version of the ppc code.
Fortunately, they didn't diverge from the basic APIs, so they are
still compatible, which means we can just delete the ppc version now
that the build env is merged at the top-level.
This is a bit redundant for most ports as they go through sim-basics.h
which always includes sim-types.h before including sim-endian.h, but in
order to unify ppc's sim-endian code, we need this include here. Plus,
it's the directly we generally want to go to get away from one header
that defines all APIs and causes hard to untangle dependencies.
The common/ code has macros with the same name but different behavior:
it's for declaring integer constants as 64-bit, not for casting them.
Rename ppc's local variant since it's only used in this file in order
to avoid conflicts.
