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>
Some review comments came in after I pushed the last lot of ctf-api.h
comment improvements. They were good, so I've incorporated them.
Mostly: better _next iterator usage info, better info on ctf_*open
functions, and better info on ctf_type_aname and ctf_type_name_raw.
include/
* ctf-api.h: improve documentation.
Without this patch, the build chokes on:
../../src/gdb/windows-nat.c:384:21: error: field 'm_debug_event_pending' has incomplete type 'std::atomic<bool>'
384 | std::atomic<bool> m_debug_event_pending { false };
| ^~~~~~~~~~~~~~~~~~~~~
In file included from […gcc tree…]/include/c++/13.2.1/bits/shared_ptr_atomic.h:33,
from […gcc tree…]/include/c++/13.2.1/memory:81,
from ../../src/gdb/../gdbsupport/gdb_unique_ptr.h:23,
from ../../src/gdb/../gdbsupport/common-utils.h:26,
from ../../src/gdb/../gdbsupport/common-defs.h:199,
from ./../../src/gdb/defs.h:26,
from <command-line>:
[…gcc tree…]/include/c++/13.2.1/bits/atomic_base.h:174:12: note: declaration of 'struct std::atomic<bool>'
174 | struct atomic;
| ^~~~~~
make.exe[2]: *** [Makefile:1947: windows-nat.o] Error 1
Presumably windows-nat.c relied on objfiles.h including <atomic>,
which was undone in 2024-05-16 "gdb: remove unused includes in
objfiles.{c,h}" (f617661c11).
When running test-case gdb.testsuite/gdb-caching-proc-consistency.exp with
target board native-gdbserver, we run into:
...
(gdb) ERROR: tcl error sourcing gdb.testsuite/gdb-caching-proc-consistency.exp.
ERROR: gdbserver does not support attach 4827 without extended-remote
while executing
"error "gdbserver does not support $command without extended-remote""
(procedure "gdb_test_multiple" line 51)
invoked from within
"gdb_test_multiple "attach $test_pid" "can spawn for attach" {
-re -wrap "$attaching_re\r\n.*ptrace: Operation not permitted\\." {
# Not permitte..."
(procedure "gdb_real__can_spawn_for_attach_1" line 27)
invoked from within
"gdb_real__can_spawn_for_attach_1"
...
The problem is that:
- can_spawn_for_attach_1 is a helper function for can_spawn_for_attach,
designed to be called only from that function, and
- can_spawn_for_attach_1 is a gdb_caching_proc, and consequently
test-case gdb.testsuite/gdb-caching-proc-consistency.exp calls
can_spawn_for_attach_1 directly.
Fix this by copying the early-outs from can_spawn_for_attach to
can_spawn_for_attach_1.
Tested on x86_64-linux.
Reported-By: Simon Marchi <simark@simark.ca>
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
The DWARF specification (especially, DWARF4 and 5 [1,2]) states that
DW_CFA_def_cfa_register cannot be used as the first CFI operation.
It said DW_CFA_def_cfa_register as follows:
... This operation is valid only if the current CFA rule is defined
to use a register and offset.
So, DW_CFA_def_cfa_register can be used after that other definition
operation such as DW_CFA_def_cfa is called. However, the current gas
code emits DW_CFA_def_cfa_register as an initial CFI operation for RISCV.
In the libgcc, the unwinding function does not care about it, so it can
unwind the call stack. However, on the third party library such as
libunwindstack in Android, it causes a fatal error.
This patch changes the initial CFI operation to DW_CFA_def_cfa with
offset 0. It works as same as the previous one, but it does not have
any limitation so it satisfies the DWARF spec. This change resolves
the compatibility issue while preserving the original behaviour.
[1] DWARF4 specification, https://dwarfstd.org/doc/DWARF4.pdf
[2] DWARF5 specification, https://dwarfstd.org/doc/DWARF5.pdf
Signed-off-by: Sung-hun Kim <sfoon.kim@samsung.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Nelson Chu <nelson@rivosinc.com>
gas/
PR 31733
config/tc-riscv.c (riscv_cfi_frame_initial_instructions): Use
DW_CFA_def_cfa rather than DW_CFA_def_cfa_register.
