Haochen Jiang [Tue, 19 Dec 2023 08:35:00 +0000 (16:35 +0800)]
x86: Remove the restriction for size of the mask register in AVX10
Since AVX10.1/256 will also allow 64 bit mask register, we will
remove the restriction for size of the mask register in AVX10.
gas/ChangeLog:
* config/tc-i386.c (VSZ128, VSZ256, VSZ512): New.
(VEX_check_encoding): Remove opcode_modifier check for vsz.
* testsuite/gas/i386/avx10-vsz.l: Remove testcases for mask
registers since they are not needed.
* testsuite/gas/i386/avx10-vsz.s: Ditto.
Xi Ruoyao [Tue, 5 Dec 2023 19:05:47 +0000 (03:05 +0800)]
LoongArch: Allow la.got -> la.pcrel relaxation for shared object
Even in shared objects, la.got -> la.pcrel relaxation can still be
performed for symbols with hidden visibility. For example, if a.c is:
extern int x;
int f() { return x++; }
and b.c is:
int x = 114514;
If compiling and linking with:
gcc -shared -fPIC -O2 -fvisibility=hidden a.c b.c
Then the la.got in a.o should be relaxed to la.pcrel, and the resulted f
should be like:
pcaddi $t0, x
ldptr.w $a0, $t0, 0
addi.w $t1, $a0, 1
stptr.w $t1, $t0, 0
ret
Remove bfd_link_executable from the condition of la.got -> la.pcrel
relaxation so this will really happen. The SYMBOL_REFERENCES_LOCAL
check is enough not to wrongly relax preemptable symbols (for e.g.
when -fvisibility=hidden is not used).
Note that on x86_64 this is also relaxed and the produced code is like:
Tested by running ld test suite, bootstrapping and regtesting GCC with
the patched ld, and building and testing Glibc with the patched ld. No
regression is observed.
Jeff Law [Tue, 19 Dec 2023 05:04:25 +0000 (22:04 -0700)]
Yet another fix for mcore-sim (rotli)
This came up testing the CRC optimization work from Mariam@RAU.
Basically to optimize some CRC loops into table lookups or carryless
multiplies, we may need to do a bit reflection, which on the mcore
processor is done using a rotate instruction.
Unfortunately the simulator implementation of rotates has the exact same
problem as we saw with right shifts. The input value may have been sign
extended from 32 to 64 bits. When we rotate the extended value, we get
those sign extension bits and thus the wrong result.
The fix is the same. Rather than using a "long", use a uint32_t for the
type of the temporary. This fixes a handful of tests in the GCC testsuite:
Thread 1 "thread-specific" hit Breakpoint 4, end () at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29
29 }
(gdb) [Thread 0x7ffff7c5c700 (LWP 1552086) exited]
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.
FAIL: gdb.threads/thread-specific-bp.exp: non_stop=on: continue to end (timeout)
...
This only crops up (for me) when running on a loaded machine, and
still only occurs sometimes. I've had to leave the test running in a
loop for 10+ minutes sometimes in order to see the failure.
The problem is that we use gdb_test_multiple to try and match two
patterns:
(1) The 'Thread-specific breakpoint 3 deleted ....' message, and
(2) The GDB prompt.
As written in the test, we understand that these patterns can occur in
any order, and we have a flag for each pattern. Once both patterns
have been seen then we PASS the test.
The problem is that once expect has matched a pattern, everything up
to, and including the matched text is discarded from the input
buffer. Thus, if the input buffer contains:
<PATTERN 2><PATTERN 1>
Then expect will first try to match <PATTERN 1>, which succeeds, and
then expect discards the entire input buffer up to the end of the
<PATTERN 1>. As a result, we will never spot <PATTERN 2>.
Obviously we can't just reorder the patterns within the
gdb_test_multiple, as the output can legitimately (and most often
does) occur in the other order, in which case the test would mostly
fail, and only occasionally pass!
I think the easiest solution here is just to have the
gdb_test_multiple contain two patterns, each pattern consists of the
two parts, but in the alternative orders, thus, for a particular
output configuration, only one regexp will match. With this change in
place, I no longer see the intermittent failure.
mengqinggang [Thu, 23 Nov 2023 07:42:49 +0000 (15:42 +0800)]
LoongArch: Add call36 and tail36 pseudo instructions for medium code model
For tail36, it is necessary to explicitly indicate the temporary register.
Therefore, the compiler and users will know that the tail will use a register.
Georg-Johann Lay [Sun, 17 Dec 2023 18:20:54 +0000 (19:20 +0100)]
PR31177: Let region text start at __TEXT_REGION_ORIGIN___
The start of MEMORY region text currently starts hard-coded at 0.
The linker can produce more exact diagnostics when it knows the exact placements of the memory regions.
For some old devices, program memory starts at 0x8000, so allow to specify program memory start at __TEXT_REGION_ORIGIN__ similar to how the data region is described.
If ok, please apply to master.
This one is also fine to back-port.
Johann
--
AVR: Use __TEXT_REGION_ORIGIN__ as start for MEMORY region text.
ld/
PR 31177
* scripttempl/avr.sc (__TEXT_REGION_ORIGIN__): New symbol.
(MEMORY): Use as start address for the text region.
Hannes Domani [Sat, 16 Dec 2023 10:24:16 +0000 (11:24 +0100)]
Use function entry point record only for entry values
PR28987 notes that optimized code sometimes shows the wrong
value of variables at the entry point of a function, if some
code was optimized away and the variable has multiple values
stored in the debug info for this location.
In this example:
```
void foo()
{
int l_3 = 5, i = 0;
for (; i < 8; i++)
;
test(l_3, i);
}
```
When compiled with optimization, the entry point of foo is at
the test() function call, since everything else is optimized
away.
The debug info of i looks like this:
```
(gdb) info address i
Symbol "i" is multi-location:
Base address 0x140001600 Range 0x13fd41600-0x13fd41600: the constant 0
Range 0x13fd41600-0x13fd41600: the constant 1
Range 0x13fd41600-0x13fd41600: the constant 2
Range 0x13fd41600-0x13fd41600: the constant 3
Range 0x13fd41600-0x13fd41600: the constant 4
Range 0x13fd41600-0x13fd41600: the constant 5
Range 0x13fd41600-0x13fd41600: the constant 6
Range 0x13fd41600-0x13fd41600: the constant 7
Range 0x13fd41600-0x13fd4160f: the constant 8
(gdb) p i
$1 = 0
```
Currently, when at the entry point of a function, it will
always show the initial value (here 0), while the user would
expect the last value (here 8).
This logic was introduced for showing the entry-values of
function arguments if they are available, but for some
reason this was added for non-entry-values as well.
One of the tests of amd64-entry-value.exp shows the same
problem for function arguments, if you "break stacktest"
in the following example, you stop at this line:
```
124 static void __attribute__((noinline, noclone))
125 stacktest (int r1, int r2, int r3, int r4, int r5, int r6, int s1, int s2,
126 double d1, double d2, double d3, double d4, double d5, double d6,
127 double d7, double d8, double d9, double da)
128 {
129 s1 = 3;
130 s2 = 4;
131 d9 = 3.5;
132 da = 4.5;
133 -> e (v, v);
134 asm ("breakhere_stacktest:");
135 e (v, v);
136 }
```
But `bt` still shows the entry values:
```
s1=s1@entry=11, s2=s2@entry=12, ..., d9=d9@entry=11.5, da=da@entry=12.5
```
I've fixed this by only using the initial values when
explicitely looking for entry values.
Now the local variable of the first example is as expected:
```
(gdb) p i
$1 = 8
```
And the test of amd64-entry-value.exp shows the expected
current and entry values of the function arguments:
```
s1=3, s1@entry=11, s2=4, s2@entry=12, ..., d9=3.5, d9@entry=11.5, da=4.5, da@entry=12.5
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28987 Tested-By: Guinevere Larsen <blarsen@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Sat, 16 Dec 2023 09:39:17 +0000 (10:39 +0100)]
[gdb/build] Remove dependency on _rl_term_autowrap
Commit deb1ba4e38b ("[gdb/tui] Fix TUI resizing for TERM=ansi") introduced a
dependency on readline private variable _rl_term_autowrap.
There is precedent for this, but it's something we want to get rid of
(PR build/10723).
Remove the dependency on _rl_term_autowrap, and instead calculate
readline_hidden_cols by comparing the environment variable COLS with cols as
returned by rl_get_screen_size.
Mike Frysinger [Sat, 16 Dec 2023 05:29:36 +0000 (00:29 -0500)]
sim: cr16: clean up unused insn operands
The push/pop insns only have 2 operands, so delete unused "c".
The pushret/popret insns use 2 operands, but they don't implement the
logic directly, they call the push/pop implementations. So delete the
unused "a" & "b".
Mike Frysinger [Sat, 16 Dec 2023 04:54:40 +0000 (23:54 -0500)]
sim: sh: adjust some dsp insn masks
The pmuls encoding is incorrect -- it looks like a copy & paste error
from the padd pmuls variant. The SuperH software manual covers this.
On the flip side, the manual lists pwsb & pwad as insns that exist,
but no description of what they do, what the insn name means, or the
actual encoding. Our sim implementation stubs them both out as nops.
Let's mark the fields to avoid unused variable warnings.
Mike Frysinger [Thu, 7 Dec 2023 03:08:01 +0000 (20:08 -0700)]
sim: mn10300: fix incorrect implementation of a few insns
Fix a few problems caught by compiler warnings:
* Some of the asr & lsr insns were setting up the c state flag,
but then forgetting to set it in the PSW. Add it like the other
asr & lsr variants.
* Some of the dmulh insns were multiplying one of the source regs
against itself instead of against the other source reg.
* The sat16_cmp parallel insn was using the wrong register in the
compare -- the reg1 src/dst pair are used in the sat16 op, and
the reg2 src/dst pair are used in the add op.
Tom Tromey [Tue, 28 Nov 2023 21:26:56 +0000 (14:26 -0700)]
Refine Ada overload matching
Currently, the overload handling in Ada assumes that any two array
types are compatible. However, this is obviously untrue, and a user
reported an oddity where comparing two Ada strings resulted in a call
to the "=" function for packed boolean arrays.
This patch improves the situation somewhat, by requiring that the two
arrays have the same arity and compatible base element types. This is
still over-broad, but it seems safe and is better than the status quo.
Matthieu Longo [Fri, 15 Dec 2023 15:08:28 +0000 (15:08 +0000)]
arm: reformat -march option section in gas documentation
Hi,
This patch contains a reformatting of -march option section in gas documentation.
For instance (see https://sourceware.org/binutils/docs-2.41/as.html#ARM-Options),
before all the options were on one line:
For armv8-a:
+crc: Enables CRC32 Extension. +simd: Enables VFP and NEON for Armv8-A. +crypto: Enables
Cryptography Extensions for Armv8-A, implies +simd. +sb: Enables Speculation Barrier
Instruction for Armv8-A. +predres: Enables Execution and Data Prediction Restriction
Instruction for Armv8-A. +nofp: Disables all FPU, NEON and Cryptography Extensions.
+nocrypto: Disables Cryptography Extensions.
Now, the readability is improved thanks to the itemization of the options:
For armv8-a:
+crc: Enables CRC32 Extension.
+simd: Enables VFP and NEON for Armv8-A.
+crypto: Enables Cryptography Extensions for Armv8-A, implies +simd.
+sb: Enables Speculation Barrier Instruction for Armv8-A.
+predres: Enables Execution and Data Prediction Restriction Instruction for Armv8-A.
+nofp: Disables all FPU, NEON and Cryptography Extensions.
+nocrypto: Disables Cryptography Extensions.
Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf.
Jan Beulich [Fri, 15 Dec 2023 11:42:43 +0000 (12:42 +0100)]
x86: last-insn recording should be per-subsection
Otherwise intermediate subsection switches result in inconsistent
behavior. Leverage ELF's section change hook to switch state as
necessary, limiting overhead to the bare minimum when subsections aren't
used.
Jan Beulich [Fri, 15 Dec 2023 11:41:49 +0000 (12:41 +0100)]
ELF: reliably invoke md_elf_section_change_hook()
... after any (sub)section change. While certain existing target hooks
only look at now_seg, for a few others it looks as if failing to do so
could have caused anomalies if sub-sections were used. In any event a
subsequent x86 change is going to require the sub-section to be properly
in place at the time the hook is invoked.
This primarily means for obj_elf_section() to pass the new subsection
into change_section(), for it to be set right away (ahead of invoking
the hook).
Also adjust obj_elf_ident() to invoke the hook after all section
changes. (Note that obj_elf_version(), which also changes sections and
then changes them back, has no hook invocation at all so far, so none
are added. Presumably there is a reason for this difference in
behavior.)
Jan Beulich [Fri, 15 Dec 2023 11:05:11 +0000 (12:05 +0100)]
x86: fold assembly dialect attributes
Now that ATTSyntax and ATTMnemonic aren't use in combination anymore,
fold them and IntelSyntax into a single, enum-like attribute. Note that
this shrinks i386_opcode_modifier back to 2 32-bit words (albeit that's
not for long, seeing in-flight additions for APX).
Jan Beulich [Fri, 15 Dec 2023 11:04:39 +0000 (12:04 +0100)]
x86: Intel syntax implies Intel mnemonics
As noted in the context of d53e6b98a259 ("x86/Intel: correct disassembly
of fsub*/fdiv*") there's no such thing as Intel syntax without Intel
mnemonics. Enforce this on the assembler side, and disentangle command
line option handling on the disassembler side accordingly.
As a result in the opcode table specifying ATTMnemonic|ATTSyntax becomes
redundant with just ATTMnemonic. Drop the now meaningless ATTSyntax and
remove the then no longer accessible templates.
Mike Frysinger [Fri, 15 Dec 2023 03:45:22 +0000 (22:45 -0500)]
sim: m32r: fix mloop.in variant stamp deps
The migration to local.mk in commit 0a129eb19a773d930d60b084209570f663db2053
accidentally listed the deps for all mloop steps as mloop.in instead of the
various variants that m32r uses.
Reported-by: Simon Marchi <simon.marchi@polymtl.ca>
Mike Frysinger [Fri, 15 Dec 2023 03:34:28 +0000 (22:34 -0500)]
sim: m32r: use @cpu@_fill_argbuf_tp to set trace & profile state
The mloop.in code does this, but these variants do not. Use it to
avoid unused function warnings. The fast_p logic in these files
also looks off, but that'll require a bit more work to fixup.
CC m32r/mloopx.o
m32r/mloopx.c:37:1: error: ‘m32rxf_fill_argbuf_tp’ defined but not used [-Werror=unused-function]
37 | m32rxf_fill_argbuf_tp (const SIM_CPU *cpu, ARGBUF *abuf,
| ^~~~~~~~~~~~~~~~~~~~~
CC m32r/mloop2.o
m32r/mloop2.c:37:1: error: ‘m32r2f_fill_argbuf_tp’ defined but not used [-Werror=unused-function]
37 | m32r2f_fill_argbuf_tp (const SIM_CPU *cpu, ARGBUF *abuf,
| ^~~~~~~~~~~~~~~~~~~~~
Reported-by: Simon Marchi <simon.marchi@polymtl.ca> Tested-By: Simon Marchi <simon.marchi@polymtl.ca>
Mike Frysinger [Fri, 15 Dec 2023 03:29:56 +0000 (22:29 -0500)]
sim: igen: do not reindent literal semantics output
When generating semantics.c from .igen source files, indenting the code
makes it more readable, but confuses compiler diagnostics. The latter
is a bit more important than the former, so bias towards that.
For example, with an introduced error, we can see w/gcc-13:
(before this change)
CC mn10300/semantics.o
../../../sim/mn10300/am33-2.igen: In function ‘semantic_dcpf_D1a’:
../../../sim/mn10300/am33-2.igen:11:5: error: ‘srcreg’ undeclared (first use in this function)
11 | srcreg = translate_rreg (SD_, RN2);
| ^~~~~~
(with this change)
CC mn10300/semantics.o
../../../sim/mn10300/am33-2.igen: In function ‘semantic_dcpf_D1a’:
../../../sim/mn10300/am33-2.igen:11:3: error: ‘srcreg’ undeclared (first use in this function)
11 | srcreg = translate_rreg (SD_, RN2);
| ^~~~~~
Alan Modra [Thu, 14 Dec 2023 23:34:48 +0000 (10:04 +1030)]
Re: readelf..debug-dump=loc displays bogus base addresses
Commit b05efa39b479 removed checks I added in commit f22f27f46c75 to
prevent segfaults when debug_info_p is NULL, which can be the case
with fuzzed objects. Restore those checks. Also, for dwo look at
rnglists_dwo rather than rnglists.
Andrew Burgess [Thu, 14 Dec 2023 11:54:13 +0000 (11:54 +0000)]
gdb/options: fix copy&paste error in string_option_def
Spotted what appears to be a copy&paste error in string_option_def,
the code for string handling writes the address fetching callback
function into the option_def::var_address::enumeration location,
rather than option_def::var_address::string.
Of course, this works just fine as option_def::var_address is a union,
and all of its members are function pointers, so they're going to be
the same size on every target GDB cares about.
But it doesn't hurt to be correct, so fixed in this commit.
There should be no user visible changes after this commit.
follow the same pattern, just with different registers.
The other test, arm-pseudo-unwind-legacy, tests the special case where
the unwind information contains an entry for a register considered a
pseudo-register by GDB.
Change-Id: Ic29ac040c5eb087b4a0d79f9d02f65b7979df30f Reviewed-By: John Baldwin <jhb@FreeBSD.org> Reviewed-by: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com> (aarch64/arm) Tested-By: Luis Machado <luis.machado@arm.com> (aarch64/arm)
Simon Marchi [Fri, 1 Dec 2023 16:27:34 +0000 (11:27 -0500)]
gdb: migrate aarch64 to new gdbarch_pseudo_register_write
Make aarch64 use the new gdbarch_pseudo_register_write. This fixes
writing pseudo registers to non-current frames on this architecture.
Change-Id: Ic012a0b95ae728d45a7121f77a79d604c23a849e Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
Simon Marchi [Fri, 1 Dec 2023 16:27:33 +0000 (11:27 -0500)]
gdb: add missing raw register read in aarch64_sme_pseudo_register_write
It seems like the intention here is to read the contents of the ZA
register and only write part of it. However, there's no actual read of
the ZA register, so it looks like we'll write uninitialized bytes to the
target, for the portion of the raw register where we don't write the
pseudo register. Add a call to raw_read to fix this.
I don't know how to test this though.
Change-Id: I7548240bd4324f6a3b729a1ebf7502fae5a46e9e Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-by: Luis Machado <luis.machado@arm.com>
Simon Marchi [Fri, 1 Dec 2023 16:27:32 +0000 (11:27 -0500)]
gdb: make aarch64_za_offsets_from_regnum return za_offsets
This is not necessary, but it seems more natural to me to make
aarch64_za_offsets_from_regnum return a za_offsets object, rather than
fill an instance passed by parameter.
Change-Id: I40a185f055727da887ce7774be193eef1f4b9147 Approved-by: Luis Machado <luis.machado@arm.com> Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Simon Marchi [Fri, 1 Dec 2023 16:27:30 +0000 (11:27 -0500)]
gdb: add gdbarch_pseudo_register_write that takes a frame
Add a new variant of gdbarch_pseudo_register_write that takes a
frame_info in order to write raw registers. Use this new method when
available:
- in put_frame_register, when trying to write a pseudo register to a given frame
- in regcache::cooked_write
No implementation is migrated to use this new method (that will come in
subsequent patches), so no behavior change is expected here.
The objective is to fix writing pseudo registers to non-current
frames. See previous commit "gdb: read pseudo register through
frame" for a more detailed explanation.
Change-Id: Ie7fe364a15a4d86c2ecb09de2b4baa08c45555ac Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Simon Marchi [Fri, 1 Dec 2023 16:27:29 +0000 (11:27 -0500)]
gdb: rename gdbarch_pseudo_register_write to gdbarch_deprecated_pseudo_register_write
The next patch introduces a new variant of gdbarch_pseudo_register_write
that takes a frame instead of a regcache for implementations to write
raw registers. Rename to old one to make it clear it's deprecated.
Change-Id: If8872c89c6f8a1edfcab983eb064248fd5ff3115 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Simon Marchi [Fri, 1 Dec 2023 16:27:27 +0000 (11:27 -0500)]
gdb: read pseudo register through frame
Change gdbarch_pseudo_register_read_value to take a frame instead of a
regcache. The frame (and formerly the regcache) is used to read raw
registers needed to make up the pseudo register value. The problem with
using the regcache is that it always provides raw register values for
the current frame (frame 0).
Let's say the user wants to read the ebx register on amd64. ebx is a pseudo
register, obtained by reading the bottom half (bottom 4 bytes) of the
rbx register, which is a raw register. If the currently selected frame
is frame 0, it works fine:
But if the user is looking at another frame, and the raw register behind
the pseudo register has been saved at some point in the call stack, then
we get a wrong answer:
(gdb) frame 1
#1 0x000055555555517d in caller () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:56
56 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S
(gdb) p/x $ebx
$3 = 0x24252627
(gdb) p/x $rbx
$4 = 0x1011121314151617
Here, the value of ebx was computed using the value of rbx in frame 0
(through the regcache), it should have been computed using the value of
rbx in frame 1.
In other to make this work properly, make the following changes:
- Make dwarf2_frame_prev_register return nullptr if it doesn't know how
to unwind a register and that register is a pseudo register.
Previously, it returned `frame_unwind_got_register`, meaning, in our
example, "the value of ebx in frame 1 is the same as the value of ebx
in frame 0", which is obviously false. Return nullptr as a way to
say "I don't know".
- In frame_unwind_register_value, when prev_register (for instance
dwarf2_frame_prev_register) returns nullptr, and we are trying to
read a pseudo register, try to get the register value through
gdbarch_pseudo_register_read_value or gdbarch_pseudo_register_read.
If using gdbarch_pseudo_register_read, the behavior is known to be
broken. Implementations should be migrated to use
gdbarch_pseudo_register_read_value to fix that.
- Change gdbarch_pseudo_register_read_value to take a frame_info
instead of a regcache, update implementations (aarch64, amd64, i386).
In i386-tdep.c, I made a copy of i386_mmx_regnum_to_fp_regnum that
uses a frame instead of a regcache. The version using the regcache
is still used by i386_pseudo_register_write. It will get removed in
a subsequent patch.
- Add some helpers in value.{c,h} to implement the common cases of
pseudo registers: taking part of a raw register and concatenating
multiple raw registers.
- Update readable_regcache::{cooked_read,cooked_read_value} to pass the
current frame to gdbarch_pseudo_register_read_value. Passing the
current frame will give the same behavior as before: for frame 0, raw
registers will be read from the current thread's regcache.
Notes:
- I do not plan on changing gdbarch_pseudo_register_read to receive a
frame instead of a regcache. That method is considered deprecated.
Instead, we should be working on migrating implementations to use
gdbarch_pseudo_register_read_value instead.
- In frame_unwind_register_value, we still ask the unwinder to try to
unwind pseudo register values. It's apparently possible for the
debug info to provide information about [1] pseudo registers, so we
want to try that first, before falling back to computing them
ourselves.
Simon Marchi [Fri, 1 Dec 2023 16:27:26 +0000 (11:27 -0500)]
gdb: add value::allocate_register
Add value::allocate_register, to facilitate allocating a value
representing a register in a given frame (or rather, in the given
frame's previous frame). It will be used in a subsequent patch. I
changed one relatively obvious spot that could use it, to at least
exercise the code path.
Change-Id: Icd4960f5e471a74b657bb3596c88d89679ef3772 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Simon Marchi [Fri, 1 Dec 2023 16:27:22 +0000 (11:27 -0500)]
gdb: remove frame_register
I was going to change frame_register to take the "next frame", but I
realized that doing so would make it a useless wrapper around
frame_register_unwind. So, just remove frame_register and replace uses
with frame_register_unwind.
Change-Id: I185868bc69f8e098124775d0550d069220a4678a Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Simon Marchi [Fri, 1 Dec 2023 16:27:21 +0000 (11:27 -0500)]
gdb: change value_of_register and value_of_register_lazy to take the next frame
Some functions related to the handling of registers in frames accept
"this frame", for which we want to read or write the register values,
while other functions accept "the next frame", which is the frame next
to that. The later is needed because we sometimes need to read register
values for a frame that does not exist yet (usually when trying to
unwind that frame-to-be).
value_of_register and value_of_register_lazy both take "this frame",
even if what they ultimately want internally is "the next frame". This
is annoying if you are in a spot that currently has "the next frame" and
need to call one of these functions (which happens later in this
series). You need to get the previous frame only for those functions to
get the next frame again. This is more manipulations, more chances of
mistake.
I propose to change these functions (and a few more functions in the
subsequent patches) to operate on "the next frame". Things become a bit
less awkward when all these functions agree on which frame they take.
So, in this patch, change value_of_register_lazy and value_of_register
to take "the next frame" instead of "this frame". This adds a lot of
get_next_frame_sentinel_okay, but if we convert the user registers API
to also use "the next frame" instead of "this frame", it will get simple
again.
Change-Id: Iaa24815e648fbe5ae3c214c738758890a91819cd Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Simon Marchi [Fri, 1 Dec 2023 16:27:19 +0000 (11:27 -0500)]
gdb: fix bugs in {get,put}_frame_register_bytes
I found this only by inspection: the myaddr pointer in
{get,put}_frame_register_bytes is reset to `buffer.data ()` at each
iteration. This means that we will always use the bytes at the
beginning of `buffer` to read or write to the registers, instead of
progressing in `buffer`.
Fix this by re-writing the functions to chip away the beginning of the
buffer array_view as we progress in reading or writing the data.
These bugs was introduced almost 3 years ago [1], and yet nobody
complained. I'm wondering which architecture relies on that register
"overflow" behavior (reading or writing multiple consecutive registers
with one {get,put}_frame_register_bytes calls), and in which situation.
I find these functions a bit dangerous, if a caller mis-calculates
things, it could end up silently reading or writing to the next
register, even if it's not the intent.
If I could change it, I would prefer to have functions specifically made
for that ({get,put}_frame_register_bytes_consecutive or something like
that) and make {get,put}_frame_register_bytes only able to write within
a single register (which I presume represents most of the use cases of
the current {get,put}_frame_register_bytes). If a caller mis-calculates
things and an overflow occurs while calling
{get,put}_frame_register_bytes, it would hit an assert. The problem is
knowing which callers rely on the overflow behavior and which don't.
Simon Marchi [Fri, 1 Dec 2023 16:27:18 +0000 (11:27 -0500)]
gdb: change regcache interface to use array_view
Change most of regcache (and base classes) to use array_view when
possible, instead of raw pointers. By propagating the use of array_view
further, it enables having some runtime checks to make sure the what we
read from or write to regcaches has the expected length (such as the one
in the `copy(array_view, array_view)` function. It also integrates well
when connecting with other APIs already using gdb::array_view.
Add some overloads of the methods using raw pointers to avoid having to
change all call sites at once (which is both a lot of work and risky).
I tried to do this change in small increments, but since many of these
functions use each other, it ended up simpler to do it in one shot than
having a lot of intermediary / transient changes.
This change extends into gdbserver as well, because there is some part
of the regcache interface that is shared.
Changing the reg_buffer_common interface to use array_view caused some
build failures in nat/aarch64-scalable-linux-ptrace.c. That file
currently "takes advantage" of the fact that
reg_buffer_common::{raw_supply,raw_collect} operates on `void *`, which
IMO is dangerous. It uses raw_supply/raw_collect directly on
uint64_t's, which I guess is fine because it is expected that native
code will have the same endianness as the debugged process. To
accomodate that, add some overloads of raw_collect and raw_supply that
work on uint64_t.
This file also uses raw_collect and raw_supply on `char` pointers.
Change it to use `gdb_byte` pointers instead. Add overloads of
raw_collect and raw_supply that work on `gdb_byte *` and make an
array_view on the fly using the register's size. Those call sites could
be converted to use array_view with not much work, in which case these
overloads could be removed, but I didn't want to do it in this patch, to
avoid starting to dig in arch-specific code.
During development, I inadvertently changed reg_buffer::raw_compare's
behavior to not accept an offset equal to the register size. This
behavior (effectively comparing 0 bytes, returning true) change was
caught by the AArch64 SME core tests. Add a selftest to make sure that
this raw_compare behavior is preserved in the future.
Change-Id: I9005f04114543ddff738949e12d85a31855304c2 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Simon Marchi [Fri, 1 Dec 2023 16:27:17 +0000 (11:27 -0500)]
gdb: simplify conditions in regcache::{read,write,raw_collect,raw_supply}_part
Make a few simplifications in these functions.
1. When checking if we need to do nothing, if the length is 0, we don't
need to do anything, regardless of the value of offset. Remove the
offset check.
2. When check if transferring the whole register, if the length is equal
to the register size, then we transfer the whole register, no need to
check the offset. Remove the offset check.
3. In the gdb_asserts, it is unnecessary to check for:
offset <= reg_size
given that right after we check for:
len >= 0 && offset + len <= reg_size
If `offset + len` is <= reg_size and len is >= 0, then necessarily
offset is <= reg_size. Remove the `offset <= reg_size` check.
Change-Id: I30a73acdc7bf432c45a07f5f177224d1cdc298e8 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Simon Marchi [Fri, 1 Dec 2023 16:27:16 +0000 (11:27 -0500)]
gdb: make store_integer take an array_view
Change store_integer, store_signed_integer and store_unsigned_integer to
accept an array_view. Add some backwards compatibility overloads to
avoid changing all callers at once.
Change-Id: Ibb1381228ab1cb65fc7e2e4b92cf9ab1047cdc03 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Simon Marchi [Fri, 1 Dec 2023 16:27:15 +0000 (11:27 -0500)]
gdb: use reg_buffer_common throughout gdbsupport/common-regcache.h
Right now, gdbsupport/common-regcache.h contains two abstractons for a
regcache. An opaque type `regcache` (gdb and gdbserver both have their
own regcache that is the concrete version of this) and an abstract base
class `reg_buffer_common`, that is the base of regcaches on both sides.
These abstractions allow code to be written for both gdb and gdbserver,
for instance in the gdb/arch sub-directory.
However, having two
different abstractions is impractical. If some common code has a regcache,
and wants to use an operation defined on reg_buffer_common, it can't.
It would be better to have just one. Change all instances of `regcache
*` in gdbsupport/common-regcache.h to be `reg_buffer_common *`, then fix
fallouts.
Implementations in gdb and gdbserver now need to down-cast (using
gdb::checked_static_cast) from reg_buffer_common to their concrete
regcache type. Some of them could be avoided by changing free functions
(like regcache_register_size) to be virtual methods on
reg_buffer_common. I tried it, it seems to work, but I did not include
it in this series to avoid adding unnecessary changes.
Change-Id: Ia5503adb6b5509a0f4604bd2a68b4642cc5283fd Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Simon Marchi [Fri, 1 Dec 2023 16:27:14 +0000 (11:27 -0500)]
gdb: don't handle i386 k registers as pseudo registers
I think that i386 k registers are raw registers, and therefore shouldn't
be handled in the various functions handling pseudo registers.
What tipped me off is the code in i386_pseudo_register_read_into_value:
else if (i386_k_regnum_p (gdbarch, regnum))
{
regnum -= tdep->k0_regnum;
/* Extract (always little endian). */
status = regcache->raw_read (tdep->k0_regnum + regnum, raw_buf);
We take regnum (the pseudo register number we want to read), subtract
k0_regnum, add k0_regnum, and pass the result to raw_read. So we would
end up calling raw_read with the same regnum as the function received
which is supposedly a pseudo register number.
Other hints are:
- The command `maint print raw-registers` shows the k registers.
- Printing $k0 doesn't cause i386_pseudo_register_read_into_value to be
called.
- There's code in i387-tdep.c to save/restore the k registers.
Hannes Domani [Sun, 14 Nov 2021 15:19:31 +0000 (16:19 +0100)]
Allow calling of variadic C++ functions
Currently, it's not possible to call a variadic C++ function:
```
(gdb) print sum_vararg_int(1, 10)
Cannot resolve function sum_vararg_int to any overloaded instance
(gdb) print sum_vararg_int(2, 20, 30)
Cannot resolve function sum_vararg_int to any overloaded instance
```
It's because all additional arguments get the TOO_FEW_PARAMS_BADNESS
rank by rank_function, which disqualifies the function.
To fix this, I've created the new VARARG_BADNESS rank, which is
used only for additional arguments of variadic functions, allowing
them to be called:
```
(gdb) print sum_vararg_int(1, 10)
$1 = 10
(gdb) print sum_vararg_int(2, 20, 30)
$2 = 50
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28589 Approved-By: Tom Tromey <tom@tromey.com>
Jin Ma [Fri, 17 Nov 2023 06:20:53 +0000 (14:20 +0800)]
RISC-V: Fix the wrong encoding and operand of the XTheadFmv extension.
The description of instructions 'th.fmv.hw.x' and 'th.fmv.x.hw' of the
XTheadFmv extension in T-Head specific is incorrect, and it also has
some impact on the implementation of the binutils, so this patch
corrects this.
For details see:
https://github.com/T-head-Semi/thead-extension-spec/pull/34
Magne Hov [Wed, 13 Dec 2023 11:45:49 +0000 (11:45 +0000)]
[gdb/tui] add SingleKey bindings for reverse execution commands
The bindings for the reverse execution commands are the same letters
as the forward execution command, but with the opposite case. This way
one can simply hold down the Shift modifier key or tap the Caps Lock key
to change the direction of execution.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Wed, 6 Dec 2023 15:57:11 +0000 (16:57 +0100)]
gdb/python: avoid use of _PyOS_ReadlineTState
In python/py-gdb-readline.c we make use of _PyOS_ReadlineTState,
however, this variable is no longer public in Python 3.13, and so GDB
no longer builds.
We are making use of _PyOS_ReadlineTState in order to re-acquire the
Python Global Interpreter Lock (GIL). The _PyOS_ReadlineTState
variable is set in Python's outer readline code prior to calling the
user (GDB) supplied readline callback function, which for us is
gdbpy_readline_wrapper. The gdbpy_readline_wrapper function is called
without the GIL held.
Instead of using _PyOS_ReadlineTState, I propose that we switch to
calling PyGILState_Ensure() and PyGILState_Release(). These functions
will acquire the GIL based on the current thread. I think this should
be sufficient; I can't imagine why we'd be running
gdbpy_readline_wrapper on one thread on behalf of a different Python
thread.... that would be unexpected I think.
Andrew Burgess [Sat, 2 Dec 2023 11:36:43 +0000 (11:36 +0000)]
gdb: improve error reporting for 'save gdb-index'
While making recent changes to 'save gdb-index' command I triggered
some errors -- of the kind a user might be expected to trigger if they
do something wrong -- and I didn't find GDB's output as helpful as it
might be.
For example:
$ gdb -q /tmp/hello.x
...
(gdb) save gdb-index /non_existing_dir
Error while writing index for `/tmp/hello': mkstemp: No such file or directory.
That the error message mentions '/tmp/hello', which does exist, but
doesn't mention '/non_existing_dir', which doesn't is, I think,
confusing.
Also, I find the 'mkstemp' in the error message confusing for a user
facing error. A user might not know what mkstemp means, and even if
they do, that it appears in the error message is an internal GDB
detail. The user doesn't care what function failed, but wants to know
what was wrong with their input, and what they should do to fix
things.
Similarly, for a directory that does exist, but can't be written to:
(gdb) save gdb-index /no_access_dir
Error while writing index for `/tmp/hello': mkstemp: Permission denied.
In this case, the 'Permission denied' might make the user thing there
is a permissions issue with '/tmp/hello', which is not the case.
After this patch, the new errors are:
(gdb) save gdb-index /non_existing_dir
Error while writing index for `/tmp/hello': `/non_existing_dir': No such file or directory.
and:
(gdb) save gdb-index /no_access_dir
Error while writing index for `/tmp/hello': `/no_access_dir': Permission denied.
we also have:
(gdb) save gdb-index /tmp/not_a_directory
Error while writing index for `/tmp/hello': `/tmp/not_a_directory': Is not a directory.
I think these do a better job of guiding the user towards fixing the
problem.
I've added a new test that exercises all of these cases, and also
checks the case where a user tries to use an executable that already
contains an index in order to generate an index. As part of the new
test I've factored out some code from ensure_gdb_index (lib/gdb.exp)
into a new proc (get_index_type), which I've then used in the new
test. I've confirmed that all the tests that use ensure_gdb_index
still pass.
During review it was pointed out that the testsuite proc
have_index (lib/gdb.exp) is similar to the new get_index_type proc, so
I've rewritten have_index to also use get_index_type, I've confirmed
that all the tests that use have_index still pass.
Nothing that worked correctly before this patch should give an error
after this patch; I've only changed the output when the user was going
to get an error anyway.
Reviewed-By: Tom de Vries <tdevries@suse.de> Reviewed-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
Stefano Moioli [Wed, 6 Dec 2023 00:42:19 +0000 (01:42 +0100)]
gdbserver/win32: fix crash on detach
this patch fixes a crash in gdbserver whenever a process is detached.
the crash is caused by `detach` calling `remove_process` before `win32_clear_inferiors`
error message:
Detaching from process 184
../../gdbserver/inferiors.cc:160: A problem internal to GDBserver has been detec
ted.
remove_process: Assertion `find_thread_process (process) == NULL' failed.
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Hannes Domani [Tue, 12 Dec 2023 14:57:14 +0000 (15:57 +0100)]
Fix gdb.FinishBreakpoint when returning to an inlined function
Currently, when creating a gdb.FinishBreakpoint in a function
called from an inline frame, it will never be hit:
```
(gdb) py fb=gdb.FinishBreakpoint()
Temporary breakpoint 1 at 0x13f1917b4: file C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c, line 47.
(gdb) c
Continuing.
Thread-specific breakpoint 1 deleted - thread 1 no longer in the thread list.
[Inferior 1 (process 1208) exited normally]
```
The reason is that the frame_id of a breakpoint has to be the
ID of a real frame, ignoring any inline frames.
With this fixed, it's working correctly:
```
(gdb) py fb=gdb.FinishBreakpoint()
Temporary breakpoint 1 at 0x13f5617b4: file C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c, line 47.
(gdb) c
Continuing.
projects / thirdparty / binutils-gdb.git / log
