| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Consider the test-case test.c, compiled without debug info:
...
void
foo (const char *s)
{
}
int
main (void)
{
foo ("foo");
return 0;
}
...
Disassembly of foo:
...
0000000000400564 <foo>:
400564: d10043ff sub sp, sp, #0x10
400568: f90007e0 str x0, [sp, #8]
40056c: d503201f nop
400570: 910043ff add sp, sp, #0x10
400574: d65f03c0 ret
...
Now, let's do "info frame" at each insn in foo, as well as printing $sp
and $x29 (and strip the output of info frame to the first line, for brevity):
...
$ gdb -q a.out
Reading symbols from a.out...
(gdb) b *foo
Breakpoint 1 at 0x400564
(gdb) r
Starting program: a.out
Breakpoint 1, 0x0000000000400564 in foo ()
(gdb) display /x $sp
1: /x $sp = 0xfffffffff3a0
(gdb) display /x $x29
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x0000000000400568 in foo ()
1: /x $sp = 0xfffffffff390
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x000000000040056c in foo ()
1: /x $sp = 0xfffffffff390
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x0000000000400570 in foo ()
1: /x $sp = 0xfffffffff390
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x0000000000400574 in foo ()
1: /x $sp = 0xfffffffff3a0
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3b0:
pc = 0x400574 in foo; saved pc = 0x40058c
(gdb) si
0x000000000040058c in main ()
1: /x $sp = 0xfffffffff3a0
2: /x $x29 = 0xfffffffff3a0
...
The "frame at" bit lists 0xfffffffff3a0 except at the last insn, where it
lists 0xfffffffff3b0.
The frame address is calculated here in aarch64_make_prologue_cache_1:
...
unwound_fp = get_frame_register_unsigned (this_frame, cache->framereg);
if (unwound_fp == 0)
return;
cache->prev_sp = unwound_fp + cache->framesize;
...
For insns after the prologue, we have cache->framereg == sp and
cache->framesize == 16, so unwound_fp + cache->framesize gives the wrong
answer once sp has been restored to entry value by the before-last insn.
Fix this by detecting the situation that the sp has been restored.
This fixes PRs tdep/30010 and tdep/30011.
This also fixes the aarch64 FAILs in gdb.reverse/solib-precsave.exp and
gdb.reverse/solib-reverse.exp I reported in PR gdb/PR29721.
Tested on aarch64-linux.
PR tdep/30010
PR tdep/30011
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30010
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30011
|
|
This helps resolve some cyclic include problem later in the series.
The only language-related thing frame.h needs is enum language, and that
is in defs.h.
Doing so reveals that a bunch of files were relying on frame.h to
include language.h, so fix the fallouts here and there.
Change-Id: I178a7efec1953c2d088adb58483bade1f349b705
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
In aarch64-tdep.c we find these register aliases:
...
{
/* 64-bit register names. */
{"fp", AARCH64_FP_REGNUM},
{"lr", AARCH64_LR_REGNUM},
{"sp", AARCH64_SP_REGNUM},
...
The sp alias is superfluous, because the canonical name of x31 is already sp.
The fp alias is superfluous, because it's already taken by the default meaning
of fp, assigned here in _initialize_frame_reg:
...
user_reg_add_builtin ("fp", value_of_builtin_frame_fp_reg, NULL);
...
Fix this by removing the fp and sp aliases.
While we're at it, add an x31 alias for sp.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested on aarch64-linux.
PR tdep/30012
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30012
|
|
It's currently not clear how the ownership of gdbarch_tdep objects
works. In fact, nothing ever takes ownership of it. This is mostly
fine because we never free gdbarch objects, and thus we never free
gdbarch_tdep objects. There is an exception to that however: when
initialization fails, we do free the gdbarch object that is not going to
be used, and we free the tdep too. Currently, i386 and s390 do it.
To make things clearer, change gdbarch_alloc so that it takes ownership
of the tdep. The tdep is thus automatically freed if the gdbarch is
freed.
Change all gdbarch initialization functions to pass a new gdbarch_tdep
object to gdbarch_alloc and then retrieve a non-owning reference from
the gdbarch object.
Before this patch, the xtensa architecture had a single global instance
of xtensa_gdbarch_tdep. Since we need to pass a dynamically allocated
gdbarch_tdep_base instance to gdbarch_alloc, remove this global
instance, and dynamically allocate one as needed, like we do for all
other architectures. Make the `rmap` array externally visible and
rename it to the less collision-prone `xtensa_rmap` name.
Change-Id: Id3d70493ef80ce4bdff701c57636f4c79ed8aea2
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This patch updates the gdbarch_return_value_as_value implementations
to work correctly with variably-sized return types.
|
|
This converts a few selected architectures to use
gdbarch_return_value_as_value rather than gdbarch_return_value. The
architectures are just the ones that I am able to test. This patch
should not introduce any behavior changes.
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
With the AArch64 Scalable Matrix Extension we have a new TPIDR2 register, and
it will be added to the existing NT_ARM_TLS register set. Kernel patches are
being reviewed here:
https://lore.kernel.org/linux-arm-kernel/20220818170111.351889-1-broonie@kernel.org/
From GDB's perspective, we handle it in a similar way to the existing TPIDR
register. But we need to consider cases of systems that only have TPIDR and
systems that have both TPIDR and TPIDR2.
With that in mind, the following patch adds the required code to support
TPIDR2 and turns the org.gnu.gdb.aarch64.tls feature into a
dynamically-generated target description as opposed to a static target
description containing only TPIDR.
That means we can remove the gdb/features/aarch64-tls.xml file and replace the
existing gdb/features/aarch64-tls.c auto-generated file with a new file that
dynamically generates the target description containing either TPIDR alone or
TPIDR and TPIDR2.
In the future, when *BSD's start to support this register, they can just
enable it as is being done for the AArch64 Linux target.
The core file read/write code has been updated to support TPIDR2 as well.
On GDBserver's side, there is a small change to the find_regno function to
expose a non-throwing version of it.
It always seemed strange to me how find_regno causes the whole operation to
abort if it doesn't find a particular register name. The patch moves code
from find_regno into find_regno_no_throw and makes find_regno call
find_regno_no_throw instead.
This allows us to do register name lookups to find a particular register
number without risking erroring out if nothing is found.
The patch also adjusts the feature detection code for aarch64-fbsd, since
the infrastructure is shared amongst all aarch64 targets. I haven't added
code to support TPIDR2 in aarch64-fbsd though, as I'm not sure when/if
that will happen.
|
|
The missing newline causes testsuite issues because the gdb prompt gets output
to an unexpected location.
|
|
PR tdep/28796
As reported, we are using some memory read routines that don't handle read
errors gracefully. Convert those to use the safe_* versions if available.
This allows the code to handle those read errors in a more sensible way.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28796
|
|
Currently, every internal_error call must be passed __FILE__/__LINE__
explicitly, like:
internal_error (__FILE__, __LINE__, "foo %d", var);
The need to pass in explicit __FILE__/__LINE__ is there probably
because the function predates widespread and portable variadic macros
availability. We can use variadic macros nowadays, and in fact, we
already use them in several places, including the related
gdb_assert_not_reached.
So this patch renames the internal_error function to something else,
and then reimplements internal_error as a variadic macro that expands
__FILE__/__LINE__ itself.
The result is that we now should call internal_error like so:
internal_error ("foo %d", var);
Likewise for internal_warning.
The patch adjusts all calls sites. 99% of the adjustments were done
with a perl/sed script.
The non-mechanical changes are in gdbsupport/errors.h,
gdbsupport/gdb_assert.h, and gdb/gdbarch.py.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
|
|
This changes GDB to use frame_info_ptr instead of frame_info *
The substitution was done with multiple sequential `sed` commands:
sed 's/^struct frame_info;/class frame_info_ptr;/'
sed 's/struct frame_info \*/frame_info_ptr /g' - which left some
issues in a few files, that were manually fixed.
sed 's/\<frame_info \*/frame_info_ptr /g'
sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace
problems.
The changed files were then manually checked and some 'sed' changes
undone, some constructors and some gets were added, according to what
made sense, and what Tromey originally did
Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>
|
|
registers
The aarch64 port handles W registers as aliases of X registers. This is
incorrect because X registers are 64-bit and W registers are 32-bit.
This patch teaches GDB how to handle W registers as pseudo-registers of
32-bit, the bottom half of the X registers.
Testcase included.
|
|
additional registers
When using AArch64 GDB with the QEMU debugging stub (in user mode), we get
additional system registers that GDB doesn't particularly care about, so
it doesn't number those explicitly.
But given the pseudo-register numbers are above the number of real registers,
we need to setup/account for the real registers first before going ahead and
numbering the pseudo-registers. This has to happen at the end of
aarch64_gdbarch_init, after the call to tdesc_use_registers, as that
updates the total number of real registers.
This is in preparation to supporting pointer authentication for bare metal
aarch64 (QEMU).
|
|
Remove the macro, replace all uses with calls to type::length.
Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
|
|
Remove the macro, replace all uses by calls to type::target_type.
Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
|
|
As reported by Tom in https://sourceware.org/pipermail/gdb-patches/2022-August/191357.html,
the aarch64 prologue analyzer considers the adrp instruction in the
gdb.dwarf2/dw2-dir-file-name.exp testcase to be part of a prologue.
The function has no prologue though, and it only loads the volatile variable
from memory. GDB should not skip any instructions in this case.
Doing some archaeology, it seems handling for adr/adrp in prologues was
included with the original aarch64 port. It might've been an oversight.
In the particular case of gdb.dwarf2/dw2-dir-file-name.exp, the analyzer skips
a couple instructions and leaves us in a nice spot where the address to the
variable "v" is already in w0. But no prologues exists.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29481
|
|
When the inferior program changes the SVE length, GDB can stop tracking
some registers as it obtains the new gdbarch that corresponds to the
updated length:
Breakpoint 1, do_sve_ioctl_test () at sve-ioctls.c:44
44 res = prctl(PR_SVE_SET_VL, i, 0, 0, 0, 0);
(gdb) print i
$2 = 32
(gdb) info registers
⋮
[ snip registers x0 to x30 ]
⋮
sp 0xffffffffeff0 0xffffffffeff0
pc 0xaaaaaaaaa8ac 0xaaaaaaaaa8ac <do_sve_ioctl_test+112>
cpsr 0x60000000 [ EL=0 BTYPE=0 C Z ]
fpsr 0x0 0
fpcr 0x0 0
vg 0x8 8
tpidr 0xfffff7fcb320 0xfffff7fcb320
(gdb) next
45 if (res < 0) {
(gdb) info registers
⋮
[ snip registers x0 to x30 ]
⋮
sp 0xffffffffeff0 0xffffffffeff0
pc 0xaaaaaaaaa8cc 0xaaaaaaaaa8cc <do_sve_ioctl_test+144>
cpsr 0x200000 [ EL=0 BTYPE=0 SS ]
fpsr 0x0 0
fpcr 0x0 0
vg 0x4 4
(gdb)
Notice that register tpidr disappeared when vg (which holds the vector
length) changed from 8 to 4. The tpidr register is provided by the
org.gnu.gdb.aarch64.tls feature.
This happens because the code that searches for a new gdbarch to match the
new vector length in aarch64_linux_nat_target::thread_architecture doesn't
take into account the features present in the target description associated
with the previous gdbarch. This patch makes it do that.
Since the id member of struct gdbarch_info is now unused, it's removed.
|
|
On aarch64, I run into:
...
FAIL: gdb.base/large-frame.exp: optimize=-O0: backtrace
...
The problem is that the architecture-specific prologue analyzer fails to
handle the first two insns in the prologue properly:
...
0000000000400610 <func>:
400610: d2880210 mov x16, #0x4010
400614: cb3063ff sub sp, sp, x16
400618: a9007bfd stp x29, x30, [sp]
40061c: 910003fd mov x29, sp
400620: 910043a0 add x0, x29, #0x10
400624: 97fffff0 bl 4005e4 <blah>
...
so we get:
...
$ gdb -q -batch ./outputs/gdb.base/large-frame/large-frame-O0 -ex "b func"
Breakpoint 1 at 0x400614
...
Fix this by:
- fixing the support for the first insn to extract the immediate operand, and
- adding support for the second insn,
such that we have:
...
Breakpoint 1 at 0x400624
...
Note that we're overshooting by one insn (0x400620 is the first insn after the
prologue), but that's a pre-existing problem.
Tested on aarch64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29408
|
|
I built GDB for all targets on a x86-64/GNU-Linux system, and
then (accidentally) passed GDB a RISC-V binary, and asked GDB to "run"
the binary on the native target. I got this error:
(gdb) show architecture
The target architecture is set to "auto" (currently "i386").
(gdb) file /tmp/hello.rv32.exe
Reading symbols from /tmp/hello.rv32.exe...
(gdb) show architecture
The target architecture is set to "auto" (currently "riscv:rv32").
(gdb) run
Starting program: /tmp/hello.rv32.exe
../../src/gdb/i387-tdep.c:596: internal-error: i387_supply_fxsave: Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed.
What's going on here is this; initially the architecture is i386, this
is based on the default architecture, which is set based on the native
target. After loading the RISC-V executable the architecture of the
current inferior is updated based on the architecture of the
executable.
When we "run", GDB does a fork & exec, with the inferior being
controlled through ptrace. GDB sees an initial stop from the inferior
as soon as the inferior comes to life. In response to this stop GDB
ends up calling save_stop_reason (linux-nat.c), which ends up trying
to read register from the inferior, to do this we end up calling
target_ops::fetch_registers, which, for the x86-64 native target,
calls amd64_linux_nat_target::fetch_registers.
After this I eventually end up in i387_supply_fxsave, different x86
based targets will end in different functions to fetch registers, but
it doesn't really matter which function we end up in, the problem is
this line, which is repeated in many places:
i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch);
The problem here is that the ARCH in this line comes from the current
inferior, which, as we discussed above, will be a RISC-V gdbarch, the
tdep field will actually be of type riscv_gdbarch_tdep, not
i386_gdbarch_tdep. After this cast we are relying on undefined
behaviour, in my case I happen to trigger an assert, but this might
not always be the case.
The thing I tried that exposed this problem was of course, trying to
start an executable of the wrong architecture on a native target. I
don't think that the correct solution for this problem is to detect,
at the point of cast, that the gdbarch_tdep object is of the wrong
type, but, I did wonder, is there a way that we could protect
ourselves from incorrectly casting the gdbarch_tdep object?
I think that there is something we can do here, and this commit is the
first step in that direction, though no actual check is added by this
commit.
This commit can be split into two parts:
(1) In gdbarch.h and arch-utils.c. In these files I have modified
gdbarch_tdep (the function) so that it now takes a template argument,
like this:
template<typename TDepType>
static inline TDepType *
gdbarch_tdep (struct gdbarch *gdbarch)
{
struct gdbarch_tdep *tdep = gdbarch_tdep_1 (gdbarch);
return static_cast<TDepType *> (tdep);
}
After this change we are no better protected, but the cast is now
done within the gdbarch_tdep function rather than at the call sites,
this leads to the second, much larger change in this commit,
(2) Everywhere gdbarch_tdep is called, we make changes like this:
- i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch);
+ i386_gdbarch_tdep *tdep = gdbarch_tdep<i386_gdbarch_tdep> (arch);
There should be no functional change after this commit.
In the next commit I will build on this change to add an assertion in
gdbarch_tdep that checks we are casting to the correct type.
|
|
"struct insn_decode_record_t" is defined in multiple .c files, causing
ODR warnings. This patch renames the types, and removes the use of
"typedef" here -- this is a C-ism that's no longer needed.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
|
|
This small patch adds support for TYPE_CODE_DECFLOAT in
aapcs_is_vfp_call_or_return_candidate_1 and pass_in_v_vfp_candidate,
so that GDB for AArch64 knows how to pass DFP parameters and how to
read DFP results when calling a function.
Tested on aarch64-linux-gnu, with a GCC with DFP support in the PATH,
all of GDB's DFP tests pass.
|
|
Replace the sve bool member of aarch64_features with a vq member that
holds the vector quotient. It is zero if SVE is not present.
Add std::hash<> specialization and operator== so that aarch64_features
can be used as a key with std::unordered_map<>.
Change the various functions that create or lookup aarch64 target
descriptions to accept a const aarch64_features object rather than a
growing number of arguments.
Replace the multi-dimension tdesc_aarch64_list arrays used to cache
target descriptions with unordered_maps indexed by aarch64_feature.
|
|
This will allow the unwind info to explicitly specify a different value
for the return address from the link register.
Such usage, although uncommon, is valid and useful for signal frames.
It is also supported by aadwarf64 from ARM (Note 9 in [1]).
Ref https://sourceware.org/pipermail/gdb/2022-May/050091.html
[1] https://github.com/ARM-software/abi-aa/blob/2022Q1/aadwarf64/aadwarf64.rst#dwarf-register-names
Signed-off-by: Luis Machado <luis.machado@arm.com>
|
|
The AARCH64_DWARF_PAUTH_DMASK and AARCH64_DWARF_PAUTH_CMASK DWARF registers
never made their way into the aadwarf64. The following patch removes these
constants and their use.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26295
|
|
The aadwarf64 [1] names this register RA_SIGN_STATE, so update the code to use
the same name.
[1] https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst
|
|
|
|
There's a set of 7 default register groups. If we don't add any
gdbarch specific register groups during gdbarch initialisation, then
when we iterate over the register groups using reggroup_next and
reggroup_prev we will make use of these 7 default groups. See the use
of default_groups in gdb/reggroups.c for details on this.
However, if the gdbarch adds its own groups during gdbarch
initialisation, then these groups will be used in preference to the
default groups.
A problem arises though if the particular architecture makes use of
the target description mechanism. If the default target
description(s) (i.e. those internal to GDB that are used when the user
doesn't provide their own) don't mention any additional register
groups then the default register groups will be used.
But if the target description does mention additional groups then the
default groups are not used, and instead, the groups from the target
description are used.
The problem with this is that what usually happens is that the target
description will mention additional groups, e.g. groups for special
registers. Most architectures that use target descriptions work
around this by adding all (or most) of the default register groups in
all cases. See i386_add_reggroups, aarch64_add_reggroups,
riscv_add_reggroups, xtensa_add_reggroups, and others.
In this patch, my suggestion is that we should just add the default
register groups for every architecture, always. This change is in
gdb/reggroups.c.
All the remaining changes are me updating the various architectures to
not add the default groups themselves.
So, where will this change be visible to the user? I think the
following commands will possibly change:
* info registers / info all-registers:
The user can provide a register group to these commands. For example,
on csky, we previously never added the 'vector' group. Now, as a
default group, this will be available, but (presumably) will not
contain any registers. I don't think this is necessarily a bad
thing, there's something to be said for having some consistent
defaults available. There are other architectures that didn't add
all 7 of the defaults, which will now have gained additional groups.
* maint print reggroups
This prints the set of all available groups. As a maintenance
command I'm less concerned with the output changing here.
Obviously, for the architectures that didn't previously add all the
defaults, this list just got bigger.
* maint print register-groups
This prints all the registers, and the groups they are in. If the
defaults were not previously being added then a register (obviously)
can't appear in one of the default groups. Now the groups are
available then registers might be in more groups than previously.
However, this is again a maintenance command, so I'm less concerned
about this changing.
|
|
Change gdbarch_register_reggroup_p to take a 'const struct reggroup *'
argument. This requires a change to the gdb/gdbarch-components.py
script, regeneration of gdbarch.{c,h}, and then updates to all the
architectures that implement this method.
There should be no user visible changes after this commit.
|
|
It is better to rename floatformats_ia64_quad to floatformats_ieee_quad
to reflect the reality, and then we can clean up the related code.
As Tom Tromey said [1]:
These files are maintained in gcc and then imported into the
binutils-gdb repository, so any changes to them will have to
be proposed there first.
the related changes have been merged into gcc master now [2], it is time
to do it for gdb.
[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186569.html
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b2dff6b2d9d6
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions. This is done under the name
"gdb_printf". Most of this patch was written by script.
|
|
The internal AdaCore testsuite has a test that checks that an
out-of-scope watchpoint is deleted. This fails on some aarch64
configurations, reporting an extra stop:
(gdb) continue
Continuing.
Thread 3 hit Watchpoint 2: result
Old value = 64
New value = 0
0x0000000040021648 in pck.get_val (seed=0, off_by_one=false) at [...]/pck.adb:13
13 end Get_Val;
I believe what is happening here is that the variable is stored at:
<efa> DW_AT_location : 2 byte block: 91 7c (DW_OP_fbreg: -4)
and the extra stop is reported just before a return, when the ldp
instruction is executed:
0x0000000040021644 <+204>: ldp x29, x30, [sp], #48
0x0000000040021648 <+208>: ret
This instruction modifies the frame base calculation, and so the test
picks up whatever memory is pointed to in the callee frame.
Implementing the gdbarch hook gdbarch_stack_frame_destroyed_p fixes
this problem.
As usual with this sort of patch, it has passed internal testing, but
I don't have a good way to try it with dejagnu. So, I don't know
whether some existing test covers this. I suspect there must be one,
but it's also worth noting that this test passes for aarch64 in some
configurations -- I don't know what causes one to fail and another to
succeed.
|
|
When running gdb.cp/non-trivial-retval.exp, the following shows up for
both aarch64-linux and armhf-linux:
Breakpoint 3, f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35
35 A a;
(gdb) finish
Run till exit from #0 f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35
main () at /src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:163
163 B b = f2 (i1, i2);
Value returned is $6 = {a = -11952}
(gdb)
The return value should be {a = 123} instead. This happens because the
backends don't extract the return value from the correct location. GDB should
fetch a pointer to the memory location from X8 for aarch64 and r0 for armhf.
With the patch, gdb.cp/non-trivial-retval.exp has full passes on
aarch64-linux and armhf-linux on Ubuntu 20.04/18.04.
The problem only shows up with the "finish" command. The "call" command
works correctly and displays the correct return value.
This is also related to PR gdb/28681
(https://sourceware.org/bugzilla/show_bug.cgi?id=28681) and fixes FAIL's in
gdb.ada/mi_var_array.exp.
A new testcase is provided, and it exercises GDB's ability to "finish" a
function that returns a large struct (> 16 bytes) and display the
contents of this struct correctly. This has always been incorrect for
these backends, but no testcase exercised this particular scenario.
|
|
aarch64-tdep.c defines the following macro:
#define MEM_ALLOC(MEMS, LENGTH, RECORD_BUF) \
do \
{ \
unsigned int mem_len = LENGTH; \
if (mem_len) \
{ \
MEMS = XNEWVEC (struct aarch64_mem_r, mem_len); \
memcpy(&MEMS->len, &RECORD_BUF[0], \
sizeof(struct aarch64_mem_r) * LENGTH); \
} \
} \
while (0)
This is simlpy allocating a new array and copying it. However, for
the destination address, it is actually copying into the first member
of the first element of the array (`&MEMS->len"). This elicits a
warning with GCC 12:
../../binutils-gdb/gdb/aarch64-tdep.c: In function ‘int aarch64_process_record(gdbarch*, regcache*, CORE_ADDR)’:
../../binutils-gdb/gdb/aarch64-tdep.c:3711:23: error: writing 16 bytes into a region of size 8 [-Werror=stringop-overflow=]
3711 | memcpy(&MEMS->len, &RECORD_BUF[0], \
| ^
../../binutils-gdb/gdb/aarch64-tdep.c:4394:3: note: in expansion of macro ‘MEM_ALLOC’
4394 | MEM_ALLOC (aarch64_insn_r->aarch64_mems, aarch64_insn_r->mem_rec_count,
| ^~~~~~~~~
../../binutils-gdb/gdb/aarch64-tdep.c:3721:12: note: destination object ‘aarch64_mem_r::len’ of size 8
3721 | uint64_t len; /* Record length. */
| ^~~
The simple fix is to reference the array, `MEMS' as the destination of the copy.
Tested by rebuilding.
# Please enter the commit message for your changes. Lines starting
# with '#' will be kept; you may remove them yourself if you want to.
# An empty message aborts the commit.
#
# Date: Tue Jan 25 08:28:32 2022 -0800
#
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
# (use "git push" to publish your local commits)
#
# Changes to be committed:
# modified: aarch64-tdep.c
#
|
|
This changes gdbarch dumping to use filtered output. This seems a bit
better to me, both on the principle that this is an ordinary command,
and because the output can be voluminous, so it may be nice to stop in
the middle.
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
The process record code often emits unfiltered output. In some cases,
this output ought to go to gdb_stderr (but see below). In other
cases, the output is guarded by a logging variable and so ought to go
to gdb_stdlog. This patch makes these changes.
Note that in many cases, the output to stderr is followed by a
"return -1", which is how process record indicates an error. It seems
to me that calling error here would be preferable, because, in many
cases, that's all the caller does when it sees a -1. However, I
haven't made this change.
This is part of PR gdb/7233.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
|
|
Consider the following code:
type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary
function Call_FP1 (F : FP1_Type) return FP1_Type is
begin
return F;
end Call_FP1;
When the default in GCC is to generate proper DWARF info for fixed point
types, then in gdb, printing the result of a call to call_fp1 with a
decimal parameter leads to:
(gdb) p call_fp1(0.5)
$1 = 0
The displayed value is wrong, and we actually expected:
(gdb) p call_fp1(0.5)
$1 = 0.5
What happened is that our fixed point type parameter got promoted to a
32bit integer because we detected that the length of that object was less
than 4 bytes. The compiler does not perform this promotion and therefore
GDB should not either.
This patch fixes the behavior described above.
|
|
Handle the BTI instruction in the prologue analyzer. The patch handles all
the variations of the BTI instruction.
|
|
I would like to be able to use non-trivial types in gdbarch_tdep types.
This is not possible at the moment (in theory), because of the one
definition rule.
To allow it, rename all gdbarch_tdep types to <arch>_gdbarch_tdep, and
make them inherit from a gdbarch_tdep base class. The inheritance is
necessary to be able to pass pointers to all these <arch>_gdbarch_tdep
objects to gdbarch_alloc, which takes a pointer to gdbarch_tdep.
These objects are never deleted through a base class pointer, so I
didn't include a virtual destructor. In the future, if gdbarch objects
deletable, I could imagine that the gdbarch_tdep objects could become
owned by the gdbarch objects, and then it would become useful to have a
virtual destructor (so that the gdbarch object can delete the owned
gdbarch_tdep object). But that's not necessary right now.
It turns out that RISC-V already has a gdbarch_tdep that is
non-default-constructible, so that provides a good motivation for this
change.
Most changes are fairly straightforward, mostly needing to add some
casts all over the place. There is however the xtensa architecture,
doing its own little weird thing to define its gdbarch_tdep. I did my
best to adapt it, but I can't test those changes.
Change-Id: Ic001903f91ddd106bd6ca09a79dabe8df2d69f3b
|
|
The bug fixed by this [1] patch was caused by an out-of-bounds access to
a value's content. The code gets the value's content (just a pointer)
and then indexes it with a non-sensical index.
This made me think of changing functions that return value contents to
return array_views instead of a plain pointer. This has the advantage
that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view
are checked, making bugs more apparent / easier to find.
This patch changes the return types of these functions, and updates
callers to call .data() on the result, meaning it's not changing
anything in practice. Additional work will be needed (which can be done
little by little) to make callers propagate the use of array_view and
reap the benefits.
[1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html
Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
|
|
I wrote this while debugging a problem where the expected unwinder for a
frame wasn't used. It adds messages to show which unwinders are
considered for a frame, why they are not selected (if an exception is
thrown), and finally which unwinder is selected in the end.
To be able to show a meaningful, human-readable name for the unwinders,
add a "name" field to struct frame_unwind, and update all instances to
include a name.
Here's an example of the output:
[frame] frame_unwind_find_by_frame: this_frame=0
[frame] frame_unwind_try_unwinder: trying unwinder "dummy"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "dwarf2 tailcall"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "inline"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "jit"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "python"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "amd64 epilogue"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "i386 epilogue"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "dwarf2"
[frame] frame_unwind_try_unwinder: yes
gdb/ChangeLog:
* frame-unwind.h (struct frame_unwind) <name>: New. Update
instances everywhere to include this field.
* frame-unwind.c (frame_unwind_try_unwinder,
frame_unwind_find_by_frame): Add debug messages.
Change-Id: I813f17777422425f0d08b22499817b23922e8ddb
|
|
While reviewing another patch, I realized that gdbarch_info_init could
easily be removed in favor of initializing gdbarch_info fields directly
in the struct declaration. The only odd part is the union. I don't
know if it's actually important for it to be zero-initialized, but I
presume it is. I added a constructor to gdbarch_info to take care of
that. A proper solution would be to use std::variant. Or, these could
also be separate fields, the little extra space required wouldn't
matter.
gdb/ChangeLog:
* gdbarch.sh (struct gdbarch_info): Initialize fields, add
constructor.
* gdbarch.h: Re-generate.
* arch-utils.h (gdbarch_info_init): Remove, delete all usages.
* arch-utils.c (gdbarch_info_init): Remove.
Change-Id: I7502e08fe0f278d84eef1667a072e8a97bda5ab5
|
|
I wrote a small script to spot a pattern of indentation mistakes I saw
happened in breakpoint.c. And while at it I ran it on all files and
fixed what I found. No behavior changes intended, just indentation and
addition / removal of curly braces.
gdb/ChangeLog:
* Fix some indentation mistakes throughout.
gdbserver/ChangeLog:
* Fix some indentation mistakes throughout.
Change-Id: Ia01990c26c38e83a243d8f33da1d494f16315c6e
|
|
AArch64 MTE support in the Linux kernel exposes a new register
through ptrace. This patch adds the required code to support it.
include/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* elf/common.h (NT_ARM_TAGGED_ADDR_CTRL): Define.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-nat.c (fetch_mteregs_from_thread): New function.
(store_mteregs_to_thread): New function.
(aarch64_linux_nat_target::fetch_registers): Update to call
fetch_mteregs_from_thread.
(aarch64_linux_nat_target::store_registers): Update to call
store_mteregs_to_thread.
* aarch64-tdep.c (aarch64_mte_register_names): New struct.
(aarch64_cannot_store_register): Handle MTE registers.
(aarch64_gdbarch_init): Initialize and setup MTE registers.
* aarch64-tdep.h (gdbarch_tdep) <mte_reg_base>: New field.
<has_mte>: New method.
* arch/aarch64-linux.h (AARCH64_LINUX_SIZEOF_MTE): Define.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-low.cc (aarch64_fill_mteregset): New function.
(aarch64_store_mteregset): New function.
(aarch64_regsets): Add MTE register set entry.
(aarch64_sve_regsets): Add MTE register set entry.
|
|
This patch adds a target description and feature "mte" for aarch64.
It includes one new register, tag_ctl, that can be used to configure the
tag generation rules and sync/async modes. It is 64-bit in size.
The patch also adjusts the code that creates the target descriptions at
runtime based on CPU feature checks.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-nat.c
(aarch64_linux_nat_target::read_description): Take MTE flag into
account.
Slight refactor to hwcap flag checking.
* aarch64-linux-tdep.c
(aarch64_linux_core_read_description): Likewise.
* aarch64-tdep.c (tdesc_aarch64_list): Add one more dimension for
MTE.
(aarch64_read_description): Add mte_p parameter and update to use it.
Update the documentation.
(aarch64_gdbarch_init): Update call to aarch64_read_description.
* aarch64-tdep.h (aarch64_read_description): Add mte_p parameter.
* arch/aarch64.c: Include ../features/aarch64-mte.c.
(aarch64_create_target_description): Add mte_p parameter and update
the code to use it.
* arch/aarch64.h (aarch64_create_target_description): Add mte_p
parameter.
* features/Makefile (FEATURE_XMLFILES): Add aarch64-mte.xml.
* features/aarch64-mte.c: New file, generated.
* features/aarch64-mte.xml: New file.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-ipa.cc (get_ipa_tdesc): Update call to
aarch64_linux_read_description.
(initialize_low_tracepoint): Likewise.
* linux-aarch64-low.cc (aarch64_target::low_arch_setup): Take MTE flag
into account.
* linux-aarch64-tdesc.cc (tdesc_aarch64_list): Add one more dimension
for MTE.
(aarch64_linux_read_description): Add mte_p parameter and update to
use it.
* linux-aarch64-tdesc.h (aarch64_linux_read_description): Add mte_p
parameter.
|
|
Enable displaced stepping over a BR/BLR instruction
Displaced stepping over an instruction executes a instruction in a
scratch area and then manually fixes up the PC address to leave
execution where it would have been if the instruction were in its
original location.
The BR instruction does not need modification in order to run correctly
at a different address, but the displaced step fixup method should not
manually adjust the PC since the BR instruction sets that value already.
The BLR instruction should also avoid such a fixup, but must also have
the link register modified to point to just after the original code
location rather than back to the scratch location.
This patch adds the above functionality.
We add this functionality by modifying aarch64_displaced_step_others
rather than by adding a new visitor method to aarch64_insn_visitor.
We choose this since it seems that visitor approach is designed
specifically for PC relative instructions (which must always be modified
when executed in a different location).
It seems that the BR and BLR instructions are more like the RET
instruction which is already handled specially in
aarch64_displaced_step_others.
This also means the gdbserver code to relocate an instruction when
creating a fast tracepoint does not need to be modified, since nothing
special is needed for the BR and BLR instructions there.
Regression tests showed nothing untoward on native aarch64 (though it
took a while for me to get the testcase to account for PIE).
------#####
Original observed (mis)behaviour before was that displaced stepping over
a BR or BLR instruction would not execute the function they called.
Most easily seen by putting a breakpoint with a condition on such an
instruction and a print statement in the functions they called.
When run with the breakpoint enabled the function is not called and
"numargs called" is not printed.
When run with the breakpoint disabled the function is called and the
message is printed.
--- GDB Session
~ [15:57:14] % gdb ../using-blr
Reading symbols from ../using-blr...done.
(gdb) disassemble blr_call_value
Dump of assembler code for function blr_call_value:
...
0x0000000000400560 <+28>: blr x2
...
0x00000000004005b8 <+116>: ret
End of assembler dump.
(gdb) break *0x0000000000400560
Breakpoint 1 at 0x400560: file ../using-blr.c, line 22.
(gdb) condition 1 10 == 0
(gdb) run
Starting program: /home/matmal01/using-blr
[Inferior 1 (process 33279) exited with code 012]
(gdb) disable 1
(gdb) run
Starting program: /home/matmal01/using-blr
numargs called
[Inferior 1 (process 33289) exited with code 012]
(gdb)
Test program:
---- using-blr ----
\#include <stdio.h>
typedef int (foo) (int, int);
typedef void (bar) (int, int);
struct sls_testclass {
foo *x;
bar *y;
int left;
int right;
};
__attribute__ ((noinline))
int blr_call_value (struct sls_testclass x)
{
int retval = x.x(x.left, x.right);
if (retval % 10)
return 100;
return 9;
}
__attribute__ ((noinline))
int blr_call (struct sls_testclass x)
{
x.y(x.left, x.right);
if (x.left % 10)
return 100;
return 9;
}
int
numargs (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right)
{
printf("numargs called\n");
return 10;
}
void
altfunc (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right)
{
printf("altfunc called\n");
}
int main(int argc, char **argv)
{
struct sls_testclass x = { .x = numargs, .y = altfunc, .left = 1, .right = 2 };
if (argc > 2)
{
blr_call (x);
}
else
blr_call_value (x);
return 10;
}
|
|
I'm trying to enable clang's -Wmissing-variable-declarations warning.
This patch fixes all the obvious spots where we can simply add "static"
(at least, found when building on x86-64 Linux).
gdb/ChangeLog:
* aarch64-linux-tdep.c (aarch64_linux_record_tdep): Make static.
* aarch64-tdep.c (tdesc_aarch64_list, aarch64_prologue_unwind,
aarch64_stub_unwind, aarch64_normal_base, ): Make static.
* arm-linux-tdep.c (arm_prologue_unwind): Make static.
* arm-tdep.c (struct frame_unwind): Make static.
* auto-load.c (auto_load_safe_path_vec): Make static.
* csky-tdep.c (csky_stub_unwind): Make static.
* gdbarch.c (gdbarch_data_registry): Make static.
* gnu-v2-abi.c (gnu_v2_abi_ops): Make static.
* i386-netbsd-tdep.c (i386nbsd_mc_reg_offset): Make static.
* i386-tdep.c (i386_frame_setup_skip_insns,
i386_tramp_chain_in_reg_insns, i386_tramp_chain_on_stack_insns):
Make static.
* infrun.c (observer_mode): Make static.
* linux-nat.c (sigchld_action): Make static.
* linux-thread-db.c (thread_db_list): Make static.
* maint-test-options.c (maintenance_test_options_list):
* mep-tdep.c (mep_csr_registers): Make static.
* mi/mi-cmds.c (struct mi_cmd_stats): Remove struct type name.
(stats): Make static.
* nat/linux-osdata.c (struct osdata_type): Make static.
* ppc-netbsd-tdep.c (ppcnbsd_reg_offsets): Make static.
* progspace.c (last_program_space_num): Make static.
* python/py-param.c (struct parm_constant): Remove struct type
name.
(parm_constants): Make static.
* python/py-record-btrace.c (btpy_list_methods): Make static.
* python/py-record.c (recpy_gap_type): Make static.
* record.c (record_goto_cmdlist): Make static.
* regcache.c (regcache_descr_handle): Make static.
* registry.h (DEFINE_REGISTRY): Make definition static.
* symmisc.c (std_in, std_out, std_err): Make static.
* top.c (previous_saved_command_line): Make static.
* tracepoint.c (trace_user, trace_notes, trace_stop_notes): Make
static.
* unittests/command-def-selftests.c (nr_duplicates,
nr_invalid_prefixcmd, lists): Make static.
* unittests/observable-selftests.c (test_notification): Make
static.
* unittests/optional/assignment/1.cc (counter): Make static.
* unittests/optional/assignment/2.cc (counter): Make static.
* unittests/optional/assignment/3.cc (counter): Make static.
* unittests/optional/assignment/4.cc (counter): Make static.
* unittests/optional/assignment/5.cc (counter): Make static.
* unittests/optional/assignment/6.cc (counter): Make static.
gdbserver/ChangeLog:
* ax.cc (bytecode_address_table): Make static.
* debug.cc (debug_file): Make static.
* linux-low.cc (stopping_threads): Make static.
(step_over_bkpt): Make static.
* linux-x86-low.cc (amd64_emit_ops, i386_emit_ops): Make static.
* tracepoint.cc (stop_tracing_bkpt, flush_trace_buffer_bkpt,
alloced_trace_state_variables, trace_buffer_ctrl,
tracing_start_time, tracing_stop_time, tracing_user_name,
tracing_notes, tracing_stop_note): Make static.
Change-Id: Ic1d8034723b7802502bda23770893be2338ab020
|
|
With the new member functions for struct trad_frame_saved_reg, there is no
need to invoke some of the set/get functions anymore. This patch removes
those and adjusts all callers.
Even though the most natural initial state of a saved register value is
UNKNOWN, there are target backends relying on the previous initial state
of REALREG set to a register's own number. I noticed this in at least a
couple targets: aarch64 and riscv.
Because of that, I decided to keep the reset function that sets the set of
register values to REALREG. I can't exercise all the targets to make sure
the initial state change won't break things, hence why it is risky to change
the default.
Validated with --enable-targets=all on aarch64-linux Ubuntu 18.04/20.04.
gdb/ChangeLog
2021-01-19 Luis Machado <luis.machado@linaro.org>
* trad-frame.h (trad_frame_saved_reg) <set_value_bytes>: Allocate
memory and save data.
(trad_frame_set_value, trad_frame_set_realreg, trad_frame_set_addr)
(trad_frame_set_unknown, trad_frame_set_value_bytes)
(trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p)
(trad_frame_value_bytes_p): Remove.
(trad_frame_reset_saved_regs): Adjust documentation.
* trad-frame.c (trad_frame_alloc_saved_regs): Initialize via a
constructor and reset the state of the registers.
(trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p)
(trad_frame_value_bytes_p, trad_frame_set_value)
(trad_frame_set_realreg, trad_frame_set_addr)
(trad_frame_set_unknown, trad_frame_set_value_bytes): Remove.
(trad_frame_set_reg_realreg): Update to call member function.
(trad_frame_set_reg_addr, trad_frame_set_reg_value_bytes): Likewise.
(trad_frame_get_prev_register): Likewise.
* aarch64-tdep.c (aarch64_analyze_prologue)
(aarch64_analyze_prologue_test, aarch64_make_prologue_cache_1)
(aarch64_prologue_prev_register): Update to use member functions.
* alpha-mdebug-tdep.c (alpha_mdebug_frame_unwind_cache): Likewise.
* alpha-tdep.c (alpha_heuristic_frame_unwind_cache): Likewise.
* arc-tdep.c (arc_print_frame_cache, arc_make_frame_cache): Likewise.
* arm-tdep.c (arm_make_prologue_cache, arm_exidx_fill_cache)
(arm_make_epilogue_frame_cache): Likewise.
* avr-tdep.c (avr_frame_unwind_cache)
(avr_frame_prev_register): Likewise.
* cris-tdep.c (cris_scan_prologue): Likewise.
* csky-tdep.c (csky_frame_unwind_cache): Likewise.
* frv-tdep.c (frv_analyze_prologue): Likewise.
* hppa-tdep.c (hppa_frame_cache, hppa_fallback_frame_cache): Likewise.
* lm32-tdep.c (lm32_frame_cache): Likewise.
* m32r-tdep.c (m32r_frame_unwind_cache): Likewise.
* m68hc11-tdep.c (m68hc11_frame_unwind_cache): Likewise.
* mips-tdep.c (set_reg_offset, mips_insn16_frame_cache)
(mips_micro_frame_cache, mips_insn32_frame_cache): Likewise.
(reset_saved_regs): Adjust to set realreg.
* riscv-tdep.c (riscv_scan_prologue, riscv_frame_cache): Adjust to
call member functions.
* rs6000-tdep.c (rs6000_frame_cache, rs6000_epilogue_frame_cache)
* s390-tdep.c (s390_prologue_frame_unwind_cache)
(s390_backchain_frame_unwind_cache): Likewise.
* score-tdep.c (score7_analyze_prologue)
(score3_analyze_prologue, score_make_prologue_cache): Likewise.
* sparc-netbsd-tdep.c (sparc32nbsd_sigcontext_saved_regs): Likewise.
* sparc-sol2-tdep.c (sparc32_sol2_sigtramp_frame_cache): Likewise.
* sparc64-netbsd-tdep.c (sparc64nbsd_sigcontext_saved_regs): Likewise.
* sparc64-sol2-tdep.c (sparc64_sol2_sigtramp_frame_cache): Likewise.
* tilegx-tdep.c (tilegx_analyze_prologue)
(tilegx_frame_cache): Likewise.
* v850-tdep.c (v850_frame_cache): Likewise.
* vax-tdep.c (vax_frame_cache): Likewise.
|
|
This patch adds support for bfloat16 in AArch64 gdb.
Also adds the field "bf" to vector registers h0-h31.
Also adds the vector "bf" to h field in vector registers v0-v31.
The following is how the vector register h and v looks like.
Before this patch:
(gdb) p $h0
$1 = {f = 0, u = 0, s = 0}
(gdb) p/x $h0
$2 = {f = 0x0, u = 0x0, s = 0x0}
(gdb) p $v0.h
$3 = {f = {0, 0, 0, 0, 0, 0, 0, 0}, u = {0, 0, 0, 0, 0, 0, 0, 0}, s = {0, 0, 0, 0, 0, 0, 0, 0}}
(gdb) p/x $v0.h
$4 = {f = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
s = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
After this patch:
(gdb) p $h0
$1 = {bf = 0, f = 0, u = 0, s = 0}
(gdb) p/x $h0
$2 = {bf = 0x0, f = 0x0, u = 0x0, s = 0x0}
(gdb) p $v0.h
$3 = {bf = {0, 0, 0, 0, 0, 0, 0, 0}, f = {0, 0, 0, 0, 0, 0, 0, 0}, u = {0, 0, 0, 0, 0, 0, 0, 0},
s = {0, 0, 0, 0, 0, 0, 0, 0}}
(gdb) p/x $v0.h
$4 = {bf = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, f = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
u = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, s = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
gdb/ChangeLog:
2021-01-12 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
* aarch64-tdep.c (aarch64_vnh_type): Add "bf" field in h registers.
(aarch64_vnv_type): Add "bf" type in h field of v registers.
* features/aarch64-fpu.c (create_feature_aarch64_fpu): Regenerated.
* features/aarch64-fpu.xml: Add bfloat16 type.
gdb/testsuite/ChangeLog:
2021-01-12 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
* gdb.arch/aarch64-fp.exp: Modify to test bfloat16 support.
|
