The default memory region sizes for PRU were set somewhat arbitrarily to
the sizes of the most popular BeagleBone board with AM33x SoC. But the
PRU toolchain documentation has always instructed to use SoC-specific
spec files to override the defaults and set the correct memory sizes [1].
The small default memory sizes can cause IMEM memory region overflow
even for simple printf("Hello world") programs, as usually done by
Autotools checks. The stdio is simply too big to fit in 8K
instruction memory. This can confuse the check and lead to wrong
feature selection during configure [2].
Fix by bumping the default DMEM and IMEM memory sizes.
There is no need to backport this patch. Issue was caught with a
feature-rich newlib build used for daily CI. The release builds of the
PRU toolchain use stripped newlib configuration, which does not overflow
the IMEM region, even for 8K.
[1] https://github.com/dinuxbg/gnuprumcu
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115158
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
Introduces instructions for the SVE2 lut extension for AArch64. They are documented in the following links:
* luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en
* luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en
These instructions use new SVE2 vector operands. They are called
SVE_Zm1_23_INDEX, SVE_Zm2_22_INDEX, and Zm3_12_INDEX and they have
1 bit, 2 bit, and 3 bit indices respectively.
The lsb and width of these new operands are the same as many existing
operands but the convention is to give different names to fields that
serve different purpose so we introduced new fields in aarch64-opc.c
and aarch64-opc.h.
We made a design choice for the second operand of the halfword variant of
luti4 with two register tables. We could have either defined a new operand,
like SVE_Znx2, or we could have use the existing operand SVE_ZnxN. With
the new operand, we would need to implement constraints on register
lists based on either operand or opcode flag. With existing operand, we
could just existing constraint checks using opcode flag. We chose
the second approach and went with SVE_ZnxN and added opcode flag to
enforce lengths of vector register list operands. This way, we can reuse
the existing constraint check logic.
Introduces instructions for the Advanced SIMD lut extension for AArch64. They are documented in the following links:
* luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en
* luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en
These instructions needed definition of some new operands. We will first
discuss operands for the third operand of the instructions and then
discuss a vector register list operand needed for the second operand.
The third operands are vectors with bit indices and without type
qualifiers. They are called Em_INDEX1_14, Em_INDEX2_13, and Em_INDEX3_12
and they have 1 bit, 2 bit, and 3 bit indices respectively. For these
new operands, we defined new parsing case branch. The lsb and width of
these operands are the same as many existing but the convention is to
give different names to fields that serve different purpose so we
introduced new fields in aarch64-opc.c and aarch64-opc.h for these new
operands.
For the second operand of these instructions, we introduced a new
operand called LVn_LUT. This represents a vector register list with
stride 1. We defined new inserter and extractor for this new operand and
it is encoded in FLD_Rn. We are enforcing the number of registers in the
reglist using opcode flag rather than operand flag as this is what other
SIMD vector register list operands are doing. The disassembly also uses
opcode flag to print the correct number of registers.
This changes target_ops::thread_events and target_thread_events to use
'bool'. The callers were already doing this.
Tested by rebuilding.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The autogenerated files in opcodes use spaces for indentation.
Changing that would be a lot of work to little benefit, so add a local
override to the white-space rules, so patches apply cleanly.
The type U RISC-V instruction format in gas/doc/c-riscv.texi shows the
bit arrangement of the simm20 immediate that belongs to the J type;
It should be just `simm20[19:0]`. The current behavior of `gas` matches
the proposed documentation change.
Additionally, the opcode is called `opcode6` despite of having 7 bits.
Rename it to `opcode7`.
gas/
* doc/c-riscv.texi: Fix U type, and replace opcode6 with opcode7.
This was originally reported by Hau Hsu <hau.hsu@sifive.com>.
Similar to commit 51a8a7c2e3
We shouldn't use riscv_elf_append_rela to add dynamic relocs into .rela.iplt
in the riscv_elf_relocate_section when handling ifunc data reloc R_RISCV_32/64.
This just like what did in the riscv_elf_finish_dynamic_symbol.
bfd/
* elfnn-riscv.c (riscv_elf_relocate_section): We shouldn't use
riscv_elf_append_rela to add dynamic relocs into .rela.iplt in the
riscv_elf_relocate_section when handling ifunc data reloc.
ld/
* testsuite/ld-riscv-elf/ifunc-overwrite.s: Updated and renamed.
* testsuite/ld-riscv-elf/ifunc-overwrite-exe.rd: Likewise.
* testsuite/ld-riscv-elf/ifunc-overwrite-pic.rd: Likewise.
* testsuite/ld-riscv-elf/ifunc-overwrite-pie.rd: Likewise.
* testsuite/ld-riscv-elf/ifunc-overwrite.d: Renamed.
This was originally reported by Ard Biesheuvel <ardb@kernel.org>.
The followings are reproduce steps,
https://lore.kernel.org/all/202404260640.9GQVTmrw-lkp@intel.com/T/#u
The segment fault happens in the riscv_elf_finish_dynamic_sections when the
output got section is an ABS. Refer to MIPS code, they added an extra
bfd_is_abs_section check to avoid ABS got, so this seems the right and easier
way to go in the short-term.
bfd/
* elfnn-riscv.c (riscv_elf_finish_dynamic_sections): Set sh_entsize
and fill the got entries only when the got isn't an ABS section, and
the size of got is larger than zero. The similar goes for gotplt,
except we already reported error when the gotplt is an ABS.
ld -z separate-code let .text and .rodata in two different but read only
segment. If the symbol and pc in two segment, the offset from pc to
symbol need to consider segment alignment.
Add a function 'loongarch_two_sections_in_same_segment' to determine
whether two sections are in the same segment.
Now that the GDB 15 branch has been created,
this commit bumps the version number in gdb/version.in to
16.0.50.DATE-git
For the record, the GDB 15 branch was created
from commit 3a624d9f1c.
Also, as a result of the version bump, the following changes
have been made in gdb/testsuite:
* gdb.base/default.exp: Change $_gdb_major to 16.
PR gas/31752
These are effectively macro-like, without any separate macro definition.
They already support \@, so they would better also support \+. This
allows, where desired, to get away without maintaining an explicit count
variable in source code.
With this the recently introduced testcase doesn't need any xfails
anymore.
The present handling of inner double quotes can lead to very strange
diagnostics. Follow one of the two possible interpretations of the doc:
@dots{} referring to possibly multiple white space separated
@var{values}, each of which may be quoted. The original implementation,
prior to 465e561723 ("PR gas/3856"), hints at the other possible
interpretation: When quoted there's only a single @var{values}, with
inner quotes taken as ordinary characters. That, however, seems overall
less useful to me.
While touching the documentation, mirror the (inverse) spelling
correction (@section line inconsistent with actual description) to .irp
as well.
As already suggested during review, rather than having an extra
conditional in build_modrm_byte() (a code path used for quite a few
more insns, including even certain GPR ones), adjust the attribute in
the installed template to properly describe things with operands
swapped.
These run after template matching. Therefore operands are already known
to match the template in use. With the loop bodies skipping anything not
a GPR in the actual operands, there's therefore no need to check the
template's operand type for permitting Reg or Accum.
At the same time bring the three functions in sync for the "byte" part
of the logic, as far as checking the template for other sizes (qword
specifically) goes. Plus drop a stale comment from check_qword_reg(),
when all three are now behaving the same in this regard.
Properly reject inappropriate suffixes (No_lSuf / No_qSuf mistakenly
omitted by cf665fee1d ["x86: re-work AVX512 embedded rounding / SAE"]),
to avoid emitting bad or arbitrarily guessed instructions. Interestingly
check_{long,qword}_suffix() don't help here, which perhaps is another
indication that the way they work right now isn't quite appropriate.
Sadly correcting just the templates breaks operand ambiguity detection,
since so far that worked from a single template permitting more than one
suffix. Here we have ambiguity though which can now be noticed only when
taking all (matching) templates together. Therefore we need to determine
further matching templates (see code comments for constraints), to then
accumulate permitted suffixes across all of them.
When running test-case gdb.threads/attach-many-short-lived-threads.exp, I run
regularly into PR26286:
...
(gdb) continue^M
Continuing.^M
[LWP ... exited]^M
...
[LWP ... exited]^M
^M
Program terminated with signal SIGTRAP, Trace/breakpoint trap.^M
The program no longer exists.^M
(gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \
break at break_fn: 1
...
Add a kfail for this, such that we have:
...
(gdb) KFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \
break at break_fn: 1 (PRMS: threads/26286)
...
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Tested on x86_64-linux.
In a remote testing setup, I saw this error:
~~~
(gdb) FAIL: gdb.base/foll-fork.exp: check_fork_catchpoints: runto: run to main
ERROR: tcl error sourcing gdb/gdb/testsuite/gdb.base/foll-fork.exp.
ERROR: expected boolean value but got ""
while executing
"if { ![check_fork_catchpoints] } {
untested "follow-fork not supported"
return
}"
(file "gdb/gdb/testsuite/gdb.base/foll-fork.exp" line 434)
invoked from within
"source gdb/gdb/testsuite/gdb.base/foll-fork.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source gdb/gdb/testsuite/gdb.base/foll-fork.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Remote debugging from host 172.0.1.3, port 37766
Killing process(es): 1171
Quit
~~~
The actual reason for this were some connection problems. Though the
function check_fork_catchpoints shouldn't return an empty string, especially
as it promises to always return 0 or 1. Fix that.
Approved-By: Tom Tromey <tom@tromey.com>
The code that was factored out from gdb.base/relativedebug.exp assumed that
libc has debug info and only determined that it doesn't if it saw a specific
message from GDB to that effect. In the process of factoring it into a
require predicate, I made it stricter by trying to make a specific
determination of whether or not debug info is available.
Pedro noticed that "It'll disable the testcase on systems that link with
their libc statically (even if has debug info), or systems that name their
libc something else." Which is something I hadn't considered.
This patch returns libc_has_debug_info to the original behaviour.
Also, remove a verbose message that is redundant with the $message
variable.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31700
Approved-By: Tom Tromey <tom@tromey.com>
Unfortunately the background DWARF reading series introduced a number
of races, as repored by thread sanitizer. This patch changes gdb to
disable this feature for the time being -- in particular for the gdb
15 release.
I've filed a bug and linked all the known races to it. Once those are
fixed we can re-enable this feature by default.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31751
A build with --enable-maintainer-mode is currently failing with:
make[4]: *** No rule to make target '<SRC>/gas/config/te-ia64aix.h',
needed by '<SRC>/gas/po/gas.pot'. Stop.
make[4]: Leaving directory '<$OBJ>/gas/po'
make[3]: *** [Makefile:1695: all-recursive] Error 1
...
As config/te-ia64aix.h is now removed, remove the corresponding fragment
from the makefile.
gas/
* Makefile.am: Remove config/te-ia64aix.h.
* Makefile.in: Regenerate.
* po/POTFILES.in: Regenerate.
This patch is to enable ZU for IMUL (opcodes 0x69 and 0x6B) and SETcc.
Since the spec only recommends one form of setzu, I won't be adding
set<cc>reg32/reg64 support in this patch.
gas/ChangeLog:
* config/tc-i386.c (build_apx_evex_prefix): Handle ZU.
* testsuite/gas/i386/x86-64.exp: Added new tests for ZU.
* testsuite/gas/i386/x86-64.exp: Added new tests for ZU.
* testsuite/gas/i386/x86-64-apx-zu-intel.d: New test.
* testsuite/gas/i386/x86-64-apx-zu-inval.l: Ditto.
* testsuite/gas/i386/x86-64-apx-zu-inval.s: Ditto.
* testsuite/gas/i386/x86-64-apx-zu.d: Ditto.
* testsuite/gas/i386/x86-64-apx-zu.s: Ditto.
opcodes/ChangeLog:
* i386-dis-evex-prefix.h: Handle PREFIX_EVEX_MAP4_40 ~
PREFIX_EVEX_MAP4_4F.
* i386-dis-evex.h: Ditto.
* i386-dis.c (struct dis386): Add new micro 'ZU'.
(putop): Handle %ZU.
* i386-gen.c: Added ZU.
* i386-opc.h: Ditto.
* i386-opc.tbl: Added new templates to support ZU.
Resulting code will do better without the extra conditional branch.
Remove "i.rex" to eliminate extra conditional branch.
gas/ChangeLog:
* config/tc-i386.c (establish_rex): Remove i.rex.
Since APX supports EVEX from legacy instructions, we need to check
the 8-bit old registers in EVEX format. And add test cases for it.
gas/ChangeLog:
* config/tc-i386.c (md_assemble): Add invalid check for old byte
registers in EVEX format.
* testsuite/gas/i386/x86-64-apx-inval.l: Add new test.
* testsuite/gas/i386/x86-64-apx-inval.s: Ditto.
Split "REX/REX2 old register checking" and "add empty rex prefix"
into two separate branches.
gas/ChangeLog:
* config/tc-i386.c (establish_rex): Split the judgments.
A previous commit 80ec235 fixed the memory leaks, but brought to light
that the code should ideally make consistent use of snprintf and not
allocate/free more buffers than necessary.
gas/
* ginsn.c (ginsn_dst_print): Use snprintf consistently.
This patch fixes the following comment.
- /* The hyphenated form is preferred for disassembly if there are
- more than two registers in the list, and the register numbers
are monotonically increasing in increments of one. */
+ /* The hyphenated form is preferred for disassembly if there is
+ more than one register in the list, and the register numbers
are monotonically increasing in increments of one. */
An Ada pretty-printer had a bug where its 'child' method returned a
gdb.Value rather than a tuple. Kévin suggested that the documentation
for this method could be improved to clarify this.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
Approved-By: Eli Zaretskii <eliz@gnu.org>
