Alan Modra [Mon, 19 May 2025 06:37:20 +0000 (16:07 +0930)]
rs_fill_nop and md_generate_nops
Make rs_fill_nop behave like rs_fill in using a repeat count
(fr_offset) to emit fr_var length repeated nop patterns. Besides
being more elegant, this reduces memory required for large .nops
directives.
* as.h (rs_fill_nop): Update comment.
* config/tc-i386.c (i386_generate_nops): Handle rs_fill_nop as
for rs_align_code.
* config/tc-i386.h (MAX_MEM_FOR_RS_SPACE_NOP): Define.
* listing.c (calc_hex): Handle rs_fill_nop as for rs_fill.
* read.c (MAX_MEM_FOR_RS_SPACE_NOP): Define.
(s_nops): Use MAX_MEM_FOR_RS_SPACE_NOP setting up frag.
* write.c (write_contents): Call md_generate_nops for rs_fill_nop
before the fr_fix part is written, so that rs_fill_nop can be
handled as for rs_fill.
Alan Modra [Sat, 17 May 2025 05:41:14 +0000 (15:11 +0930)]
tidy target HANDLE_ALIGN
avr, kvx, metag, mn10300, nds32, v850, visium, and wasm32 targets
defined HANDLE_ALIGN without defining MAX_MEM_FOR_RS_ALIGN_CODE. This
can result in a rather large chunk of memory being allocated. Fix
that by a combination of changing the default allocation to one byte
and/or defining a target MAX_MEM_FOR_RS_ALIGN_CODE.
arm wanted to write out the entire set of nops, and limited allowed
code alignment to 64 bytes to prevent large memory allocations.
Fix that by making use of the fact that rs_align_code frags repeat
fr_var bytes at fr_literal + fr_fix to fill out the required area.
Fix metag, nds32 and kvx too, which it seems copied either arm or x86
in similarly not making use of repeating patterns.
It's worth mentioning that my tidy to kvx changed the order of nop
bundles, placing a short bundle first rather than last.
epiphany was totally broken in that uninitialised data was written out
for any alignment requiring more than three bytes of fill.
ppc created a new frag to handle a branch over a large number of nops.
This saves 4 bytes per rs_align_code frag, and most times the branch
isn't used so it is generally a win for memory usage, but I figured
the extra code complexity wasn't worth it. So that code of mine goes.
visium copied the same scheme, so that goes too.
This leaves x86 as the only target making large allocations for
alignment frags.
* frags.c (MAX_MEM_FOR_RS_ALIGN_CODE): Default to 1.
* config/tc-aarch64.c (aarch64_handle_align): Remove always true
condition.
* config/tc-aarch64.h (MAX_MEM_FOR_RS_ALIGN_CODE): Move to be
adjacent to HANDLE_ALIGN define.
* config/tc-arm.c (arm_handle_align): Allow alignment of more
than MAX_MEM_FOR_RS_ALIGN_CODE bytes. Just write one repeat
of nop pattern to frag.
(arm_frag_align_code): Delete function.
* config/tc-arm.h (MAX_MEM_ALIGNMENT_BYTES): Don't define.
(MAX_MEM_FOR_RS_ALIGN_CODE): Set to 7.
(md_do_align): Don't define.
(arm_frag_align_code): Don't declare.
* config/tc-epiphany.c (epiphany_handle_align): Correct frag
so that nop_pattern repeats rather than random data.
* config/tc-epiphany.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define.
* config/tc-kvx.c (kvx_make_nops): Merge into..
(kvx_handle_align): ..here. Put short nop bundle first,
followed by repeated full nop bundle.
* config/tc-kvx.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define.
* config/tc-m32c.h (HANDLE_ALIGN, MAX_MEM_FOR_RS_ALIGN_CODE):
Don't define.
* config/tc-metag.c (metag_handle_align): Just write one
repeat of nop pattern to frag.
* config/tc-metag.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define.
* config/tc-nds32.c (nds32_handle_align): Just write one
repeat of nop pattern to frag.
* config/tc-nds32.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define.
* config/tc-ppc.c (ppc_handle_align): Don't make a new frag
for branch.
* config/tc-ppc.h (MAX_MEM_FOR_RS_ALIGN_CODE): Increase to 8.
* config/tc-visium.c (visium_handle_align): Don't make a new
frag for branch.
* config/tc-visium.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define.
* config/tc-wasm32.h (HANDLE_ALIGN): Don't define.
* testsuite/gas/epiphany/nop.d,
* testsuite/gas/epiphany/nop.s: New test.
* testsuite/gas/epiphany/allinsn.exp: Run it.
* testsuite/gas/kvx/nop-align.d: Adjust.
Andrew Burgess [Wed, 21 May 2025 09:16:08 +0000 (10:16 +0100)]
gdb: reorder checks in validate_exec_file
While reviewing another patch I was briefly confused by a call to
target_pid_to_exec_file coming from validate_exec_file while attaching
to a process when I had not previously set an executable.
The current order of actions in validate_exec_file is:
1. Get name of current executable.
2. Get name of executable from the current inferior.
3. If either of (1) or (2) return NULL, then there's nothing to
check, early return.
I think it would be cleaner if we instead did this:
1. Get name of current executable.
3. If (1) returned NULL then there's nothing to check, early return.
3. Get name of executable from the current inferior.
4. If (3) returned NULL then there's nothing to check, early return.
This does mean there's an extra step, but I don't think the code is
any more complex really, and we now avoid trying to extract the name
of the executable from the current inferior unless we really need it.
This avoids the target_pid_to_exec_file call that I was seeing, which
for remote targets does avoid a packet round trip (not that I'm
selling this as an "optimisation", just noting the change).
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Thu, 22 May 2025 16:46:50 +0000 (10:46 -0600)]
Ensure cooked_index_entry self-tests are run
While looking at code coverage for gdb, I noticed that the
cooked_index_entry self-tests were not run. I tracked this down to a
formatting error in cooked-index-entry.c.
I suspect it might be better to use a macro to define these
initialization functions. That would probably remove the possibility
for this kind of error.
gprofng: fix 32892 source line level information not available with "-g -O2"
gprofng did not read the .debug_rnglists section for dwarf-5.
Another problem was that gprofng ignored DW_AT_abstract_origin
As a result, gprofng skiped Dwarf for all functions declared as:
<1><e18b>: Abbrev Number: 43 (DW_TAG_subprogram)
<e18c> DW_AT_abstract_origin: <0xe168>
<e190> DW_AT_linkage_name: _ZN10Bool_ArrayD2Ev
gprofng/ChangeLog
2025-05-19 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR 32892
* src/Dwarf.cc: Read the .debug_rnglists section.
Support DW_AT_abstract_origin.
* src/Dwarf.h: Likewise.
* src/DwarfLib.cc: Likewise.
* src/DwarfLib.h: Likewise.
* src/LoadObject.cc (dump_functions): Print mangled names for aliases.
* src/Stabs.cc (fixSymtabAlias): Set 'alias' correctly.
* src/Symbol.cc (find_symbols): Add argument where to collect symbols.
* src/Symbol.h: Likewise.
* NEWS: Mention new extensions.
* config/tc-riscv.c (enum riscv_csr_class): New CSR class.
(riscv_csr_address): Add support for Ssccfg.
* testsuite/gas/riscv/csr-version-1p10.d: New test for Ssccfg CSR.
* testsuite/gas/riscv/csr-version-1p10.l: New warning for Ssccfg CSR.
* testsuite/gas/riscv/csr-version-1p11.d: New test for Ssccfg CSR.
* testsuite/gas/riscv/csr-version-1p11.l: New warning for Ssccfg CSR.
* testsuite/gas/riscv/csr-version-1p12.d: New test for Ssccfg CSR.
* testsuite/gas/riscv/csr-version-1p12.l: New warning for Ssccfg CSR.
* testsuite/gas/riscv/csr-version-1p13.d: New test for Ssccfg CSR.
* testsuite/gas/riscv/csr-version-1p13.l: New warning for Ssccfg CSR.
* testsuite/gas/riscv/csr.s: New Ssccfg CSR.
* testsuite/gas/riscv/imply.d: New imply check.
* testsuite/gas/riscv/imply.s: New implies.
* testsuite/gas/riscv/march-help.l: New helping info.
include/ChangeLog:
* opcode/riscv-opc.h (CSR_SCOUNTINHIBIT): New CSR address.
(DECLARE_CSR): Add Ssccfg CSR.
Alan Modra [Wed, 21 May 2025 08:27:04 +0000 (17:57 +0930)]
ubsan: integer overflow in tc-i386.c:offset_in_range
or $9223372036854775808,%eax
runtime error: negation of -9223372036854775808 cannot be represented
in type 'offsetT' (aka 'long'); cast to an unsigned type to negate
this value to itself
* config/tc-i386.c (offset_in_range): Avoid signed overflow.
Tom Tromey [Thu, 10 Apr 2025 15:01:06 +0000 (09:01 -0600)]
Minor spelling fixes in gdb directory
I ran codespell on the gdb directory and fixed a number of minor
problems. In a couple cases I replaced a "gdb spelling" (e.g.,
"readin") with an English one ("reading") where it seemed harmless.
Tom de Vries [Tue, 20 May 2025 09:10:29 +0000 (11:10 +0200)]
[gdb/testsuite] Fix gdb.dwarf2/dw-form-strx-out-of-bounds.exp with make-check-all.sh
I forgot to run test-case gdb.dwarf2/dw-form-strx-out-of-bounds.exp with
make-check-all.sh, and consequently failed to notice that it fails with for
instance target board fission-dwp.
The test-case does:
...
source $srcdir/$subdir/dw-form-strx.exp.tcl
...
and in that tcl file, prepare_for_testing fails, so a -1 is returned, but
that is ignored by the source command.
Fix this by using require, but rather that testing the result of the source
command, communicate success by setting a global variable
prepare_for_testing_done.
Likewise in gdb.dwarf2/dw-form-strx.exp.
Also, the test-case gdb.dwarf2/dw-form-strx-out-of-bounds.exp fails for target
board readnow, because the DWARF error occurs during a different command than
expected.
Fix this by just skipping the test-case in that case.
Tested on x86_64-linux.
Reported-by: Simon Marchi <simark@simark.ca> Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Tue, 20 May 2025 09:05:54 +0000 (11:05 +0200)]
[gdb/testsuite] Fix gdbsever typo
I noticed a typo in the testsuite, twice: gdbsever. Fix these.
Codespell doesn't detect it, so add a new file
gdb/contrib/codespell-dictionary.txt that contains a gdbsever->gdbserver
entry, and update gdb/contrib/setup.cfg to use it.
Andreas Schwab [Wed, 14 May 2025 10:44:08 +0000 (12:44 +0200)]
libiberty: sync with gcc
Import the following commits from GCC as of r16-614-g9d039eff453f77: 31dd621796f libiberty: add ldirname function f3d07779fdb libiberty: Append <libgen.h> to AC_CHECK_DECLS [PR119218]. 90183362524 libiberty, gcc: Add memrchr to libiberty and use it [PR119283]. 43717ee9064 libiberty: Fix off-by-one when collecting range expression
Alan Modra [Tue, 20 May 2025 05:52:13 +0000 (15:22 +0930)]
ubsan: undefined shift in loongarch_elf_add_sub_reloc_uleb128
An oss-fuzz testcase found:
runtime error: shift exponent 140 is too large for 32-bit type 'int'
OK, that's just a completely silly uleb, but we ought to be able to
handle 64 bits here.
* elfxx-loongarch.c (loongarch_elf_add_sub_reloc_uleb128): Formatting.
Don't left shift int. Avoid shifts larger than bits in a bfd_vma.
Simulator testsuite build started failing with host GCC-15:
bits-tst.c:323:1: error: function declaration isn’t a prototype [-Werror=strict-prototypes]
bits-tst.c: In function ‘main’:
bits-tst.c:323:1: error: old-style function definition [-Werror=old-style-definition]
Fix by including string.h to get the required prototypes, and changing
main's declaration to modern C.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu> Approved-By: Tom Tromey <tom@tromey.com>
Alan Modra [Sun, 18 May 2025 10:10:34 +0000 (19:40 +0930)]
ubsan: integer overflow in s_fill
Silence ubsan warning. We don't worry about wrap-around in most
places that adjust abs_section_offset, so don't fuss over an overflow
in the multiplication here.
* read.c (s_fill): Replace "long" vars with offsetT and valueT.
Avoid signed overflow calculating abs_section_offset.
> If vector AMO instructions are supported, then the scalar Zaamo
> instructions (atomic operations from the standard A extension)
> must be present.
Note that using the words like "imply" or "depend" for extensions
weren't a common practice to represent dependencies between extensions
at the time the documentation was created.
The "Zaamo" was not ratified as an extension at the time but this is a
subset of the "A" extension and defines scalar AMO operations (while
"Zvamo" -- NOT in the ratified specification -- defines vector AMO ops).
The important part is that the T-Head/XuanTie's documentation just
states that the "Zvamo" (draft) extension is renamed to "XTheadZvamo".
It means, this implication should have been preserved in some way.
Tsukasa OI [Sun, 18 May 2025 04:35:16 +0000 (04:35 +0000)]
RISC-V: Add implicit dependency to the XTheadVector extension
While this dependency is not directly stated in the documentation,
the XTheadVector extension cannot work without the Zicsr extension
(the documentation does not specify CSR access instruction subset
either as in the Zkr extension or the seed CSR section in the manual).
Also, making an implication to the Zicsr extension is in parity with
the ratified vector extensions (in GNU Binutils, the Zve32x extension --
a dependency of V -- depends on the Zvl32b and Zicsr extensions).
Tsukasa OI [Sun, 18 May 2025 04:35:16 +0000 (04:35 +0000)]
RISC-V: Wider conflicts with the XTheadVector extension
T-Head/XuanTie's "XTheadVector" is based on a draft version of the now
standard vector extensions and it conflicts with not just the "V"
extension but all of its subsets.
This commit makes "XTheadVector" conflict with the "Zve32x" extension,
which is the smallest subset of the standard vector extensions. Still,
a reference to "V" is preserved in the error message
as the documentation suggests:
> Therefore, the XTheadVector extension and the V extension are
> in conflict.
Note that, instructions in the "XTHeadZvamo" extension currently has
no conflicts with other extensions, even after addition of the "Zabha"
extension.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_parse_check_conflicts):
Make "XTheadVector" conflict with not just "V" but its subsets.
gas/ChangeLog:
* testsuite/gas/riscv/x-thead-vector-fail.d: Test a vector
subset "Zve32x" to test failures.
* testsuite/gas/riscv/x-thead-vector-fail.l: Reflect change
in the error message.
Jens Remus [Mon, 19 May 2025 08:38:01 +0000 (10:38 +0200)]
s390: Prevent GOT access rewrite for misaligned symbols
Dereferences of GOT slots with lgrl or lg for global symbols are
rewritten to larl to get get rid of the extra memory access. However
this is invalid for:
- symbols marked for absolute addressing
- symbols at odd addresses (larl can handle only even addresses)
Commit e6213e09ed0e ("S/390: Prevent GOT access rewrite for certain
symbols") added checks for the above. But instead of checking the
address of a symbol for being halfword aligned, it tries to deduce
this from whether the symbol value and section the symbol is defined
in are halfword aligned. The way it is done has two issues:
1. The use of bfd_section_from_elf_index to obtain the section the
symbol is defined in may not return the one that remains in the
output. For instance for COMDAT sections getting deduplicated
the section retrieved using bfd_section_from_elf_index may not be
the same as h->root.u.def.section. If COMDAT sections of same
group signature have different alignment properties the wrong
one may be checked. This may then lead to an erroneous rewrite
of lgrl %rX, sym@GOTENT to larl %rX, sym, although the symbol in
the remaining section is not properly aligned, triggering an
"relocation for misaligned symbol" error at link-time.
This may for instance occur when mixing C++ modules compiled with
GCC and Clang, as GCC emits a 2-byte alignment and Clang a 1-byte
alignment for COMDAT sections containing type information:
Produces (reformatted and reduced):
File Name Off Size ES Flg Lk Inf Al
sample_gcc.o .rodata._ZTS1A 000080 000004 00 AG 0 0 2
sample_clang.o .rodata._ZTS1A 000058 000003 00 AG 0 0 1
2. The symbol may end up at an even address, if both the symbol value
and the section defining the symbol are 1-byte aligned. While this
does not trigger an error, it fails an opportunity to rewrite a GOT
access.
In a Linux Kernel build this causes ~15k GOT accesses using lgrl to
be skipped to be rewritten to larl.
Resolve both issues by simply checking whether the symbol address is
halfword aligned. Do not check the symbol value nor section defining
the symbol for halfword alignment.
bfd/
PR ld/32969
* elf64-s390.c (elf_s390_relocate_section): Only rewrite
lgrl/lg from GOT to larl if symbol address is halfword aligned.
ld/testsuite/
PR ld/32969
* ld-s390/s390.exp (pr32969_64-1, pr32969_64-2): Add tests for
rewrite of GOT access when COMDAT section deduplication is
involved.
* ld-s390/pr32969_64-1.dd: New test for rewrite of GOT access
when COMDAT section deduplication is involved.
* ld-s390/pr32969_64-2.dd: Likewise.
* ld-s390/pr32969a.s: Likewise.
* ld-s390/pr32969b.s: Likewise.
* ld-s390/pr32969c.s: Likewise.
Bug: https://sourceware.org/PR32969 Fixes: e6213e09ed0e ("S/390: Prevent GOT access rewrite for certain symbols") Reported-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jens Remus [Mon, 19 May 2025 08:38:01 +0000 (10:38 +0200)]
s390: Improve diagnostic for reloc against misaligned sym
Report the BFD in which a misaligned symbol is defined in the error
message. This complements commit 906f69cf65da ("IBM zSystems: Issue
error for *DBL relocs on misaligned symbols"). While at it reword
the error message.
Old error message text (re-wrapped):
<sec-bfd>(<sec>+<off>): misaligned symbol `<sym>' (<addr>) for
relocation <rel>
New error message text (re-wrapped):
<sec-bfd>(<sec>+<off>): relocation <rel> against misaligned symbol
`<sym>' (<addr>) in <sym-bfd>
Note that the linker tests do not require to be updated, as they match
against the pattern ".*misaligned symbol.*", which has not changed in
the error message.
bfd/
PR ld/32969
* elf64-s390.c (elf_s390_relocate_section): Report BFD
in which a misaligned symbol is defined in error message.
Indu Bhagat [Mon, 19 May 2025 07:05:17 +0000 (00:05 -0700)]
gas: sframe: handle .cfi_undefined
Fix PR gas/32952 - sframe: incorrect handling of .cfi_undefined in gas
In context of SFrame generation, it is incorrect to simply ignore all
.cfi_undefined. We may ignore only those .cfi_undefined which are for
registers of no interest (similar to whats done for other CFI
directives).
gas/
* gen-sframe.c (sframe_xlate_do_cfi_undefined): New definition.
(sframe_do_cfi_insn): Handle .cfi_undefined.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe.exp: Add new tests.
* gas/cfi-sframe/cfi-sframe-common-10.d: New test.
* gas/cfi-sframe/cfi-sframe-common-10.s: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-4.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-4.s: New test.
Indu Bhagat [Mon, 19 May 2025 07:03:39 +0000 (00:03 -0700)]
gas: sframe: reword diagnostic to address ambiguity
The current warning text of "skipping SFrame FDE" does not unabiguously
indicate that the SFrame FDE is not generated in the output section.
Reword the diagnostic to say "no SFrame FDE emitted" as requested.
Indu Bhagat [Mon, 19 May 2025 07:01:29 +0000 (00:01 -0700)]
gas: sframe: i386: have the backend specify the RA too
To process some CFI directives like .cfi_undefined and .cfi_same_value,
it is necessary for correctness to detect all cases when the register
used is one of SP, FP or RA.
Currently, the backends needed to specify the SFRAME_CFA_RA_REG only in
the case of those ABIs where RA tracking was necessary, e.g. AArch64.
For AMD64, since the return address is always at a fixed offset from the
CFA, RA tracking was disabled.
The backends must now specify the applicable return address register via
SFRAME_CFA_RA_REG. This is necessary so that SFrame generation code can
then properly handle the cases when RA is used like so:
.cfi_undefined <RA>
or,
.cfi_same_value <RA>
Detecting these cases is necessary for correctness. E.g., on AMD64, we
need to skip FDE generation as the above constructs cannot be
represented in SFrame yet.
This change is a prerequisite to fixing the two PRs:
PR gas/32952 - sframe: incorrect handling of .cfi_undefined in gas
PR gas/32953 - sframe: incorrect handling of .cfi_same_value in gas
In the SFrame generation code in gen-sframe.c, instead of using
SFRAME_FRE_RA_TRACKING ifdef's, we now simply rely on the API
sframe_ra_tracking_p () to detect if RA-tracking is enabled for the
target.
While at it, use const variables for x86 backend.
ChangeLog:
* gas/config/tc-i386.c (x86_sframe_cfa_ra_reg): New definition.
* gas/config/tc-i386.h (REG_RA): New definition.
(SFRAME_CFA_RA_REG): New declaration.
* gas/gen-sframe.c (SFRAME_FRE_RA_TRACKING): Remove.
Alan Modra [Fri, 16 May 2025 03:01:39 +0000 (12:31 +0930)]
gas .align limit
At the moment we allow alignment of up to half the address space,
which is stupidly large and results in OOM on x86_64. Change that to
1G alignment in text sections. Also fix the warning message on
exceeding max allowed alignment.
* read.c (TC_ALIGN_LIMIT): Limit to 30 in text sections.
(s_align): Correct "alignment too large" value.
Jan Beulich [Fri, 16 May 2025 10:32:39 +0000 (12:32 +0200)]
gas: adjust a comparison in s_align()
In 344b1e0f5f79 ("gas: range-check 3rd argument of .align et al") I
neglected to consider compilers which warn about signed/unsigned
mismatches in comparisons (which is somewhat odd when the signed value is
already known to be non-negative).
Jan Beulich [Fri, 16 May 2025 08:37:46 +0000 (10:37 +0200)]
gas: range-check 3rd argument of .align et al
Negative values would have been silently converted to large positive
ones, which may not be the user's intention. Similarly overly large
values would have been silently truncated. Warn them instead, and zap
such values.
Collin Funk [Fri, 16 May 2025 08:37:16 +0000 (10:37 +0200)]
ld/doc: Remove '.info' suffix in @ref, etc
Texinfo 7.2 began showing warnings like:
ld.texi:1026: warning: do not set .info suffix in reference for manual `gcc.info'
ld.texi:9689: warning: do not set .info suffix in reference for manual `binutils.info'
The Texinfo developers plan to stop removing the '.info' suffix
internally in a future release so without this patch the references will
break in the future.
Collin Funk [Fri, 16 May 2025 08:37:04 +0000 (10:37 +0200)]
binutils/doc: Remove '.info' suffix in @ref, etc
Texinfo 7.2 began showing warnings like:
binutils.texi:882: warning: do not set .info suffix in reference for manual `ld.info'
binutils.texi:1365: warning: do not set .info suffix in reference for manual `ld.info'
The Texinfo developers plan to stop removing the '.info' suffix
internally in a future release so without this patch the references will
break in the future.
Jan Beulich [Fri, 16 May 2025 08:32:19 +0000 (10:32 +0200)]
x86: improve matching diagnostics when %st is involved
Diagnosing operand size vs operand type mismatches doesn't work very
well when GPRs and FPRs are in the same register class, distinguished
just by size. Introduce a separate RegFP class.
Jan Beulich [Fri, 16 May 2025 08:31:35 +0000 (10:31 +0200)]
x86: move Anysize check in operand_size_match()
Anysize is applicable to memory operands only. Move the check to where
memory operands are handled. (The RegSIMD part there was questionable
altogether.)
Jan Beulich [Fri, 16 May 2025 08:27:55 +0000 (10:27 +0200)]
x86: improve matching diagnostics when "accumulator" registers are involved
In templates, the expectation of an "accumulator" register to be used is
expressed solely by operand size; there's no "class" specifier there.
Hence operand_size_match() is too eager in invoking
match_{operand,simd}_size(), resulting in "operand size mismatch" errors
when it's the type (of register), not the size that's wrong.
Interestingly adjustments there alone lead to no error at all then: To
"compensate", operand_type_match() needs to disambiguate register types
when register instances are specified in the template (matching the
actual operand), by checking a match (overlap) in operand sizes.
Jan Beulich [Fri, 16 May 2025 08:27:20 +0000 (10:27 +0200)]
x86: fold Accum checking in operand_size_match()
There's little point invoking match_{operand,simd}_size() twice per
loop; in fact the SIMD case with D set simply doesn't exist. Amend the
checks by one looking at the given operand, just like we already have
been doing for memory ones.
Jan Beulich [Fri, 16 May 2025 08:26:45 +0000 (10:26 +0200)]
x86: improve matching diagnostics
Many times in the past I was puzzled by seeing "operand size mismatch"
when really "operand type mismatch" would be far more appropriate. As it
turns out, there were at least two flaws: In the single operand case we
didn't propagate i.error to match_template()'s local specific_error when
noticing a type mismatch. And then operand_size_match() was too eager in
invoking match_mem_size(): Especially the Unspecified attribute can get
in the way there when the expected operand isn't a memory one (and hence
Unspecified would not be set in the operand template, whereas it's
uniformly set for memory operands in AT&T syntax).
(In the x86-64-lkgs-inval testcase the particular error for the two
bogus Intel syntax forms doesn't really matter; all we ought to care
about there isthat there is _some_ error.)
Jan Beulich [Fri, 16 May 2025 08:25:38 +0000 (10:25 +0200)]
x86: drop bogus accumulator check
Accum is an "instance", not a "class". With present enumerator values of
Reg and Accum, the 2nd check simply did the same as the first. In fact
checking for the accumulator (%rax) isn't necessary here at all, because
there's no case where an individual template would permit alternatively
a memory operand or the (qword) accumulator; only "any GPR" is ever
being paired with "memory".
Tsukasa OI [Tue, 13 May 2025 08:14:01 +0000 (08:14 +0000)]
RISC-V: check offsets when linker relaxation is disabled
The assembler partially relied on the linker to check whether the
offset is valid. However, some optimization logic (added later)
removes relocations relative to local symbols without checking offsets.
For instance, it caused following code to silently emit wrong jumps
(to the jump instruction "." itself) without relocations:
> .option norelax
> j .+0x200000 # J (or JAL) instruction cannot encode this offset.
> j .+1 # Jump to odd address is not valid.
This commit adds offset checks where necessary.
gas/ChangeLog:
* config/tc-riscv.c (md_apply_fix): Check offsets when the
relocation relative to a local symbol is being optimized out.
* testsuite/gas/riscv/no-relax-branch-offset-fail.s: Failure
case where the branch offset is invalid.
* testsuite/gas/riscv/no-relax-branch-offset-fail.d: Ditto.
* testsuite/gas/riscv/no-relax-branch-offset-fail.l: Ditto.
* testsuite/gas/riscv/no-relax-branch-offset-ok.s: Border case.
* testsuite/gas/riscv/no-relax-branch-offset-ok.d: Ditto.
* testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.s: Failure
case only on RV64 where the PC-relative offset exceed limits.
* testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.d: Ditto.
* testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.l: Ditto.
* testsuite/gas/riscv/no-relax-pcrel-offset-fail-not-32.d: Test
case for RV32 so that no errors occur.
* testsuite/gas/riscv/no-relax-pcrel-offset-ok.s: Border case.
* testsuite/gas/riscv/no-relax-pcrel-offset-ok.d: Ditto.
Indu Bhagat [Thu, 15 May 2025 19:21:05 +0000 (12:21 -0700)]
gas: sframe: avoid creating more symbols than necessary for FRE offset
Each SFrame FDE contains an offset to the start of its respective SFrame
FREs in the sfde_func_start_fre_off field. To generate this offset,
fre_symbols[] array is being used. The number of elements of this array
is currently set to the total number of SFrame FREs in the entire SFrame
section. This is more than unnecessary. We only need to track as many
points as the number of SFrame FDEs.
gas/
* gen-sframe.c (output_sframe_internal): Size fde_fre_symbols
with the number of SFrame FDEs.
Tom Tromey [Tue, 13 May 2025 19:41:26 +0000 (13:41 -0600)]
Fix regression with dynamic array bounds
Kévin discovered that commit ba005d32b0f ("Handle dynamic field
properties") regressed a test in the internal AdaCore test suite.
The problem here is that, when writing that patch, I did not consider
the case where an array type's bounds might come from a member of a
structure -- but where the array is not defined in the structure's
scope.
In this scenario the field-resolution logic would trip this condition:
/* Defensive programming in case we see unusual DWARF. */
if (fi == nullptr)
return nullptr;
This patch reworks this area, partly backing out that commit, and
fixes the problem.
In the new code, I chose to simply duplicate the field's location
information. This isn't totally ideal, in that it might result in
multiple copies of a baton. However, this seemed nicer than tracking
the DIE/field correspondence for every field in every CU -- my
thinking here is that this particular dynamic scenario is relatively
rare overall. Also, if the baton cost does prove onerous, we could
intern the batons somewhere.
Regression tested on x86-64 Fedora 41. I also tested this using the
AdaCore internal test suite.
Tested-By: Simon Marchi <simon.marchi@efficios.com>
H.J. Lu [Wed, 14 May 2025 23:30:06 +0000 (07:30 +0800)]
binutils: Don't complain plugin with all LTO sections removed
When all LTO sections have been removed, the BFD lto_type is set to
lto_non_ir_object by bfd_set_lto_type. In this case, don't complain
needing a plugin when seeing a LTO slim symbol.
Alan Modra [Wed, 14 May 2025 22:59:37 +0000 (08:29 +0930)]
gas .file 0 vs. dwarf5
Support added in commit 3417bfca676f for dwarf5 directory table 0
assumed that .file 0 was always the first debug .file directive.
That's not necessarily true.
* dwarf2dbg.c (get_directory_table_entry): Don't assume entry
1 is available after putting DW_AT_comp_dir in entry 0. Pass
pwd as file0_dirname to recursive call to avoid another
getpwd in the case file0_dirname is NULL.
Rohr, Stephan [Mon, 24 Mar 2025 13:05:33 +0000 (13:05 +0000)]
testsuite: fix gdb_exit for MinGW target
GDB is not properly exited via 'remote_close host' when running the
testsuite in a MinGW environment. Use the 'quit' command to properly
exit the GDB debugging session.
Tom Tromey [Mon, 12 May 2025 17:30:33 +0000 (11:30 -0600)]
Fix create_breakpoint_parse_arg_string self-test
The emoji patch broke the create_breakpoint_parse_arg_string self-test
when gdb is running on a suitable terminal. The problem is that the
test case doesn't take the error prefix string into account.
This patch fixes the test by having it compare the exception message
directly, rather than relying on the result of exception_print. I did
try a different approach, of having the test mimic exception_print,
but this one seemed cleaner to me.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Alan Modra [Wed, 14 May 2025 05:18:33 +0000 (14:48 +0930)]
gas .file sanity check
Currently we allow insane file numbers that cause gas to allocate up
to 4G of memory for a file array. Trim that a little to 1G (which
still allows insane file numbers up to 33554431), and tidy function
parameter types so that we only need one file number sanity check.
* dwarf2dbg.c (assign_file_to_slot): Take a valueT file number.
Reduce max files array size.
(allocate_filename_to_slot): Take a valueT file number.
(dwarf2_directive_filename): Don't duplicate file number
sanity check here.
H.J. Lu [Sat, 3 May 2025 21:12:46 +0000 (05:12 +0800)]
strip: Add GCC LTO IR support
Add GCC LTO IR support to strip by copying GCC LTO IR input as unknown
object file. Don't enable LTO plugin in strip unless all LTO sections
should be removed, assuming all LTO sections will be removed with
-R .gnu.lto_.*. Add linker LTO tests for strip with --strip-unneeded
and GCC LTO IR inputs.
binutils/
PR binutils/21479
* objcopy.c: Include "plugin-api.h" and "plugin.h".
(lto_sections_removed): New.
(command_line_switch): Add OPTION_PLUGIN.
(strip_options): Likewise.
(strip_usage): Display "--plugin NAME".
(copy_unknown_file): New function.
(copy_unknown_object): Call copy_unknown_file.
(copy_archive): Copy input LTO IR member as unknown object.
(copy_file): Set input target to "plugin" for strip if it is
unset unless all LTO sections should be removed. Copy input
LTO IR file as unknown file.
(strip_main): Call bfd_plugin_set_program_name. Handle
OPTION_PLUGIN. Set lto_sections_removed to true if all GCC
LTO sections should be removed.
* doc/binutils.texi: Document --plugin for strip.
Alice Carlotti [Fri, 4 Apr 2025 18:23:11 +0000 (19:23 +0100)]
aarch64: Replace incorrect comment
The comment explaining the placement of the cfinv entry before the
generic msr entry in the opcode table was incorrect. The issue is
unrelated to the all ones bitmask for cfinv, and is actually due the
large number of architectural aliases of the msr instruction.
Andrew Burgess [Sun, 13 Apr 2025 10:26:41 +0000 (11:26 +0100)]
gdb/python: new gdb.ParameterPrefix class
This commit adds a new gdb.ParameterPrefix class to GDB's Python API.
When creating multiple gdb.Parameters, it is often desirable to group
these together under a sub-command, for example, 'set print' has lots
of parameters nested under it, like 'set print address', and 'set
print symbol'. In the Python API the 'print' part of these commands
are called prefix commands, and are created using gdb.Command objects.
However, as parameters are set via the 'set ....' command list, and
shown through the 'show ....' command list, creating a prefix for a
parameter usually requires two prefix commands to be created, one for
the 'set' command, and one for the 'show' command.
This often leads to some duplication, or at the very least, each user
will end up creating their own helper class to simplify creation of
the two prefix commands.
This commit adds a new gdb.ParameterPrefix class. Creating a single
instance of this class will create both the 'set' and 'show' prefix
commands, which can then be used while creating the gdb.Parameter.
This adds 'set my-prefix' and 'show my-prefix', both of which are
prefix commands. The user can then add gdb.Parameter objects under
these prefixes.
The gdb.ParameterPrefix initialise method also supports documentation
strings, so we can write:
gdb.ParameterPrefix('my-prefix', gdb.COMMAND_NONE,
"Configuration setting relating to my special extension.")
which will set the documentation string for the prefix command.
Also, it is possible to support prefix commands that use the `invoke`
functionality to handle unknown sub-commands. This is done by
sub-classing gdb.ParameterPrefix and overriding either 'invoke_set' or
'invoke_show' to handle the 'set' or 'show' prefix command
respectively.
Andrew Burgess [Sat, 12 Apr 2025 14:42:25 +0000 (15:42 +0100)]
gdb/guile: generate general description string for parameters
This commit builds on the previous one, and auto-generates a general
description string for parameters defined via the Guile API. This
brings the Guile API closer inline with the Python API. It is worth
reading the previous commit to see some motivating examples.
This commit updates get_doc_string in guile/scm-param.c to allow for
the generation of a general description string. Then in
gdbscm_make_parameter, if '#:doc' was not given, get_doc_string is
used to generate a suitable default.
This does invalidate (and so the commit removes) this comment that was
in gdbscm_make_parameter:
/* If doc is NULL, leave it NULL. See add_setshow_cmd_full. */
First, Python already does exactly what I'm proposing here, and has
done for a while, with no issues reported. And second, I've gone and
read add_setshow_cmd_full, and some of the functions it calls, and can
see no reasoning behind this comment...
... well, there is one reason that I can think of, but I'll discuss
that more below.
With this commit, if I define a parameter like this:
(gdb) help show print test
Show the current value of 'print test'.
This command is not documented.
(gdb) help set print test
Set the current value of 'print test'.
This command is not documented.
(gdb)
The two 'This command is not documented.' lines are new. This output
is what we get from a similarly defined parameter using the Python
API (see the previous commit for an example).
I mentioned above that I can think of one reason for the (now deleted)
comment in gdbscm_make_parameter about leaving the doc field as NULL,
and that is this: consider the following GDB behaviour:
(gdb) help show style filename foreground
Show the foreground color for this property.
(gdb)
Notice there is only a single line of output. If I want to get the
same behaviour from a parameter defined in Guile, I might try skipping
the #:doc argument, but (after this commit), if I do that, GDB will
auto-generate some text for me, giving two lines of output (see
above).
So, next, maybe I try setting #:doc to the empty string, but if I do
that, then I get this:
(gdb) help show print test
Show the current value of 'print test'.
(gdb)
Notice the blank line, that's not what I wanted. In fact, the only
way to get rid of the second line is to leave the 'doc' variable as
NULL in gdbscm_make_parameter, which, due to the new auto-generation,
is no longer possible.
This issue also existed in the Python API, and was addressed in
commit:
After this commit, an empty __doc__ string for a gdb.Parameter is
translated into a NULL pointer passed to the add_setshow_* command,
which means the second line of output is completely skipped.
And this commit includes the same solution for the Guile API. Now,
with this commit, and the Guile parameter using an empty '#:doc'
string, GDB has the following behaviour:
(gdb) help show print test
Show the current value of 'print test'.
(gdb)
This matches the output for a similarly defined parameter in Python.
Andrew Burgess [Sat, 12 Apr 2025 13:19:20 +0000 (14:19 +0100)]
gdb/guile: improve auto-generated strings for parameters
Consider this user defined parameter created in Python:
class test_param(gdb.Parameter):
def __init__(self, name):
super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
self.value = True
test_param('print test')
If this is loaded into GDB, then we observe the following behaviour:
(gdb) show print test
The current value of 'print test' is "on".
(gdb) help show print test
Show the current value of 'print test'.
This command is not documented.
(gdb) help set print test
Set the current value of 'print test'.
This command is not documented.
(gdb)
And load this into a fresh GDB session, we see the following:
(gdb) show print test
Command is not documented is off.
(gdb) help show print test
This command is not documented.
(gdb) help set print test
This command is not documented.
(gdb)
The output of 'show print test' doesn't make much sense, and is
certainly worse than the Python equivalent. For both the 'help'
commands it appears as if the first line is missing, but what is
actually happening is that the first line has become 'This command is
not documented.', and the second line is then missing.
The problems can all be traced back to 'get_doc_string' in
guile/scm-param.c. This is the guile version of this function. There
is a similar function in python/py-param.c, however, the Python
version returns one of three different strings depending on the use
case. In contrast, the Guile version just returns 'This command is
not documented.' in all cases.
The three cases that the Python code handles are, the 'set' string,
the 'show' string, and the general 'description' string.
Right now the Guile get_doc_string only returns the general
'description' string, which is funny, because, in
gdbscm_make_parameter, where get_doc_string is used, the one case that
we currently don't need is the general 'description' string. Instead,
right now, the general 'description' string is used for both the 'set'
and 'show' cases.
In this commit I plan to bring the Guile API a little more inline with
the Python API. I will update get_doc_string (in scm-param.c) to
return either a 'set' or 'show' string, and gdbscm_make_parameter will
make use of these strings.
The changes to the Guile get_doc_string are modelled on the Python
version of this function. It is also worth checking out the next
commit, which is related, and helps motivate how the changes have been
implemented in this commit.
After this commit, the same Guile parameter description shown above,
now gives this behaviour:
(gdb) show print test
The current value of 'print test' is off.
(gdb) help show print test
Show the current value of 'print test'.
(gdb) help set print test
Set the current value of 'print test'.
(gdb)
The 'show print test' output now matches the Python behaviour, and is
much more descriptive. The set and show 'help' output are now missing
the second line when compared to the Python output, but the first line
is now correct, and I think this is better than the previous Guile
output.
In the next commit I'll address the problem of the missing second
line.
Existing tests have been updated to expect the new output.
I was recently attempting to create some parameters via the Python
API. I wanted these parameters to appear similar to how GDB handles
the existing 'style' parameters.
Specifically, I was interested in this behaviour:
(gdb) help show style filename foreground
Show the foreground color for this property.
(gdb) help set style filename foreground
Set the foreground color for this property.
(gdb)
Notice how each 'help' command only gets a single line of output.
I tried to reproduce this behaviour via the Python API and was unable.
The problem is that, in order to get just a single line of output like
this, the style parameters are registered with a call to
add_setshow_color_cmd with the 'help_doc' being passed as nullptr.
On the Python side, when parameters are created, the 'help_doc' is
obtained with a call to get_doc_string (python/py-param.c). This
function either returns the __doc__ string, or a default string: "This
command is not documented.".
To avoid returning the default we could try setting __doc__ to an
empty string, but setting this field to any string means that GDB
prints a line for that string, like this:
class test_param(gdb.Parameter):
__doc__ = ""
def __init__(self, name):
super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
self.value = True
test_param('print test')
Then in GDB:
(gdb) help set print test
Set the current value of 'print test'.
(gdb)
The blank line is the problem I'd like to solve.
This commit makes a couple of changes to how parameter doc strings are
handled.
If the doc string is set to an empty string, then GDB now converts
this to nullptr, which removes the blank line problem, the new
behaviour in GDB (for the above `test_param`) is:
(gdb) help set print test
Set the current value of 'print test'.
(gdb)
Next, I noticed that if the set/show docs are set to empty strings,
then the results are less than ideal:
class test_param(gdb.Parameter):
set_doc = ""
def __init__(self, name):
super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
self.value = True
test_param('print test')
And in GDB:
(gdb) help set print test
This command is not documented.
(gdb)
So, if the set/show docs are the empty string, GDB now forces these to
be the default string instead, the new behaviour in GDB is:
(gdb) help set print test
Set the current value of 'print test'.
This command is not documented.
(gdb)
I've added some additional asserts; the set/show docs should always be
non-empty strings, which I believe is the case after this commit. And
the 'doc' string returned from get_doc_string should never nullptr,
but could be empty.
This completes without error, however, we didn't get what we were
maybe expecting:
(gdb) show print xxx foo
Undefined show print command: "xxx foo". Try "help show print".
But we did get:
(gdb) show print foo
The current value of 'print foo' is "off".
GDB stopped scanning the prefix string at the unknown 'xxx', and just
created the parameter there. I don't think this makes sense, nor is
it inline with the manual.
An identical problem exists with gdb.Command creation; GDB stops
parsing the prefix at the first unknown prefix, and just creates the
command there. The manual for gdb.Command says:
NAME is the name of the command. If NAME consists of multiple
words, then the initial words are looked for as prefix commands.
In this case, if one of the prefix commands does not exist, an
exception is raised.
So again, the correct action is, I believe, to raise an exception.
The problem is in gdbpy_parse_command_name (python/py-cmd.c), GDB
calls lookup_cmd_1 to look through the prefix string and return the
last prefix group. If the very first prefix word is invalid then
lookup_cmd_1 returns NULL, and this case is handled. However, if
there is a valid prefix, followed by an invalid prefix, then
lookup_cmd_1 will return a pointer to the last valid prefix list, and
will update the input argument to point to the start of the invalid
prefix word. This final case, where the input is left pointing to an
unknown prefix, was previously not handled.
I've fixed gdbpy_parse_command_name, and added tests for command and
parameter creation to cover this case.
The exact same error is present in the guile API too. The guile
documentation for make-parameter and make-command says the same things
about unknown prefixes resulting in an exception, but the same error
is present in gdbscm_parse_command_name (guile/scm-cmd.c), so I've
fixed that too, and added some tests.
Simon Marchi [Tue, 6 May 2025 17:03:47 +0000 (13:03 -0400)]
gdb/dwarf: skip broken .debug_macro.dwo
Running gdb.base/errno.exp with gcc <= 13 with split DWARF results in:
$ make check TESTS="gdb.base/errno.exp" RUNTESTFLAGS="CC_FOR_TARGET=gcc-13 --target_board=fission"
(gdb) break -qualified main
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7549: internal-error: locate_dwo_sections: Assertion `!dw_sect->readin' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...
FAIL: gdb.base/errno.exp: macros: gdb_breakpoint: set breakpoint at main (GDB internal error)
The assert being hit has been added in 28f15782adab ("gdb/dwarf: read
multiple .debug_info.dwo sections"), but it merely exposed an existing
problem.
Basically, it produces .dwo files with multiple .debug_macro.dwo
sections, with some unresolved links between them. I think that this
macro debug info is unusable, and all we can do is ignore it.
In locate_dwo_sections, if we detect a second .debug_macro.dwo section,
forget about the previous .debug_macro.dwo and any subsequent one. This
will effectively make it as if the macro debug info wasn't there at all.
The errno test seems happy with it:
# of expected passes 84
# of expected failures 8
Change-Id: I6489b4713954669bf69f6e91865063ddcd1ac2c8 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Tue, 6 May 2025 17:03:46 +0000 (13:03 -0400)]
gdb/dwarf: move loops into locate_dw{o,z}_sections
For a subsequent patch, it would be easier if the loop over sections
inside locate_dwo_sections (I want to maintain some state for the
duration of the loop). Move the for loop in there. And because
locate_dwz_sections is very similar, modify that one too, to keep both
in sync.
Change-Id: I90b3d44184910cc2d86af265bb4b41828a5d2c2e Approved-By: Tom Tromey <tom@tromey.com>
oltolm [Sat, 10 May 2025 08:56:12 +0000 (10:56 +0200)]
gdb/dap: fix decode_source
The documentation for the Source interface says
* The path of the source to be shown in the UI.
* It is only used to locate and load the content of the source if no
* `sourceReference` is specified (or its value is 0).
but the code used `path` first. I fixed it to use `sourceReference` first.
Keith Seitz [Mon, 12 May 2025 16:28:02 +0000 (09:28 -0700)]
[PATCH] Add syscall tests when following/detaching from fork
breakpoints/13457 discusses issues with syscall catchpoints when
following forks, lamenting that there is no coverage for the
various permutations of `follow-fork-mode' and `detach-on-fork'.
This is an attempt to try and cover some of this ground. Unfortunately
the state of syscall support when detaching after the fork is
very, very inconsistent across various architectures. [I've tested
extensively Fedora/RHEL platforms.]
Right now, the only reliable platform to run tests on is x86_64/i?86
for the specific case where we do not detach from the fork. Consequently,
this patch limits testing to those architectures.
I have updated breakpoints/13457 with my findings on failures with the
detaching case.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13457 Approved-By: Andrew Burgess <aburgess@redhat.com>
Ezra Sitorus [Fri, 2 May 2025 17:08:21 +0000 (18:08 +0100)]
aarch64: Support for FEAT_RME_GPC3
FEAT_RME_GPC3 - RME Granule Protection Check 3 Extension - introduces
a method for defining a set of windows in the memory map for which
Granule Protection Checks are skipped, and instead applies a set of
default settings associated with the window.
This patch introduces the sysreg gpcbw_el3. Add -march=armv9.5-a to
access this sysreg since this feature is optional from armv9.5-a.
Ezra Sitorus [Fri, 2 May 2025 16:14:07 +0000 (17:14 +0100)]
aarch64: Support for FEAT_OCCMO
FEAT_OCCMO - Outer Cacheable Cache Maintenance Operation - introduces
system instructions that provides software with a mechanism to publish
writes to the Outer cache level.
Patrick Monnerat [Mon, 12 May 2025 15:36:17 +0000 (17:36 +0200)]
gdbsupport/event-loop: do not truncate poll timeouts to lower second
In update_wait_timeout function, microseconds were not taken into account
in poll timeout computation, resulting in 100% cpu time consumption in
the event loop while waiting for a sub-second timeout.
This patch adds the microseconds converted to milliseconds in poll
timeout computation. Conversion by excess (ceil) is performed to
avoid the same problem with sub-millisecond timeouts too.
Andrew Burgess [Wed, 7 May 2025 10:00:13 +0000 (11:00 +0100)]
gdb: pass std::string from linux_find_memory_regions_full
Update linux_find_memory_region_ftype to take 'const std::string &'
instead of 'const char *', update the two functions which are passed
as callbacks to linux_find_memory_regions_full.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Wed, 7 May 2025 09:53:41 +0000 (10:53 +0100)]
gdb: move extra checks into dump_note_entry_p
Now that dump_note_entry_p is always called (see previous commit), we
can move some of the checks out of linux_make_mappings_callback into
dump_note_entry_p.
The checks only exist in linux_make_mappings_callback because, before
the previous commit, we couldn't be sure that dump_note_entry_p would
be called or not, so linux_make_mappings_callback had to run its own
checks.
Now that dump_note_entry_p is always called we can rely on that
function to filter out which mappings should result in an NT_FILE
entry, and linux_make_mappings_callback can just create an entry for
everything it is passed.
As a result of this change I was able to remove the inode argument
from linux_make_mappings_callback and
linux_find_memory_regions_thunk. The inode check has now moved to
dump_note_entry_p.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
projects / thirdparty / binutils-gdb.git / log
