Szabolcs Nagy [Wed, 27 Mar 2024 15:38:06 +0000 (15:38 +0000)]
aarch64: Add DT_RELR support
The logic to decide if an input relocation for a symbol becomes a
particular kind of output relocation is one of the hard to maintain
parts of the bfd ld backend, since it is partially repeated across
elfNN_aarch64_check_relocs (where dynamic relocations are counted per
symbol and input section),
elfNN_aarch64_late_size_sections (where relocation sections are sized
and GOT offsets assigned),
elfNN_aarch64_relocate_section (where most relocations are applied and
output to a relocation section),
elfNN_aarch64_finish_dynamic_symbol (where some of the GOT
relocations are applied and output).
The DT_RELR support adds another layer to this complexity: after the
output relocation sections are sized, so all dynamic relocations are
accounted (in elfNN_aarch64_late_size_sections), we scan the symbols
and input relocations again to decide which ones become relative
relocations that can be packed. The sizes of the relocation sections
are updated accordingly. This logic must be consistent with the code
that applies the relocs later so each relative relocation is emitted
exactly once: either in .rela.* or packed in .relr.dyn.
Sizing of .relr.dyn is done via elfNN_aarch64_size_relative_relocs that
may be called repeatedly whenever the layout changes since an address
change can affect the size of the packed format. Then the final content
is emitted in elfNN_aarch64_finish_relative_relocs, that is called
after the layout is final and before relocations are applied and
emitted. These hooks are only called if DT_RELR is enabled.
We only pack relative relocs that are known to be aligned in the output
during .relr.dyn sizing, the potentially unaligned relative relocs are
emitted normally (in .rela.*, not packed), because the format requires
aligned addresses.
These run after template matching. Therefore it is quite pointless for
them to check all operands, when operand sizes matching across operands
is already known. Exit the loops early in such cases.
In check_byte_reg() also drop a long-stale part of a comment.
Felix Willgerodt [Tue, 21 May 2024 12:54:05 +0000 (14:54 +0200)]
gdb, doc: Fix AVX-512 documentation.
org.gnu.gdb.i386.avx512 adds k registers, but these aren't mentioned in the
docs yet. Fix that.
In addition the documentation describes xmm registers with an `h`
(e.g. xmm16h). I am assuming that we follow the register xml files here,
which don't have the h suffix. So this removes that as well.
was causing problems. Given a release tar file, an attempt to build
and install GDB would give an error like this:
[...]
TEXI2POD gdb.pod
cannot find GDBvn.texi at ../../../gdb-15.0.50.20240508/gdb/doc/../../etc/texi2pod.pl line 251, <GEN0> line 16.
make[5]: *** [Makefile:663: gdb.pod] Error 2
The problem here is how the man pages are built, and how they are
distributed within a release.
Within the development (git) tree, the man page files are not part of
the source tree, these files are built as needed. Within a release
tar file though, the man pages are included. The idea being that a
user can build and install GDB, including getting the man pages,
without having to install the tools needed to generate the man pages.
The man pages are generated in a two step process. First the .texi
file is processed with texi2pod to create a .pod file, then this .pod
file is processed to create the .1 or .5 man file.
Prior to the above commit these two steps were combined into a single
recipe, this meant that when a user performed a build/install from a
release tree all of the dependencies, as well as the final result,
were all present in the source tree, and so nothing needed to be
rebuilt.
However, the above commit split the two steps apart. Now we had a
separate rule for building the .pod files, and the .1/.5 man page
files depended on the relevant .pod file.
As the .pod files are not shipped in a GDB release, this meant that
one of the dependencies of the man page files was now missing. As a
result if a user tried to install from a release tree a rebuild of the
.pod files would be attempted, and if that succeeded then building the
man pages would follow that.
Unfortunately, building the .pod files would fail as the GDBvn.texi
file, though present in the source tree, was not present in the build
tree, which is where it is needed for the .pod file generation to
work.
To fix this, I propose merging the .pod creation and the .1/.5 man
page creation back into a single recipe. Having these two steps split
is probably the "cleaner" solution, but makes it harder for us to
achieve our goal of shipping the prebuilt man page files. I've added
a comment explaining what's going on (such a comment would have
prevented this mistake having been made in the first place).
One possibly weird thing here is that I have left both an
ECHO_TEXI2POD and a ECHO_TEXI2MAN in the rule $(MAN1S) and $(MAN5S)
recipes. This is 100% not going to break anything, these just print
two different progress messages while executing the recipes, but I'm
not sure if this is considered poor style or not. Maybe we're only
supposed to have a single ECHO_* per recipe?
Anyway, even if this is poor style, I figure it really is just a style
thing. We can tweak this later as needed. Otherwise, this commit
should fix the current issue blocking the next GDB release.
Szabolcs Nagy [Thu, 23 May 2024 17:16:57 +0000 (18:16 +0100)]
readelf: Fix symbol display for RELR relocs
Filter symbols before binary searching for the right symbol to display
for a given address, such that only displayable symbols are present and
at most one per address.
The current logic does not handle multiple symbols for the same address
well if some of them are empty, the selected symbol is not stable with
respect to an unrelated symbol table change and on aarch64 often mapping
symbols are displayed which is not useful.
Filtering solves these problems at the cost of a linear scan of the
sorted symbol table.
The heuristic to select the best symbol likely could be improved, this
patch aims to improve symbol display for RELR without complex logic
such that the output is useful and stable for ld tests.
Jan Beulich [Wed, 29 May 2024 08:03:00 +0000 (10:03 +0200)]
x86/Intel: warn about undue mnemonic suffixes
Except for very few insns mnemonic suffixes aren't permitted in Intel
syntax. Warn about such for now, indicating that they will be outright
refused down the road.
While fiddling with testcases to address fallout, drop a few things
which should never have been tested as valid Intel syntax.
Also add a previously missing line to simd-suffix.d.
Alan Modra [Tue, 28 May 2024 04:10:50 +0000 (13:40 +0930)]
PR31796, Internal error in write_function_pdata at obj-coff-seh
PR31796 is the result of lack of aarch64 support in obj-coff-seh.c.
Nick fixed this with commit 73c8603c3f. Make the seh support
consistently warn in future if some archictecture is missing, rather
than giving internal errors.
PR 31796
* config/obj-coff-seh.c (verify_target): New function.
(obj_coff_seh_handler, obj_coff_seh_endproc, obj_coff_seh_proc),
(obj_coff_seh_endprologue): Use it.
Dimitar Dimitrov [Tue, 21 May 2024 15:05:54 +0000 (18:05 +0300)]
ld: pru: Increase the default memory region sizes
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.
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.
Richard Earnshaw [Thu, 23 May 2024 15:25:51 +0000 (16:25 +0100)]
opcodes: add a .gitattributes file for aarch64 autogenerated file exceptions
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.
Javier Mora [Fri, 24 May 2024 18:10:05 +0000 (20:10 +0200)]
RISC-V: Fix U insn; replace opcode6 with opcode7 in gas/doc/c-riscv.texi
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.
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.
Nelson Chu [Mon, 29 Apr 2024 09:44:51 +0000 (17:44 +0800)]
RISC-V: Segment fault for kernel purgatory when linking.
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.
mengqinggang [Wed, 22 May 2024 06:27:08 +0000 (14:27 +0800)]
LoongArch: Fix relaxation overflow caused by ld -z separate-code
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.
Jan Beulich [Fri, 24 May 2024 10:23:22 +0000 (12:23 +0200)]
gas: extend \+ support to .irp / .irpc
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.
Jan Beulich [Fri, 24 May 2024 10:22:54 +0000 (12:22 +0200)]
gas: adjust handling of quotes for .irpc
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 465e5617233f ("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.
Jan Beulich [Fri, 24 May 2024 10:21:57 +0000 (12:21 +0200)]
x86: simplify VexVVVV_SRC2 handling for the XOP case
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.
Jan Beulich [Fri, 24 May 2024 09:50:38 +0000 (11:50 +0200)]
x86: correct VCVT{,U}SI2SD
Properly reject inappropriate suffixes (No_lSuf / No_qSuf mistakenly
omitted by cf665fee1d6c ["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.
Tom de Vries [Fri, 24 May 2024 07:36:52 +0000 (09:36 +0200)]
[gdb/testsuite] Add PR26286 kfail in gdb.threads/attach-many-short-lived-threads.exp
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.
Felix Willgerodt [Tue, 21 May 2024 07:20:39 +0000 (09:20 +0200)]
gdb, testsuite: Fix return value in gdb.base/foll-fork.exp
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.
gdb/testsuite: Restore libc_has_debug_info's less strict behaviour
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>
Tom Tromey [Fri, 17 May 2024 14:55:46 +0000 (08:55 -0600)]
Default dwarf_synchronous to true
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.
Cui, Lili [Wed, 22 May 2024 08:15:47 +0000 (16:15 +0800)]
Support APX zero-upper
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.
Indu Bhagat [Tue, 21 May 2024 19:59:55 +0000 (12:59 -0700)]
gas: ginsn: remove unnecessary buffer allocation and free
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.
- /* 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. */
Tom Tromey [Tue, 21 May 2024 11:13:18 +0000 (05:13 -0600)]
Clarify documentation for pretty_printer.child
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>
Nick Alcock [Mon, 20 May 2024 13:31:03 +0000 (14:31 +0100)]
include, libctf: improve documentation
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.
Kévin Le Gouguec [Mon, 20 May 2024 15:22:50 +0000 (17:22 +0200)]
gdb: Fix Windows build after #include shuffle
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}" (f617661c110).
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>
Sung-hun Kim [Mon, 13 May 2024 08:11:49 +0000 (17:11 +0900)]
RISC-V: PR31733, Change initial CFI operation from DW_CFA_def_cfa_register to DW_CFA_def_cfa
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.
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.
Historically, we have used several APIs (perfctr, libcpc, perf_event_open) for profiling.
For each hardware we have several tables of hardware counters.
Some information is duplicated in these tables.
Some of the information is no longer used.
I did not touch the existing hwc tables.
I added a new hwc table for an AMD Zen3 machine.
ChangeLog
2024-05-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/31123
* common/core_pcbe.c (core_pcbe_get_events): Add new argument.
* common/hwc_cpus.h: New constants for AMD hardware.
* common/hwcdrv.c: Add new argument to hwcdrv_get_descriptions.
Clean up the code.
* common/hwcdrv.h: Likewise.
* common/hwcfuncs.c (hwcdrv_get_descriptions): Add new argument.
* common/hwctable.c: Add the hwc table for AMD Zen3.
* src/hwc_amd_zen3.h: New file.
* common/opteron_pcbe.c: Add new argument to opt_pcbe_get_events.
* src/collctrl.cc: Remove unused variable.
* src/collctrl.h: Likewise.
interface with libcpc was used on Solaris.
gprofng doesn't support profiling on Solaris.
I removed this old code and other unused macros and variables.
gprofng/ChangeLog
2024-04-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
Tom Tromey [Tue, 16 Aug 2022 17:40:15 +0000 (11:40 -0600)]
Remove gdb_stdtargerr
This patch removes gdb_stdtargerr. There doesn't seem to be a need
for this -- it is always the same as stdtarg, and (I believe) has been
for many years.
Tom Tromey [Tue, 16 Aug 2022 15:31:33 +0000 (09:31 -0600)]
Don't allow new-ui to start the TUI
The TUI can't really work properly with new-ui, at least not as
currently written. This patch changes new-ui to reject an attempt.
Attempting to make a DAP ui this way is also now rejected.
Regression tested on x86-64 Fedora 38.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29273 Approved-By: Andrew Burgess <aburgess@redhat.com>
Dmitry.Neverov [Mon, 6 May 2024 15:09:17 +0000 (17:09 +0200)]
gdb/symtab: check name matches before expanding a CU
The added check fixes the case when an unqualified lookup
name without template arguments causes expansion of many CUs
which contain the name with template arguments.
This is similar to what dw2_expand_symtabs_matching_symbol does
before expanding the CU.
In the referenced issue the lookup name was wxObjectDataPtr and many
CUs had names like wxObjectDataPtr<wxBitmapBundleImpl>. This caused
their expansion and the lookup took around a minute. The added check
helps to avoid the expansion and makes the symbol lookup to return in
a second or so.
Nick Alcock [Fri, 26 Apr 2024 17:19:15 +0000 (18:19 +0100)]
libctf: fix leak of entire dict when dict opening fails
Ever since commit 1fa7a0c24e78e7f ("libctf: sort out potential refcount
loops") ctf_dict_close has only freed anything if the refcount on entry
to the function is precisely 1. >1 obviously just decrements the
refcount, but the linker machinery can sometimes cause freeing to recurse
from a dict to another dict and then back to the first dict again, so
we interpret a refcount of 0 as an indication that this is a recursive call
and we should just return, because a caller is already freeing this dict.
Unfortunately there is one situation in which this is not true: the bad:
codepath in ctf_bufopen entered when opening fails. Because the refcount is
bumped only at the very end of ctf_bufopen, any failure causes
ctf_dict_close to be entered with a refcount of zero, and it frees nothing
and we leak the entire dict.
The solution is to bump the refcount to 1 right before freeing... but this
codepath is clearly delicate enough that we need to properly validate it,
so we add a test that uses malloc interposition to count allocations and
frees, creates a dict, writes it out, intentionally corrupts it (by setting
a bunch of bytes after the header to a value high enough that it is
definitely not a valid CTF type kind), then tries to open it again and
counts the malloc/free pairs to make sure they're matched. (Test run only
on *-linux-gnu, because malloc interposition is not a thing you can rely
upon working everywhere, and this test is not arch-dependent so if it
passes on one arch it can be assumed to pass on all of them.)
libctf/
* ctf-open.c (ctf_bufopen): Bump the refcount on failure.
* testsuite/libctf-regression/open-error-free.*: New test.
Nick Alcock [Fri, 26 Apr 2024 17:16:49 +0000 (18:16 +0100)]
libctf: test: add wrapper
This .lk option lets you run the lookup program via a wrapper executable.
For example, to run under valgrind and check for leaks (albeit noisily
because of the libtool shell script wrapper):
Nick Alcock [Fri, 26 Apr 2024 17:10:00 +0000 (18:10 +0100)]
libctf: ctf_archive_iter: fix tiny leak
If iteration fails because opening a dict has failed, ctf_archive_next does
not destroy the iterator, so the caller can keep going and try to open other
dicts further into the archive. ctf_archive_iter just returns, though, so
it should free the iterator rather than leaking it.
libctf/
* ctf-archive.c (ctf_archive_iter): Don't leak the iterator on
failure.
Nick Alcock [Fri, 26 Apr 2024 17:09:38 +0000 (18:09 +0100)]
libctf: failure to open parent dicts that exist should be an error
CTF archive member opening (via ctf_arc_open_by_name, ctf_archive_iter, et
al) attempts to be helpful and auto-open and import any needed parent dict
in the same archive. But if this fails, the error is not reported but
simply discarded, and you silently get back a dict with no parent, that
*you* suddenly have to remember to import.
This is not helpful behaviour: if the parent is corrupted or we run out of
memory or something, the caller is going to want to know! Split it in two:
if the dict cites a parent that doesn't exist at all (a lot of historic
dicts name "PARENT" as their parent, even when they're not even children, or
perhaps the parent dict is stored separately and you plan to manually
associate it), we skip it as now, but if the import fails with an actual
error other than ECTF_ARNNAME, return the error and fail the open.
libctf/
* ctf-archive.c (ctf_arc_import_parent): Return failure if
parent opening fails for reasons other thnn nonexistence.
(ctf_dict_open_sections): Adjust.
projects / thirdparty / binutils-gdb.git / log
