The vast majority of vector FP insns comes in single/double pairs. Many
pairs follow certain encoding patterns. Introduce an "sd" template to
reduce redundancy. Similarly, to further cover similarities between
AVX512F and AVX512-FP16, introduce an "sdh" template.
For element-size Disp8 shift generalize i386-gen's broadcast size
determination, allowing Disp8MemShift to be specified without an operand
in the affected templated templates. While doing the adjustment also
eliminate an unhelpful (lost information) diagnostic combined with a use
after free in what is now get_element_size().
Note that in the course of the conversion
- the AVX512F form of VMOVUPD has a stray (leftover) Load attribute
dropped,
- VMOVSH has a benign IgnoreSize added (the attribute is still strictly
necessary for VMOVSD, and necessary for VMOVSS as long as we permit
strange combinations like "-march=i286+avx"),
- VFPCLASSPH is properly split to separate AT&T and Intel syntax forms,
matching VFPCLASSP{S,D}.
This reverts commit 384f368958f2a5bb083660e58e5f8a010e6ad429, which
broke i386-gen's emitting of diagnostics. As a replacement to address
the original issue of newer gcc no longer splicing lines when dropping
the line continuation backslashes, switch to using + as the line
continuation character, doing the line splicing in i386-gen.
2022-08-16 Alan Modra <amodra@gmail.com>
Cunlong Li <shenxiaogll@163.com>
PR 29362
* dwarf.c (free_debug_information): New function, extracted..
(free_debug_memory): ..from here.
(process_debug_info): Use it when before clearing out unit
debug_information. Clear all fields.
* objcopy.c (delete_symbol_htabs): New function.
(main): Call it via xatexit.
(copy_archive): Free "dir".
* objdump.c (free_debug_section): Free reloc_info.
When kernel veriosn >= V4.x, the characteristic values used to
determine whether it is a signal function call are:
movi r7, 139
trap 0
Registers are saved at (sp + CSKY_SIGINFO_OFFSET + CSKY_SIGINFO_SIZE
+ CSKY_UCONTEXT_SIGCONTEXT + CSKY_SIGCONTEXT_PT_REGS_TLS). The order
is described in csky_linux_rt_sigreturn_init_pt_regs.
I know this target is just a skeleton, but let's not write out relocs
with uninitialised garbage.
* coff-aarch64.c (SWAP_IN_RELOC_OFFSET): Define.
(SWAP_OUT_RELOC_OFFSET): Define.
There's a comment in riscv-tdep.c that explains some of the background
about how we check for the fcsr, fflags, and frm registers within a
riscv target description.
This comment (and the functionality it describes) relates to how QEMU
advertises these registers within its target description.
Unfortunately, QEMU includes these three registers in both the fpu and
crs target description features. To work around this GDB uses one of
the register declarations, and ignores the other, this means the GDB
user sees a single copy of each register, and things just work.
When I originally wrote the comment I thought it didn't matter which
copy of the register GDB selected, the fpu copy or the csr copy, so
long as we just used one of them. The comment reflected this belief.
Upon further investigation, it turns out I was wrong. GDB has to use
the csr copy of the register. If GDB tries to use the register from
the fpu feature then QEMU will return an error when GDB tries to read
or write the register.
Luckily, the code within GDB (currently) will always select the csr
copy of the register, so nothing is broken, but the comment is wrong.
This commit updates the comment to better describe what is actually
going on.
Of course, I should probably also send a patch to QEMU to fix up the
target description that is sent to GDB.
After this commit:
commit 7b7c365c5c663ffdfb2b3f696db35c23cdccd921
Date: Wed Sep 15 10:10:46 2021 +0200
[bfd] Ensure unique printable names for bfd archs
The printable name field of the default nds32 bfd_arch_info changed
from 'n1h' to 'n1'. As a consequence the generated feature file
within GDB should have been recreated. Recreate it now.
breakpoint::decode_location_spec just asserts if called. It turned
out to be relatively easy to remove this method from breakpoint and
instead move the base implementation to code_breakpoint.
This changes readelf output a little, removing the 0x prefix on hex
output when the value is 0, except in cases where a fixed field
width is shown. %#010x is not a good replacement for 0x%08x.
This replaces dwarf_vma, dwarf_size_type and dwarf_signed_vma with
uint64_t and int64_t everywhere. The patch also gets rid of
DWARF_VMA_FMT since we can't use that with uint64_t, and all of the
configure support for deciding the flavour of HOST_WIDEST_INT.
dwarf_vmatoa also disappears, replacing most uses with one of
PRIx64, PRId64 or PRIu64. Printing of size_t and ptrdiff_t values
now use %z and %t rather than by casting to unsigned long. Also,
most warning messages that used 0x%lx or similar now use %#lx and a
few that didn't print the 0x hex prefix now also use %#. The patch
doesn't change normal readelf output, except in odd cases where values
previously might have been truncated.
This replaces bfd_vma with uint64_t in readelf, defines BFD64
unconditionally, removes tests of BFD64 and sizeof (bfd_vma), and
removes quite a few now unnecessary casts.
Replacing bfd_size_type with dwarf_size_type or uint64_t is mostly
cosmetic. The point of the change is to avoid use of a BFD type
in readelf, where we'd like to keep as independent of BFD as
possible. Also, the patch is a step towards using standard types.
This patch replaces all uses of elf_vma with uint64_t, removes
tests of sizeof (elf_vma), and does a little tidying of
byte_get_little_endian and byte_get_big_endian.
When running test-case gdb.dwarf2/dw2-dir-file-name.exp on x86_64-linux, we
have:
...
(gdb) break compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line 999.^M
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x00000000004004c4 in \
compdir_missing__ldir_missing__file_basename () \
at tmp-dw2-dir-file-name.c:999^M
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
compdir_missing__ldir_missing__file_basename
...
When trying to set a breakpoint on
compdir_missing__ldir_missing__file_basename, the architecture-specific
prologue skipper starts at 0x4004c0 and skips past two insns, to 0x4004c4:
...
00000000004004c0 <compdir_missing__ldir_missing__file_basename>:
4004c0: 55 push %rbp
4004c1: 48 89 e5 mov %rsp,%rbp
4004c4: 8b 05 72 1b 20 00 mov 0x201b72(%rip),%eax # 60203c <v>
4004ca: 83 c0 01 add $0x1,%eax
4004cd: 89 05 69 1b 20 00 mov %eax,0x201b69(%rip) # 60203c <v>
4004d3: 90 nop
4004d4: 5d pop %rbp
4004d5: c3 ret
...
And because the line table info is rudamentary:
...
CU: tmp-dw2-dir-file-name.c:
File name Line number Starting address View Stmt
tmp-dw2-dir-file-name.c 999 0x4004c0 x
tmp-dw2-dir-file-name.c 1000 0x4004d6 x
tmp-dw2-dir-file-name.c - 0x4004d6
...
the address does not fall at an actual line, so the breakpoint is shown with
address, both when setting it and hitting it.
when running the test-case with aarch64-linux, we have similarly:
...
(gdb) break compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line 999.^M
...
due to the architecture-specific prologue skipper starting at 0x400610 and
skipping past two insns, to 0x400618:
...
0000000000400610 <compdir_missing__ldir_missing__file_basename>:
400610: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17>
400614: 9100b000 add x0, x0, #0x2c
400618: b9400000 ldr w0, [x0]
40061c: 11000401 add w1, w0, #0x1
400620: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17>
400624: 9100b000 add x0, x0, #0x2c
400628: b9000001 str w1, [x0]
40062c: d503201f nop
400630: d65f03c0 ret
...
But interestingly, the aarch64 architecture-specific prologue skipper is
wrong. There is no prologue, and the breakpoint should be set at 0x400610.
By using "break *compdir_missing__ldir_missing__file_basename"
we can get the breakpoint set at 0x400610:
...
(gdb) break *compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line 999.^M
...
and make the test-case independent of prologue analysis.
This requires us to update the expected patterns.
The fix ensures that once the aarch64 architecture-specific prologue skipper
will be fixed, this test-case won't start failing.
Tested on x86_64-linux.
When doing varobj_re_set, we currently try to recreate floating varobj.
This was introduced by 4e969b4f0128 "Re-evaluate floating varobj as part
of varobj_invalidate" to deal with use a after free issue. However
since bc20e562ec0 "Fix use after free in varobj" we now ensure that we
never have dangling pointers so this all recreation is not strictly
needed anymore for floating varobjs.
This commit proposes to remove this recreation process for floating
varobjs.
Tested on x86_64-linux.
[This patch is a followup to the discussion in
https://sourceware.org/pipermail/gdb-patches/2022-August/191188.html]
PR/29426 shows failures when running the gdb.mi/mi-var-invalidate-shlib
test when using a compiler which does not produce a PIE executable by
default.
In the testcase, a varobj is created to track a global variable, and
then the main binary is reloaded in GDB (using the file command).
During the load of the new binary, GDB tries to recreate the varobj to
track the global in the new binary (varobj_invalidate_iter). At this
point, the old process is still in flight. So when we try to access to
the value of the global, in a PIE executable we only have access to the
unrelocated address (the objfile's text_section_offset () is 0). As a
consequence down the line read_value_memory fails to read the unrelated
address, so cannot evaluate the value of the global. Note that the
expression used to access to the global’s value is valid, so the varobj
can be created. When using a non PIE executable, the address of the
global GDB knows about at this point does not need relocation, so
read_value_memory can access the (old binary’s) value.
So at this point, in the case of a non-PIE executable the value field is
set, while it is cleared in the case of PIE executable. Later when the
test issues a "-var-update global_var", the command sees no change in
the case of the non-PIE executable, while in the case of the PIE
executable install_new_value sees that value changes, leading to a
different output.
This patch makes sure that, as we do for breakpoints, we wait until
relocation has happened before we try to recreate varobjs. This way we
have a consistent behavior between PIE and non-PIE binaries.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29426
Co-authored-by: Lancelot SIX <lancelot.six@amd.com>
The varobj_invalidate_iter function has logic to invalidate any local
varobj it can find. However since bc20e562ec0 "gdb/varobj: Fix use
after free in varobj" all varobj containing references to an objfile are
cleared when the objfile goes out of scope. This means that at this
point any local varobj seen by varobj_invalidate_iter either has
already been invalidated by varobj_invalidate_if_uses_objfile or only
contains valid references and there is no reason to invalidate it.
This patch proposes to remove this unnecessary invalidation and adds a
testcase which exercises a scenario where a local varobj can legitimately
survive a call to varobj_invalidate_iter.
At this point the varobj_invalidate and varobj_invalidate_iter seem
misnamed since they deal with re-creating invalid objects and do not do
invalidation, but this will be fixed in a following patch.
Tested on x86_64-linux.
svstep and svshape instructions subtract 1 before encoding some of the
operands. Obviously zero is not supported for these operands. Whilst
PPC_OPERAND_PLUS1 fits perfectly to mark that maximal value should be
incremented, there is no flag which marks the fact that zero values are
not allowed. This patch adds a new flag, PPC_OPERAND_NONZERO, for this
purpose.
This patch adds support for LibreSOC machine and SVP64 extension flag
for PowerPC architecture. SV (Simple-V) is a strict RISC-paradigm
Scalable Vector Extension for the Power ISA. SVP64 is the 64-bit
Prefixed instruction format implementing SV. Funded by NLnet through EU
Grants No: 825310 and 825322, SV is in DRAFT form and is to be publicly
submitted via the OpenPOWER Foundation ISA Working Group via the
newly-created External RFC Process.
For more details, visit https://libre-soc.org.
With this change, only valid contents of LR are accepted when unwinding
exception frames for m-profile targets.
If the contents of LR are anything but EXC_RETURN or FNC_RETURN, it
will cause GDB to print an error and/or abort unwinding of the frame as
it's an invalid state for the unwinder.
The FNC_RETURN pattern requires Security Extensions to be enabled.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
They were legacy relocation types copied from other ports. The related
-fvtable-gc was removed from GCC in 2003.
The associated assembler directives (.vtable_inherit and .vtable_entry)
have never been supported by the RISC-V port. Remove related ld code.
Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/323
Commit 53f2b36a54b9 exposed a bug in sb_scrub_and_add_sb that could
result in losing input. If scrubbing results in expansion past the
holding capacity of do_scrub_chars output buffer, then do_scrub_chars
stashes the extra input for the next call. That call never came
because sb_scrub_and_add_sb wrongly decided it was done. Fix that by
allowing sb_scrub_and_add_sb to see whether there is pending input.
Also allow a little extra space so that in most cases we won't need
to resize the output buffer.
sb_scrub_and_add_sb also limited output to the size of the input,
rather than the actual output buffer size. Fixing that resulted in a
fail of gas/testsuite/macros/dot with an extra warning: "end of file
not at end of a line; newline inserted". OK, so the macro in dot.s
really does finish without end-of-line. Apparently the macro
expansion code relied on do_scrub_chars returning early. So fix that
too by adding a newline if needed in macro_expand_body.
PR 29466
* app.c (do_scrub_pending): New function.
* as.h: Declare it.
* input-scrub.c (input_scrub_include_sb): Add extra space for
two .linefile directives.
* sb.c (sb_scrub_and_add_sb): Take into account pending input.
Allow output to max.
* macro.c (macro_expand_body): Add terminating newline.
* testsuite/config/default.exp (SIZE, SIZEFLAGS): Define.
* testsuite/gas/macros/app5.d,
* testsuite/gas/macros/app5.s: New test.
* testsuite/gas/macros/macros.exp: Run it.
The "script" field, output whenever information about a breakpoint with
commands is output, uses wrong MI syntax.
$ ./gdb -nx -q --data-directory=data-directory -x script -i mi
=thread-group-added,id="i1"
=breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",original-location="main"}
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",script={"aaa","bbb","ccc"},original-location="main"}
(gdb)
-break-info
^done,BreakpointTable={nr_rows="1",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="18",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",script={"aaa","bbb","ccc"},original-location="main"}]}
(gdb)
In both the =breakpoint-modified and -break-info output, we have:
script={"aaa","bbb","ccc"}
According to the output syntax [1], curly braces means tuple, and a
tuple contains key=value pairs. This looks like it should be a list,
but uses curly braces by mistake. This would make more sense:
script=["aaa","bbb","ccc"]
Fix it, keeping the backwards compatibility by introducing a new MI
version (MI4), in exactly the same way as was done when fixing
multi-locations breakpoint output in [2].
- Add a fix_breakpoint_script_output uiout flag. MI uiouts will use
this flag if the version is >= 4.
- Add a fix_breakpoint_script_output_globally variable and the
-fix-breakpoint-script-output MI command to set it, if frontends want
to use the fixed output for this without using the newer MI version.
- When emitting the script field, use list instead of tuple, if we want
the fixed output (depending on the two criteria above)
-
[1] https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Output-Syntax.html#GDB_002fMI-Output-Syntax
[2] b4be1b0648
Change-Id: I7113c6892832c8d6805badb06ce42496677e2242
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24285
After commit:
commit a88c79b77036e4778e70d62081c3cfd1044bb8e3
Date: Tue Aug 9 14:57:48 2022 +0100
Default to enabling colored disassembly if output is to a terminal.
The 256 extended-color support for --disassembler-color was broken.
This is fixed in this commit.
PR 29457
* objdump (objdump_styled_sprintf): Check disassembler_color
against an enum value, don't treat it as a bool.
The x0 (zero) register is read-only on RISC-V. Implement the
cannot_store_register gdbarch method to tell GDB this.
Without this method GDB will try to write to x0, and relies on the
target to ignore such writes. If you are using a target that
complains (or throws an error) when writing to x0, this change will
prevent this from happening.
The gdb.arch/riscv-reg-aliases.exp test exercises writing to x0, and
will show the errors when using a suitable target.
With a recent import of gnulib, code has been pulled that tests and enables
64-bit time_t by default on 32-bit hosts that support it.
Although gdb can use the gnulib support, bfd doesn't use gnulib and currently
doesn't do these checks.
As a consequence, if we have a 32-bit host that supports 64-bit time_t, we'll
have a mismatch between gdb's notion of time_t and bfd's notion of time_t.
This will lead to mismatches in the struct stat size, leading to memory
corruption and crashes.
This patch disables the year 2038 check for now, which makes things work
reliably again.
I'd consider this a temporary fix until we have proper bfd checks for the year
2038, if it makes sense. 64-bit hosts seems to be more common these days, so
I'm not sure how important it is to have this support enabled and how soon
we want to enable it.
Thoughts?
PR gas/29451
While out_debug_abbrev() properly skips such functions, out_debug_info()
mistakenly didn't. It needs to calculate the high_pc expression ahead of
time, in order to skip emitting any data for the function if the value
is zero.
The one case which would still leave a zero-size entry is when
symbol_get_obj(symp)->size ends up evaluating to zero. I hope we can
expect that to not be the case, otherwise we'd need to have a way to
post-process .debug_info contents between resolving expressions and
actually writing the data out to the file. Even then it wouldn't be
entirely obvious in which way to alter the data.
Prior to the inline plt call support (commit 08be322439), the only
local syms with plt entries were local ifunc symbols. There shouldn't
be stubs for other local symbols so don't look for them. The patch
also fixes minor bugs in get_reference_flags; Many relocs are valid
only for ppc64 and a couple only for ppc32.
PR 29462
* powerpc.cc (Target_powerpc::Relocate::relocate): Rename
use_plt_offset to pltcal_to_direct, invert logic. For relocs
not used with inline plt sequences against local symbols, only
look for stubs when the symbol is an ifunc.
(Target_powerpc::Scan::get_reference_flags): Correct reloc
handling for relocs not valid for both 32-bit and 64-bit.
This adds support for efi-loongarch64 by virtue of adding a new PEI target
pei-loongarch64. This is not a full target and only exists to support EFI at
this time.
This means that this target does not support relocation processing and is mostly
a container format. This format has been added to elf based loongarch64 targets
such that efi images can be made natively on Linux.
However this target is not valid for use with gas but only with objcopy.
We should't limit addresses to 32-bits for 64-bit vma, otherwise there will be
"RVA truncated" error when using objcopy on loongarch64.
With these changes the resulting file is recognized as an efi image.
Any magic number is based on the Microsoft PE specification [1].
The test results are as follows:
$ make check-binutils RUNTESTFLAGS='loongarch64.exp'
PASS: Check if efi app format is recognized
$ objdump -h -f tmpdir/loongarch64copy.o
tmpdir/loongarch64copy.o: file format pei-loongarch64
architecture: Loongarch64, flags 0x00000132:
EXEC_P, HAS_SYMS, HAS_LOCALS, D_PAGED
start address 0x0000000000000000
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0000003c 00000000200000b0 00000000200000b0 00000200 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
[1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
bfd:
* .gitignore (pe-loongarch64igen.c): New.
* Makefile.am (pei-loongarch64.lo, pe-loongarch64igen.lo, pei-loongarch64.c,
pe-loongarch64igen.c): Add support.
* Makefile.in: Likewise.
* bfd.c (bfd_get_sign_extend_vma): Add pei-loongarch64.
* coff-loongarch64.c: New file.
* coffcode.h (coff_set_arch_mach_hook, coff_set_flags,
coff_write_object_contents) Add loongarch64 (loongarch64_pei_vec) support.
* config.bfd: Likewise.
* configure: Likewise.
* configure.ac: Likewise.
* libpei.h (GET_OPTHDR_IMAGE_BASE, PUT_OPTHDR_IMAGE_BASE,
GET_OPTHDR_SIZE_OF_STACK_RESERVE, PUT_OPTHDR_SIZE_OF_STACK_RESERVE,
GET_OPTHDR_SIZE_OF_STACK_COMMIT, PUT_OPTHDR_SIZE_OF_STACK_COMMIT,
GET_OPTHDR_SIZE_OF_HEAP_RESERVE, PUT_OPTHDR_SIZE_OF_HEAP_RESERVE,
GET_OPTHDR_SIZE_OF_HEAP_COMMIT, PUT_OPTHDR_SIZE_OF_HEAP_COMMIT,
GET_PDATA_ENTRY, _bfd_peLoongArch64_bfd_copy_private_bfd_data_common,
_bfd_peLoongArch64_bfd_copy_private_section_data,
_bfd_peLoongArch64_get_symbol_info, _bfd_peLoongArch64_only_swap_filehdr_out,
_bfd_peLoongArch64_print_private_bfd_data_common,
_bfd_peLoongArch64i_final_link_postscript,
_bfd_peLoongArch64i_only_swap_filehdr_out, _bfd_peLoongArch64i_swap_aouthdr_in,
_bfd_peLoongArch64i_swap_aouthdr_out, _bfd_peLoongArch64i_swap_aux_in,
_bfd_peLoongArch64i_swap_aux_out, _bfd_peLoongArch64i_swap_lineno_in,
_bfd_peLoongArch64i_swap_lineno_out, _bfd_peLoongArch64i_swap_scnhdr_out,
_bfd_peLoongArch64i_swap_sym_in, _bfd_peLoongArch64i_swap_sym_out,
_bfd_peLoongArch64i_swap_debugdir_in, _bfd_peLoongArch64i_swap_debugdir_out,
_bfd_peLoongArch64i_write_codeview_record,
_bfd_peLoongArch64i_slurp_codeview_record,
_bfd_peLoongArch64_print_ce_compressed_pdata): New.
* peXXigen.c (_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out,
_bfd_XXi_swap_scnhdr_out, pe_print_pdata, _bfd_XX_print_private_bfd_data_common,
_bfd_XX_bfd_copy_private_section_data, _bfd_XXi_final_link_postscript):
Support COFF_WITH_peLoongArch64,
* pei-loongarch64.c: New file.
* peicode.h (coff_swap_scnhdr_in, pe_ILF_build_a_bfd, pe_ILF_object_p):
Support COFF_WITH_peLoongArch64.
(jtab): Add dummy entry that traps.
* targets.c (loongarch64_pei_vec): New.
binutils
* testsuite/binutils-all/loongarch64/loongarch64.exp: New file.
* testsuite/binutils-all/loongarch64/pei-loongarch64.d: New test.
* testsuite/binutils-all/loongarch64/pei-loongarch64.s: New test.
include
* coff/loongarch64.h: New file.
* coff/pe.h (IMAGE_FILE_MACHINE_LOONGARCH64): New.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
When running on a native RISC-V Linux target I currently see failures
in the gdb.arch/riscv-reg-aliases.exp test like this:
set $ft0.float = 501
(gdb) PASS: gdb.arch/riscv-reg-aliases.exp: write non-zero value to ft0
p/d $ft0.float
$263 = 1140490240
(gdb) FAIL: gdb.arch/riscv-reg-aliases.exp: read ft0 after non-zero write to ft0
This test started failing after this commit:
commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e
Date: Thu Feb 17 13:43:59 2022 -0700
Change how "print/x" displays floating-point value
The problem is that when 501 is written to $ft0.float the value is
converted to floating point format and stored in the register. Prior
to the above commit printing with /x and /d would first extract the
value as a float, and then convert the value to an integer for
display. After the above commit GDB now uses the raw register value
when displaying /x and /d, and so we see this behaviour:
(gdb) info registers $ft0
ft0 {float = 501, double = 5.6347704700123827e-315} (raw 0x0000000043fa8000)
(gdb) p/f $ft0.float
$1 = 501
(gdb) p/d $ft0.float
$2 = 1140490240
(gdb) p/x $ft0.float
$3 = 0x43fa8000
To fix this test I now print the float registers using the /f format
rather than /d. With this change the test now passes.
