The new -march=armv9.5-a flag enables access to the
mandatory cpa, lut and faminmax extensions.
Existing test cases for features are extended to verify they
work without additional flags.
Lulu Cai [Wed, 19 Jun 2024 03:00:36 +0000 (11:00 +0800)]
LoongArch: Do not check R_LARCH_SOP_PUSH_ABSOLUTE to avoid broken links to old object files
R_LARCH_SOP_PUSH_ABSOLUTE with -fPIC was heavily used in the era of gas-2.38.
We do not check this relocation to prevent broken links with old object
files.
Jan Beulich [Fri, 28 Jun 2024 06:22:39 +0000 (08:22 +0200)]
x86/APX: optimize {nf}-form IMUL-by-power-of-2 to SHL
..., for differing only in the resulting EFLAGS, which are left
untouched anyway. That's a shorter encoding, available as long as
certain constraints on operands are met; see code comments. (SHL-by-1
forms may then be subject to further optimization that was introduced
earlier.)
Note that kind of as a side effect this also converts multiplication by
1 to shift by 0, which is a plain move or even no-op anyway. That could
be further shrunk (as could be presence of shifts/rotates by 0 in the
original code as well as a fair set of other {nf}-form insns), yet the
expectation (for now) is that people won't write such code in the first
place.
Jan Beulich [Fri, 28 Jun 2024 06:21:48 +0000 (08:21 +0200)]
x86-64: restrict by-imm31 optimization
Avoid changing the encoding when there's no size gain: If there's a REX
or REX2 prefix anyway and the base opcode wouldn't be changed, dropping
just REX.W / REX2.W has no (size) effect. (Same for the AND-by-imm7 case
in the same big conditional.)
While there also pull out the .qword check: For the 2-register-operands
case whether that's done on the 1st or 2nd operand doesn't matter. Due
to reduction in necessary parentheses this improves readability a tiny
bit.
Jan Beulich [Fri, 28 Jun 2024 06:19:59 +0000 (08:19 +0200)]
x86/APX: optimize certain {nf}-form insns to LEA
..., as that leaves EFLAGS untouched anyway. That's a shorter encoding,
available as long as certain constraints on operand size and registers
are met; see code comments.
Note that this requires deferring to derive encoding_evex from {nf}
presence, as in optimize_encoding() we want to avoid touching the insns
when {evex} was also used.
Note further that this requires want_disp32() to now also consider the
opcode: We don't want to replace i.tm.mnem_off, for diagnostics to still
report the original mnemonic (or else things can get confusing). While
there, correct adjacent mis-indentation.
Unlike for the legacy forms, where there's a difference in the resulting
EFLAGS.CF, for the NF variants the immediate can be got rid of in that
case by switching to a 1-bit rotate in the opposite direction.
Jan Beulich [Fri, 28 Jun 2024 06:18:40 +0000 (08:18 +0200)]
x86/APX: optimize {nf} forms of ADD/SUB with specific immediates
Unlike for the legacy forms, where there's a difference in the resulting
EFLAGS, for the NF variants we can safely replace ones using 0x80 by the
respectively other insn while negating the immediate, saving 3 immediate
bytes (just 1 though for 16-bit operand size). Similarly we can replace
ones using 1 / -1 by INC/DEC (eliminating the immediate).
Jan Beulich [Fri, 28 Jun 2024 06:17:41 +0000 (08:17 +0200)]
gas: .irp/.irpc are macro-like
... for the purposes of get_line_sb() and _find_end_of_line(): They
support \@ just like macros do, and hence the special casing there also
needs applying.
Nelson Chu [Thu, 27 Jun 2024 04:27:33 +0000 (12:27 +0800)]
RISC-V: Shrink the riscv_implicit_subsets table.
Allow to add implicit extensions by using the syntax of `.option arch, +-', so
that the table is shrinked and more readable.
bfd/
* elfxx-riscv.c (check_implicit_always): Removed the unused IMPLICIT
parameter.
(check_implicit_for_i): Likewise.
(riscv_implicit_subsets): Shrink the table by allowing the syntax of
`.option arch, +-' for implicit extensions.
(riscv_update_subset1): New function, called from riscv_update_subset
or riscv_parse_add_implicit_subsets. It basically does the same thing
as riscv_update_subset function before.
(riscv_parse_add_implicit_subsets): Updated.
(riscv_update_subset): Updated.
Nelson Chu [Tue, 11 Jun 2024 08:35:58 +0000 (16:35 +0800)]
RISC-V: PR27180, Update relocation for riscv_zero_pcrel_hi_reloc.
When pcrel access overflow, the riscv_zero_pcrel_hi_reloc may convert pcrel
relocation to absolutly access if possible at the relocate stage. We used to
encode the target address into r_sym of R_RISCV_HI20 if it is converted from
R_RISCV_PCREL_HI20. But that may cause segfault if --emit-relocs is set,
since r_sym becomes an address rather than a symbol index. Although the
relocate result is correct, it does not meet the definition, so may cause
unexpected behaviors.
This patch encodes the target address into r_addend, rather than r_sym, if
riscv_zero_pcrel_hi_reloc converts the relocation. Besdies, since the
corresponding pcrel_lo relocation are also changed to absolutly access,
we should also update them to R_RISCV_LO12_I/S.
bfd/
PR 27180
* elfnn-riscv.c (riscv_pcrel_hi_reloc): New boolean `absolute', to
inform corresponding pcrel_lo that the pcrel_hi relocation was already
converted to hi20 relocation.
(riscv_record_pcrel_hi_reloc): Likewise, record `absolute'.
(riscv_pcrel_lo_reloc): Removed `const' for Elf_Internal_Rela *reloc,
since we may need to convert it from pcrel_lo to lo relocation.
(riscv_record_pcrel_lo_reloc): Likewise. Convert pcrel_lo to lo
relocation if corresponding pcrel_hi was converted to hi relocation.
(riscv_zero_pcrel_hi_reloc): Encode target absolute address into
r_addend rather than r_sym. Clear the `addr' to avoid duplicate
relocate in the perform_relocation.
(riscv_elf_relocate_section): Updated.
ld/
PR 27180
* testsuite/ld-riscv-elf/pcrel-lo-addend-3a-emit-relocs.d: New testcase.
Segfault without applying this patch.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
H.J. Lu [Tue, 25 Jun 2024 07:45:22 +0000 (00:45 -0700)]
Set BFD_DECOMPRESS when reading build-id debuglink
We should set BFD_DECOMPRESS to decompress sections unless dumping the
section contents when reading build-id debuglink.
PR binutils/31925
* objdump.c (open_debug_file): Set BFD_DECOMPRESS to decompress
sections unless dumping the section contents.
* testsuite/binutils-all/objdump.exp (test_build_id_debuglink):
Add a compress option.
Run test_build_id_debuglink with none and zlib.
Andrew Burgess [Wed, 19 Jun 2024 10:13:14 +0000 (11:13 +0100)]
gdb: add overloads of gdb_tilde_expand
Like the previous commit, add two overloads of gdb_tilde_expand, one
takes std::string and other takes gdb::unique_xmalloc_ptr<char>. Make
use of these overloads throughout GDB and gdbserver.
There should be no user visible changes after this commit.
Andrew Burgess [Wed, 19 Jun 2024 10:12:28 +0000 (11:12 +0100)]
gdb: add overloads of gdb_abspath
Add two overloads of gdb_abspath, one which takes std::string and one
which takes gdb::unique_xmalloc_ptr<char>, then make use of these
overloads throughout GDB and gdbserver.
There should be no user visible changes after this commit.
Alan Modra [Thu, 27 Jun 2024 03:01:46 +0000 (12:31 +0930)]
Re: Rewrite SHT_GROUP handling
There is no need to loop over the headers twice. Remove that leftover
from the previous scheme. Also, the previous scheme silently ignored
a section being mentioned in two or more SHT_GROUP sections.
* elf.c (process_sht_group_entries): Prevent sections from
belonging to two groups.
(_bfd_elf_setup_sections): Process groups in a single loop
over headers.
Alan Modra [Wed, 26 Jun 2024 08:17:21 +0000 (17:47 +0930)]
Rewrite SHT_GROUP handling
This patch delays setting up elf_next_in_group, elf_sec_group and
elf_group_name when reading ELF object files until after all ELF
sections have been processed by bfd_section_from_shdr. This is simpler
and more robust than the current scheme of driving the whole process
on detecting a section with SHF_GROUP set.
* elf-bfd.h (struct elf_obj_tdata): Delete group_sect_ptr,
num_group and group_search_offset.
* elf.c (Elf_Internal_Group): Delete.
(setup_group): Delete function.
(IS_VALID_GROUP_SECTION_HEADER): Delete macro.
(is_valid_group_section_header),
(process_sht_group_entries): New functions.
(_bfd_elf_setup_sections): Handle group sections here..
(_bfd_elf_make_section_from_shdr): ..rather than here.
(bfd_section_from_shdr): Don't check SHT_GROUP validity here.
Tom de Vries [Wed, 26 Jun 2024 06:49:40 +0000 (08:49 +0200)]
[gdb/testsuite] Fix timeout in gdb.base/bg-execution-repeat.exp
I ran into the following test failure with test-case
gdb.base/bg-execution-repeat.exp:
...
(gdb) PASS: gdb.base/bg-execution-repeat.exp: c&: repeat bg command
^M
Breakpoint 2, foo () at bg-execution-repeat.c:23^M
23 return 0; /* set break here */^M
print 1^M
$1 = 1^M
(gdb) PASS: gdb.base/bg-execution-repeat.exp: c&: input still accepted
FAIL: gdb.base/bg-execution-repeat.exp: c&: breakpoint hit 2 (timeout)
...
The failure can be easily reproduced by adding a sleep 5 here:
...
+ sleep 5
gdb_test "print 1" " = 1" "input still accepted"
...
There's a race in the test-case, between:
- the command handled in the foreground: the "print 1" command, and
- the command handled in the background: the continue command.
The current way of dealing with this is by putting the inferior to sleep for 5
seconds:
...
foo ();
sleep (5);
foo ();
...
with the aim that the "print 1" command will win the race.
This method is both slow and unreliable.
Fix this by making the inferior wait till the "print 1" command is done.
This reduces running time from ~11s to ~1s.
I also verified that the test-case still triggers on the original problem by
applying this gdb/infcmd.c patch:
...
-strip_bg_char (const char *args, int *bg_char_p)
+strip_bg_char (const char *_args, int *bg_char_p)
{
- const char *p;
+ char *args = const_cast<char *>(_args);
+ char *p;
Indu Bhagat [Wed, 26 Jun 2024 05:27:12 +0000 (22:27 -0700)]
doc: sframe: small improvements for readability
Update some of the content to make the specification document hopefully
clearer:
- Fix some typos.
- Use Title case consistently for headings.
- Update text around detection of foreign endianness.
- Split the structure field "Name" in each table to two separate
colunms for additional attention: "Type" and "Name".
- Rename "SFrame endianness" section to "SFrame magic number and
endianness"
- Update text around provisions for extending SFrame for future
ABIs/architectures. Make it clear by tagging all provisions with an
explicit index item "Provisions for future ABIs".
- Add a paragraph on sort order of SFrame FDEs.
- Add a statement for SFRAME_F_FRAME_POINTER flag.
- Add a statement to assert that SFrame version 1 is now obsolete and
should not be used.
libsframe/
* doc/sframe-spec.texi: Small improvements for readability.
aarch64: FP8 scale and convert - Implement minor improvements
Following feedback received shortly after the initial commit of the
aarch64 instructions for scaling and converting fp8 instructions, this
patch addresses the issues raised in the relevant feedback.
This includes the following changes:
* Standardize all FP8 qualifier-set names. This has resulted in the
renaming of QL_V2FP8B8H to QL_V2_HB_LOWER and, likewise, QL_V28H16B
to QL_V2_HB_FULL.
* Update `FP8_INSN' aarch64_opcode_table[] entries to reflect the new
standardized qualifier-set names mentioned above and, in the case of
the "fcvtn" entries, also add a leading 0 to their opcode values so
they are given as 8 hexadecimal digits in length to ensure
consistency in formatting relative to other entries in the table.
* Revise the added test-cases so that when checking operand fields in
the disassembled binaries, all bits for these fields get tested to
ensure they can be toggled on/off by the relevant operand arguments.
Flavio Cruz [Wed, 7 Feb 2024 06:53:40 +0000 (01:53 -0500)]
Hurd port: update interface to match upstream and fix warnings.
We have recently updated the interface for raising exceptions to use
long [1] and updated mach_port_t to be "unsigned int". This patches fixes
those problems and will help us port GDB to Hurd x86_64.
Jens Remus [Tue, 25 Jun 2024 15:25:55 +0000 (17:25 +0200)]
aarch64: Treat operand ADDR_SIMPLE as address with base register
The AArch64 instruction table (aarch64-tbl.h) defines the operand
ADDR_SIMPLE as "address with base register (no offset)". During assembly
it is correctly encoded as address with base register (addr.base_regno)
in parse_operands. In warn_unpredictable_ldst it is erroneously treated
as register number (reg.regno).
This resolves the assembler test case "Diagnostics Quality" to
erroneously fail when changing the union in struct aarch64_opnd_info
from union to struct for debugging purposes.
gas/
* config/tc-aarch64.c: Treat operand ADDR_SIMPLE as address with
base register.
Jens Remus [Tue, 25 Jun 2024 15:25:55 +0000 (17:25 +0200)]
aarch64: Treat operand Rt_IN_SYS_ALIASES as register number (PR 31919)
The AArch64 instruction table (aarch64-tbl.h) defines the operand
Rt_IN_SYS_ALIASES as register number. During assembly it is correctly
encoded as register number (reg.regno) in parse_operands. During
disassembly it is first correctly decoded as register number (reg.regno)
in aarch64_ext_regno called by aarch64_extract_operand, but then
erroneously treated as immediate value (imm.value) in
aarch64_print_operand.
This resolves the assembler test case "gas/aarch64/brbe-brb-inst" to
erroneously fail on s390. On AArch64 - being little-endian - the struct
aarch64_opnd_info union fields reg.regno and imm.value share their
least-significant bits. On s390 - being big-endian - they do not.
Andrew Burgess [Mon, 24 Jun 2024 11:22:26 +0000 (12:22 +0100)]
gdb/doc: the all-doc build target should build .... all docs
I noticed that the 'all-doc' build target doesn't build all the doc
formats, 'man' and 'html' are missing.
This commit updates 'all-doc' so that all formats are built.
This doesn't change the default 'all' target, which is the default
target used when building GDB itself, the 'all' target continues to
just build the 'info' docs.
There should be no difference in the actual generated output after
this commit, I'm just changing what gets built.
When building the dvi or pdf targets you'd get errors like this:
mkdir: cannot create directory ‘texi2dvi_tmpdir/gdb_dvi’: No such file or directory
mkdir: cannot create directory ‘texi2dvi_tmpdir/gdb_pdf’: No such file or directory
fixed by ensuring the directory is created before calling texi2dvi.
This patch adds missing contraints to FEAT_B16B16 sve2 instructions
bfclamp, bfmla and bfmls and add negative tests for all the bfloat
instructions.
The bfloat16-invalid.* testcases are renamed to bfloat16-1-invalid.*
to maintain consistency in the testsuite.
The bfloat16-1-invalid.* tests are modified so that "selected
processor does not support" is generated by the assembler, since
+b16b16 is not passed in the command line.
The bfloat16-2-invalid.* testcase includes the wrong operands
bfloat16 tests.
aarch64: Add extra tests for sve2p1 min max instructions.
This patch adds some extra tests for the sve2p1 "addqv, andqv, smaxqv,
sminqv, umaxqv, uminqv, eorqv, faddqv, fmaxnmqv, fmaxqv, fminnmqv and
fminqv" instructions.
The patch also adds couple of negative testcases, sve2p1-1-bad.d testcase
without "+sve2p1" option and sve2p1-2-bad.d testcase with wrong operands
for sve2p1 instructions.
arch64: Fix the wrong constraint used for sve2p1 instructions.
The current implementation for the following SVE2p1 instructions add a
constraint in aarch64_opcode_table[] array, so that these instruction
might be immediately preceded in program order by a MOVPRFX instruction.
As per the spec these instruction does not immediately preceded in
program order by a MOVPRFX instruction and to fix this issue, SVE2p1_INSNC
macro is replaced with SVE2p1_INSN macro for the entries of these
instructions in aarch64_opcode_table[] array.
List of instructions updated: addqv, andqv, smaxqv, sminqv, umaxqv, uminqv,
eorqv, faddqv, fmaxnmqv, fmaxqv, fminnmqv and fminqv.
This patch fixes encoding and syntax for sve2p1 instructions ld[1-4]q/st[1-4]q
as mentioned below, for the issues reported here.
https://sourceware.org/pipermail/binutils/2024-February/132408.html
1) Previously all the ld[1-4]q/st[1-4]q instructions are wrongly added as
predicated instructions and this issue is fixed in this patch by replacing
"SVE2p1_INSNC" with "SVE2p1_INSN" macro.
2) Wrong first operand in all the ld[1-4]q/st[1-4]q instructions is fixed
by replacing "SVE_Zt" with "SVE_ZtxN".
3) Wrong operand qualifiers in ld1q and st1q instructions are also fixed in
this patch.
4) In ld1q/st1q the index in the second argument is optional and if index
is xzr and is skipped in the assembly, the index field is ignored by the
disassembler.
Fixing above mentioned issues helps with following:
1) ld1q and st1q first register operand accepts enclosed figure braces.
2) ld2q, ld3q, ld4q, st2q, st3q, and st4q instructions accepts wrapping
sequence of vector registers.
For the instructions ld[2-4]q/st[2-4]q, tests for wrapping sequence of vector
registers are added along with short-form of operands for non-wrapping sequence.
I have added test using following logic:
ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #0, MUL VL] //raw insn encoding (all zeroes)
ld2q {Z31.Q, Z0.Q}, p0/Z, [x0, #0, MUL VL] // encoding of <Zt1>
ld2q {Z0.Q, Z1.Q}, p7/Z, [x0, #0, MUL VL] // encoding of <Pg>
ld2q {Z0.Q, Z1.Q}, p0/Z, [x30, #0, MUL VL] // encoding of <Xm>
ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #-16, MUL VL] // encoding of <imm> (low value)
ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #14, MUL VL] // encoding of <imm> (high value)
ld2q {Z31.Q, Z0.Q}, p7/Z, [x30, #-16, MUL VL] // encoding of all fields (all ones)
ld2q {Z30.Q, Z31.Q}, p1/Z, [x3, #-2, MUL VL] // random encoding.
For all the above form of instructions the hyphenated form is preferred for
disassembly if there are more than two registers in the list, and the register
numbers are monotonically increasing in increments of one.
This patch fixes the syntax of sve2p1 "extq" instruction by modifying the operands
count to 4. A new operand AARCH64_OPND_SVE_UIMM4 is defined to handle the 4th
argument an 4-bit unsigned immediate of extq instruction. The instruction encoding
is updated to use constraint C_SCAN_MOVPRFX, to enable "extq" instruction to immediately
precede in program order by a MOVPRFX instruction. Also removed the unused operand
AARCH64_OPND_SVE_Zm_imm4.
This issues was reported here:
https://sourceware.org/pipermail/binutils/2024-February/132408.html
This patch fixes the syntax of sve2p1 "dupq" instruction by modifying the way
2nd operand does the encoding and decoding using the [<imm>] value.
dupq makes use of already existing aarch64_ins_sve_index and aarch64_ext_sve_index
inserter and extractor functions. The definitions of aarch64_ins_sve_index_imm (inserter)
and aarch64_ext_sve_index_imm (extractor) is removed in this patch.
This issues was reported here:
https://sourceware.org/pipermail/binutils/2024-February/132408.html
gdb: use alternative for demangled name for non-demangeable linkage names
In case a DIE contains a linkage name which cannot be demangled and
a source language name (DW_AT_NAME) exists then we want to display this name
instead of the non-demangeable linkage name.
dwarf2_physname returns the linkage name in case the linkage name
cannot be demangled. Before this patch we always set the returned physname
as demangled name. This patch changes this by comparing the value
of physname with the linkage name. Now after this change in case it is equals
to the linkage name and if DW_AT_NAME exists then this is set as the demangled
name otherwise like before still linkage name is used.
For the reproducer, using the test source file added in this change:
"gdb/testsuite/gdb.dwarf2/dw2-wrong-mangled-name.c"
Here is an example of the DWARF where wrong linkage name is emitted by the
compiler for the "func_demangled_test" function:
Before this change for a function having both DIEs DW_AT_name and
DW_AT_LINKAGENAME but with the wrong linkage name info, the backtrace
command shows following:
(gdb) b func_demangled_test
(gdb) r
Breakpoint 1, 0x0000555555555131 in _FUNC_WRONG_MANGLED__ ()
(gdb) backtrace
\#0 0x0000555555555131 in _FUNC_WRONG_MANGLED__ ()
\#1 0x000055555555514a in main ()
After the change now GDB shows the name emitted by DW_AT_NAME:
(gdb) b func_demangled_test
(gdb) r
Breakpoint 1, 0x0000555555555131 in func_demangled_test ()
(gdb) backtrace
\#0 0x0000555555555131 in func_demangled_test ()
\#1 0x000055555555514a in main ()
Hui Li [Tue, 11 Jun 2024 11:21:26 +0000 (19:21 +0800)]
gdb: LoongArch: Add support for hardware breakpoint
LoongArch defines hardware watchpoint functions for fetch operations.
After the software configures the watchpoints for fetch, the processor
hardware will monitor the access addresses of the fetch operations and
trigger a watchpoint exception when the watchpoint setting conditions
are met.
Hardware watchpoints for fetch operations is used to implement hardware
breakpoint function on LoongArch. Refer to the following document for
hardware breakpoint.
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints
A simple test is as follows:
lihui@bogon:~$ cat test.c
#include <stdio.h>
int a = 0;
int main()
{
printf("start test\n");
a = 1;
printf("a = %d\n", a);
printf("end test\n");
return 0;
}
lihui@bogon:~$ gcc -g test.c -o test
without this patch:
lihui@bogon:~$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:5
5 printf("start test\n");
(gdb) hbreak 8
No hardware breakpoint support in the target.
with this patch:
lihui@bogon:~$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:5
5 printf("start test\n");
(gdb) hbreak 8
Hardware assisted breakpoint 2 at 0x1200006ec: file test.c, line 8.
(gdb) c
Continuing.
start test
a = 1
Breakpoint 2, main () at test.c:8
8 printf("end test\n");
(gdb) c
Continuing.
end test
[Inferior 1 (process 25378) exited normally]
Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Hui Li [Tue, 11 Jun 2024 11:21:25 +0000 (19:21 +0800)]
gdb: LoongArch: Add support for hardware watchpoint
LoongArch defines hardware watchpoint functions for load/store
operations. After the software configures the watchpoints for
load/store, the processor hardware will monitor the access
addresses of the load/store operations and trigger watchpoint
exception when the watchpoint setting conditions are met.
After this patch, watch/rwatch/awatch command are supported. Refer to the
following document for hardware watchpoint.
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints
A simple test is as follows:
lihui@bogon:~$ cat test.c
#include <stdio.h>
int a = 0;
int main()
{
printf("start test\n");
a = 1;
printf("a = %d\n", a);
printf("end test\n");
return 0;
}
lihui@bogon:~$ gcc -g test.c -o test
without this patch:
lihui@bogon:~$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:5
5 printf("start test\n");
(gdb) awatch a
Target does not support this type of hardware watchpoint.
...
with this patch:
lihui@bogon:~$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:5
5 printf("start test\n");
(gdb) awatch a
Hardware access (read/write) watchpoint 2: a
(gdb) c
Continuing.
start test
Hardware access (read/write) watchpoint 2: a
Old value = 0
New value = 1
main () at test.c:7
7 printf("a = %d\n", a);
(gdb) c
Continuing.
Hardware access (read/write) watchpoint 2: a
Value = 1
0x00000001200006e0 in main () at test.c:7
7 printf("a = %d\n", a);
(gdb) c
Continuing.
a = 1
end test
[Inferior 1 (process 22250) exited normally]
Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Hannes Domani [Mon, 24 Jun 2024 16:45:37 +0000 (18:45 +0200)]
Fix gdb.lookup_type for function-local types
Looking for a type defined locally in a function doesn't work
any more since the introduction of TYPE_DOMAIN:
```
(gdb) python print (gdb.lookup_type ('main()::Local'))
Python Exception <class 'gdb.error'>: No type named main()::Local.
Error occurred in Python: No type named main()::Local.
```
cp_search_static_and_baseclasses was simply missing a check for
SEARCH_TYPE_DOMAIN, now it works again:
```
(gdb) python print (gdb.lookup_type ('main()::Local'))
Local
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31922 Approved-By: Tom Tromey <tom@tromey.com>
Andrew Carlotti [Fri, 21 Jun 2024 18:32:31 +0000 (19:32 +0100)]
aarch64: Add SME FP8 multiplication instructions
This includes:
- FEAT_SME_F8F32 (+sme-f8f32)
- FEAT_SME_F8F16 (+sme-f8f16)
The FP16 addition/subtraction instructions originally added by
FEAT_SME_F16F16 haven't been added to Binutils yet. They are also
required to be enabled if FEAT_SME_F8F16 is present, so they are
included in this patch.
Andrew Carlotti [Fri, 21 Jun 2024 18:31:34 +0000 (19:31 +0100)]
aarch64: Add FP8 Neon and SVE multiplication instructions
This includes all the instructions under the following features:
- FEAT_FP8FMA (+fp8fma)
- FEAT_FP8DOT4 (+fp8dot4)
- FEAT_FP8DOT2 (+fp8dot2)
- FEAT_SSVE_FP8FMA (+ssve-fp8fma)
- FEAT_SSVE_FP8DOT4 (+ssve-fp8dot4)
- FEAT_SSVE_FP8DOT2 (+ssve-fp8dot2)
Tom Tromey [Wed, 5 Jun 2024 15:51:08 +0000 (09:51 -0600)]
Remove hashtab_obstack_allocate
I think that hashtabs should never be obstack-allocated. In the past
this was convenient sometimes, because any new data structure needed a
corresponding cleanup. However, with the switch to C++, resource
management has become much simpler; for example, a local variable can
simply be of type htab_up rather than hashtab_t, and the problem is
solved.
This patch removes hashtab_obstack_allocate to try to prevent this
anti-pattern from being used again.
Tom Tromey [Wed, 5 Jun 2024 15:38:53 +0000 (09:38 -0600)]
Don't obstack-allocate the call site hash table
The call site hash table is the last hash table using obstack
allocation. In one large (non-public) test case, these hash tables
take a substiantial amount of memory. Some of this memory is wasted
-- whenever the hash table is resized, the old table is not freed.
This patch fixes the problem by changing this hash table to be
heap-allocated. This means that resizing will no longer "leak"
memory.
Harmen Stoppels [Mon, 24 Jun 2024 15:00:14 +0000 (16:00 +0100)]
libdep plugin: fix bugs in parser and drop escaping
PR ld/31906
* libdep_plugin.c (str2vec): Fix bug where null byte was not copied on memmove during quote handling and escaping, causing repeat of the last character in the last argument.
Fix buffer overflow in **res when arguments were separated by `\t` instead of ` `.
Remove handling of the escape character `\`, as it made it impossible to specify paths containing `\`
-- the implementation merely dropped `\`, and was affected by the memmove bug, so this should not be breaking; just single and double quotes are sufficient to deal with white space and quote characters, there is no need for escaping.
Handle syntax errors on unterminated quotes.
Make the parser linear time instead of quadratic.
Introduces instructions for the SME2 lutv2 extension for AArch64. They
are documented in the following document:
* ARM DDI0602
For both luti4 instructions, we introduced an operand called
SME_Znx2_BIT_INDEX. We use the existing function parse_vector_reg_list
for parsing but modified that function so that it can accept operands
without qualifiers and rejects instructions that have operands with
qualifiers but are not supposed to have operands with qualifiers.
For disassembly, we modified print_register_list so that it could
accept register lists without qualifiers.
For one luti4 instruction, we introduced a SME_Zdnx4_STRIDED. It is
similar to SME_Ztx4_STRIDED and we could use existing code for parsing,
encoding, and disassembly.
For movt instruction, we introduced an operand called SME_ZT0_INDEX2_12.
This is a ZT0 register with a bit index encoded in [13:12]. It is
similar to SME_ZT0_INDEX.
We also introduced an iclass named sme_size_12_b so that we can encode
size bits [13:12] correctly when only 'b' is allowed as qualifier.
Martin Simmons [Mon, 24 Jun 2024 11:34:59 +0000 (12:34 +0100)]
Include needed unordered_map header
Compiling on FreeBSD 13.2 with the default clang version 14.0.5 and top level
configure options --with-python=/usr/local/bin/python3.9 gives this error:
CXX ada-exp.o
./../binutils-gdb/gdb/ada-exp.y:100:8: error: no template named 'unordered_map' in namespace 'std'
std::unordered_map<std::string, std::vector<ada_index_var_operation *>>
~~~~~^
1 error generated.
This change fixes it.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31918 Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Wed, 8 May 2024 18:12:57 +0000 (19:12 +0100)]
gdb/doc: fix parallel build of pdf and dvi files
When building with 'make -j20 -C gdb/doc all-doc' I often see problems
caused from trying to build some dvi files in parallel with some pdf
files. The problem files are: gdb.dvi and gdb.pdf; stabs.dvi and
stabs.pdf; and annotate.dvi and annotate.pdf.
The problem is that building these files create temporary files in the
local directory. There's already a race here that two make threads
might try to create these files at the same time.
But it gets worse, to avoid issues where a failed build could leave
these temporary files in a corrupted state, and so prevent the next
build from succeeding, the recipe for each of these files deletes all
the temporary files first, this obviously causes problems if some
other thread has already started the build and is relying on these
temporary files.
To work around this problem I propose we start using the --build and
--build-dir options for texi2dvi (which is the same tool used to
create the pdf files). These options were added in texinfo 4.9 which
was released in June 2007. We already require using a version of
texinfo after 4.9 (I tried to build with 4.13 and the doc build failed
as some of the texinfo constructs were not understood), so this patch
has not changed the minimum required version at all.
The --build flag allows the temporary files to be placed into a
sub-directory, and the --build-dir option allows us to control the
name of that sub-directory.
What we do is create a unique sub-directory for each target that
invokes texi2dvi, all of the unique sub-directories are created within
a single directory texi2dvi_tmpdir, and so after a complete doc build,
we are left with a build tree like this:
I've left out all the individual files that live within these
directories for simplicity.
To avoid corrupted temporary files preventing a future build to
complete, each recipe deletes its associated sub-directory from within
texi2dvi_tmpdir/ before it attempts a build, this ensures a fresh
start each time.
And the mostlyclean target deletes texi2dvi_tmpdir/ and all its
sub-directories, ensuring that everything is cleaned up.
For me, with this fix in place, I can now run 'make -j20 -C gdb/doc
all-doc' without seeing any build problems.
Andrew Burgess [Wed, 8 May 2024 17:55:18 +0000 (18:55 +0100)]
gdb/doc: fix parallel build of refcard related targets
There are two problems we encounter when trying to build the refcard
related target in parallel, i.e.:
$ make -j20 -C gdb/doc/ refcard.dvi refcard.ps refcard.pdf
These problems are:
(1) The refcard.dvi and refcard.pdf targets both try and generate the
tmp.sed and sedref.tex files. If two make threads end up trying
to create these files at the same time then the result is these
files become corrupted.
I've fixed this by creating a new rule that creates sedref.tex,
both refcard.dvi and refcard.pdf now depend on this, and make will
build sedref.tex just once. The tmp.sed file is now generated as
refcard.sed, this is generated and deleted as a temporary file
within the sedref.tex recipe.
(2) Having created sedref.tex the recipes for refcard.dvi and
refcard.pdf both run various LaTeX based tools with sedref.tex as
the input file. The problem with this is that these tools all
rely on creating temporary files calls sedref.*.
If the refcard.dvi and refcard.pdf rules run at the same time then
these temporary files clash and overwrite each other causing the
build to fail.
We already copy the result file in order to rename it, our input
file is sedref.tex which results in an output file named
sedref.dvi or sedref.pdf, but we actually want refcard.dvi or
refcard.pdf. So within the recipe for refcard.dvi I copy the
input file from sedref.tex to sedref_dvi.tex. Now all the temp
files are named sedref_dvi.* and the output is sedref_dvi.dvi, I
then rename this new output file to refcard.dvi.
I've done the same thing for refcard.pdf, but I copy the input
to sedref_pdf.tex.
In this way the temp files no longer clash, and both recipes can
safely run in parallel.
After this commit I was able to reliably build all of the refcard
targets in parallel. There should be no change in the final file.
Andrew Burgess [Thu, 30 May 2024 16:08:31 +0000 (17:08 +0100)]
gdb/doc: also look in srcdir when running TEXI2POD
In gdb/doc/Makefile.in the TEXI2POD variable is used to invoke
texi2pod.pl, which process the .texinfo files. This also handles the
'include' directives within the .texinfo files.
Like the texi2dvi and texi2pdf tools, texi2pod.pl handles the -I flag
to add search directories for resolving 'include' directives within
.texinfo files.
When GDB runs TEXI2POD we include gdb-cfg.texi, which then includes
GDBvn.texi.
When building from a git checkout the gdb-cfg.texi files and
GDBvn.texi files will be created in the build directory, which is
where texi2pod.pl is invoked, so the files will be found just fine.
However, for a GDB release we ship gdb-cfg.texi and GDBvn.texi in the
source tree, along with the generated manual (.1 and .5) files.
So when building a release, what normally happens is that we spot that
the .1 and .5 man files are up to date, and don't run the recipe to
regenerate these files.
However, if we deliberately touch the *.texinfo files in a release
source tree, and then try to rebuild the man files, we'll get an error
like this:
make: Entering directory '/tmp/release-build/build/gdb/doc'
TEXI2POD gdb.1
cannot find GDBvn.texi at ../../../gdb-16.0.50.20240529/gdb/doc/../../etc/texi2pod.pl line 251, <GEN0> line 16.
make: *** [Makefile:664: gdb.1] Error 2
make: Leaving directory '/tmp/release-build/build/gdb/doc'
The problem is that texi2pod.pl doesn't know to look in the source
tree for the GDBvn.texi file.
If we compare this to the recipe for creating (for example) gdb.dvi,
which uses texi2dvi, this recipe adds '-I $(srcdir)' to the texi2dvi
command line, which allows texi2dvi to find GDBvn.texi in the source
tree.
In this commit I add a similar -I option to the texi2pod.pl command
line. After this, given a GDB release, it is possible to edit (or
just touch) the gdb.texinfo file and rebuild the man pages, the
GDBvn.texi will be picked up from the source tree.
If however a dependency for GDBvn.texi is changed in a release tree
then GDBvn.texi will be regenerated into the build directory and this
will be picked up in preference to the GDBvn.texi in the source tree,
just as you would want.
Andrew Burgess [Thu, 30 May 2024 13:41:48 +0000 (14:41 +0100)]
gdb/doc: allow for version.subst in the source tree
In a git checkout of the source code we don't have a version.subst
file in the gdb/doc directory. When building the GDB docs the
version.subst file is generated on demand (we have a recipe for that).
However, in a release tar file we do include a copy of the
version.subst file in the source tree, as a result the version.subst
recipe will not be run.
If, in a release build, we force the running of any recipe that
depends on version.subst then we run into a problem. For example,
slightly confusingly, if we 'touch gdb/doc/version.subst' within the
unpacked source tree of a release, then 'make -C gdb/doc GDBvn.texi'
in the build tree, we'll see:
make: Entering directory '/tmp/build/build/gdb/doc'
GEN GDBvn.texi
sed: can't read version.subst: No such file or directory
make: Leaving directory '/tmp/build/build/gdb/doc'
The problem is that every reference to version.subst in GDB's Makefile
assumes that the version.subst file will always be in the build
directory.
Handily version.subst is always the first dependency in every recipe
that uses that file. As such we can replace references to
version.subst with $<, make will expand this to the location where the
dependency was found.
In the case of the man page generation, the reference to version.subst
is hidden inside POD2MAN. It seemed a little confusing adding a use
of $< within POD2MAN, so I've moved the use into the recipe, which I
think is clearer.
I've also added comments for the two rules that I've modified to
explain our use of $<.
After this change it is possible to rebuild the man pages even when
version.subst is located in the source tree.
Andrew Burgess [Thu, 6 Jun 2024 17:29:23 +0000 (18:29 +0100)]
gdb/doc: merge rules for building .1 and .5 man pages
We have two rules, one each for building the .1 and .5 man pages. The
only actual difference is that one rule passes --section=1 and the
other passes --section=5 (see the definitions of POD2MAN1 and POD2MAN5
respectively.
I figure by using the suffix from the target of the rule we can
combine these two rules into one.
I use:
$(subst .,,$(suffix $@))
This gets the suffix from the target, either '.1' or '.5', and the
'subst' removes the '.' leaving '1' or '5'.
Now that I'm not using a static pattern rule for building the man
pages, the advice in the 'make' documentation is to not use $*, so
I've moved away from that to instead use $(basename $@), e.g. for
'gdbinit.5' this gives 'gdbinit', which is what we want.
There should be no difference in what is created after this change.
Andrew Burgess [Fri, 10 May 2024 13:41:03 +0000 (14:41 +0100)]
gdb/doc: don't try to copy GDBvn.texi from the source tree
The build recipe for gdb.dvi and gdb.pdf contains instructions for
copying the GDBvn.texi file from the source tree into the build
directory if the GDBvn.texi file doesn't already exist in the build
directory.
The gdb.dvi and gdb.pdf targets also have a dependency on GDBvn.texi,
and we have a recipe for building GDBvn.texi.
What's happening here is this:
- In a git checkout of the source tree there is no GDBvn.texi in the
source tree, the GDBvn.texi dependency will trigger a rebuild of
GDBvn.texi, which is then used to build gdb.dvi and/or gdb.pdf.
- In a release tar file we do include a copy of GDBvn.texi. This
file will appear to be up to date, and so no copy of GDBvn.texi is
created within the build directory. Now when building gdb.dvi
and/or gdb.pdf we copy (or symlink) the version of GDBvn.texi from
the source tree into the build directory.
However, copying GDBvn.texi from the source directory is completely
unnecessary. The gdb.dvi/gdb.pdf recipes both invoke texi2dvi and
pass '-I $(srcdir)' as an argument, this means that texi2dvi will look
in the $(srcdir) to find included files, including GDBvn.texi.
As such I believe we can remove the code that copies GDBvn.texi from
the source tree into the build tree.
I've tested with a release build; creating a release with:
./src-release gdb
Then in an empty directory, unpacking the resulting .tar file,
creating a parallel build directory and doing the usual configure,
make, and 'make install'.
Having done this I can then 'touch gdb/doc/*.texinfo' in the unpacked
source tree, and do 'make -C gdb/doc pdf dvi' to rebuild all the pdf
and dvi files, this works fine without having to either build or copy
GDBvn.texi into the build directory.
$ ./gdbserver/gdbserver --once :54321 ~/empty
Process /srv/aburgess/empty created; pid = 31406
Listening on port 54321
Remote debugging from host ::1, port 39488
../../src/gdbserver/regcache.cc:272: A problem internal to GDBserver has been detected.
Unknown register st0 requested
Aborted (core dumped)
When I tried to reproduce this regression on my local i386 VM the
issue would not reproduce.
I eventually tracked the problem down to x86_linux_tdesc_for_tid in
gdb/nat/x86-linux-tdesc.c. In this function we have this line:
The problem is that on my VM the PTRACE_GETREGSET feature is
supported, while on sourceware's buildbot machine this feature is not
supported.
I did a quick search and it seems like the 'xsave' feature in
/proc/cpuinfo might be the indicator for whether PTRACE_GETREGSET is
supported or not, and indeed my machine has the 'xsave' feature while
the sourceware machine does not.
The point of divergence then is this ptrace call, on my machine the
call succeeds and we extract the xcr0 value from the iov vector, while
on the sourceware machine the ptrace call fails and we use a default
xcr0 value of 0.
This xcr0 value is then passed to i386_linux_read_description at the
end of x86_linux_tdesc_for_tid.
In gdb/arch/i386-linux-tdesc.c we find i386_linux_read_description
which does some caching but calls i386_create_target_description to
actually create the target descriptions when needed. The xcr0 value
is masked to only the bits that are interesting, but given a value of
0 we'll just pass 0 through to i386_create_target_description.
In gdb/arch/i386.c we find i386_create_target_description which checks
the xcr0 bits and builds the target description. What we can see is
that if no bits are set in the xcr0 value then no features will be
added to the created target description. This featureless target
description is then transmitted back to GDB, which is then rejected
due to lack of essential core registers.
So, how did things work prior to the above commit series? There are
three places of interest, on the GDB side there is
x86_linux_nat_target::read_description and
i386_linux_core_read_description. Then on the gdbserver side there is
x86_linux_read_description.
All of these locations have a call to i386_linux_read_description
followed by a check if the return value was nullptr. If we do get
back nullptr then we perform another call to
i386_linux_read_description with a default xcr0 value.
Looking in i386_linux_read_description we see a specific check for
xcr0 being 0 in which case we return nullptr.
And so, prior to the above series, if xcr0 was 0 due to
PTRACE_GETREGSET being unavailable we'd use a default xcr0 value.
After the above series this is no longer the case, the 'xcr0 == 0'
check has been removed from i386_linux_read_description and the
calling code is streamlined to remove the use of default xcr0 values.
The fix I propose here is to setup the default xcr0 value at the point
where we find that PTRACE_GETREGSET is unavailable. The default value
used is X86_XSTATE_SSE_MASK. This is the default used in
x86_linux_nat_target::read_description (for GDB) and in
x86_linux_read_description (for gdbserver). The above commit series
already fixed i386_linux_core_read_description to ensure that the
correct default xcr0 value was used, this case is a little special in
that it uses different defaults depending on which sections are
present in the core file, so that case always needed to be handled
differently.
The choice of X86_XSTATE_SSE_MASK corresponds to the default used for
i386 before the above series was committed. This mask includes the
X87 and SSE bits only, neither of these bits are checked for on amd64
or x32, so this default doesn't change the behaviour on these targets.
By setting the default xcr0 value at this early stage we ensure that
the cached xcr0 value on the gdbserver side is correct. This is
critical as this cached xcr0 value is passed through to the in process
agent (IPA). If we leave the cached xcr0 value as 0 and apply the
defaults later in the series we also have to encode the knowledge of
the default into the IPA, this just means we have the default encoded
in multiple locations, which seems like a bad idea. The approach used
in this patch means the default is present in just one location.
This commit should fix the i386 regressions seen on the sourceware
buildbot.
In addition to the fix in nat/x86-linux-tdesc.c I've also fixed the
layout of the declaration of x86_linux_tdesc_for_tid in the header
file.
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
Simon Marchi [Thu, 25 Apr 2024 17:42:42 +0000 (13:42 -0400)]
gdb/testsuite: analyze-racy-logs.py cleanup
- Add type annotations
- Use a raw string in one spot (where we call re.sub), to avoid an
"invalid escape sequence" warning.
- Remove unused "os" import.
Pedro Alves [Fri, 21 Jun 2024 13:14:08 +0000 (15:14 +0200)]
[gdb/tdep] Fix gdb.base/watchpoint-running.exp on {arm,ppc64le}-linux
When running test-case gdb.base/watchpoint-running on ppc64le-linux (and
similar on arm-linux), we get:
...
(gdb) watch global_var^M
warning: Error when detecting the debug register interface. \
Debug registers will be unavailable.^M
Watchpoint 2: global_var^M
(gdb) FAIL: $exp: all-stop: hardware: watch global_var
FAIL: $exp: all-stop: hardware: watchpoint hit (timeout)
...
The problem is that ppc_linux_dreg_interface::detect fails to detect the
hardware watchpoint interface, because the calls to ptrace return with errno
set to ESRCH.
This is a feature of ptrace: if a call is done while the tracee is not
ptrace-stopped, it returns ESRCH.
Indeed, in the test-case "watch global_var" is executed while the inferior is
running, and that triggers the first call to ppc_linux_dreg_interface::detect.
And because the detection failure is cached, subsequent attempts at setting
hardware watchpoints will also fail, even if the tracee is ptrace-stopped.
The way to fix this is to make sure that ppc_linux_dreg_interface::detect is
called when we know that the thread is ptrace-stopped, which in the current
setup is best addressed by using target-specific post_attach and
post_startup_inferior overrides. However, as we can see in
aarch64_linux_nat_target, that causes code duplication.
Fix this by:
- defining a new target hook low_init_process, called from
linux_init_ptrace_procfs, which is called from both
linux_nat_target::post_attach and linux_nat_target::post_startup_inferior,
- adding implementations for ppc_linux_nat_target and arm_linux_nat_target
that detect the hardware watchpoint interface,
- replacing the aarch64_linux_nat_target implementations of post_attach and
post_startup_inferior with a low_init_process implementation.
Tested on ppc64le-linux, arm-linux, aarch64-linux and x86_64-linux.
Co-Authored-By: Tom de Vries <tdevries@suse.de> Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/31834
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31834
PR tdep/31705
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31705
Jan Beulich [Fri, 21 Jun 2024 12:39:52 +0000 (14:39 +0200)]
x86: optimize left-shift-by-1
These can be replaced by adds when acting on a register operand.
While for the scalar forms there's no gain in encoding size, ADD
generally has higher throughput than SHL. EFLAGS set by ADD are a
superset of those set by SHL (AF in particular is undefined there).
For the SIMD cases the transformation also reduced code size, by
eliminating the 1-byte immediate from the resulting encoding. Note
that this transformation is not applied by gcc13 (according to my
observations), so would - as of now - even improve compiler generated
code.
Jan Beulich [Fri, 21 Jun 2024 06:36:03 +0000 (08:36 +0200)]
x86/APX: fix disassembly of byte register operands
Like for REX/REX2, EVEX-prefixed insns access the low bytes of all
registers; %ah...%bh are inaccessible. Reflect this correctly in output,
by leveraging REX machinery we already have to this effect.
Jan Beulich [Fri, 21 Jun 2024 06:35:23 +0000 (08:35 +0200)]
x86: %riz, %rip, and %eip don't require REX
While these can't be used as register operands, they can be used for
memory operand addressing. Such uses do not prevent conversion: The
RegRex64 checks in check_Rex_required() for base and index registers
were simply wrong. They specifically also aren't needed for byte
registers, as those won't pass i386_index_check() anyway.
Jan Beulich [Fri, 21 Jun 2024 06:33:57 +0000 (08:33 +0200)]
x86: don't suppress errors when optimizing
Blindly ignoring any mnemonic suffix can't be quite right: Bad suffix /
operand combinations still want flagging. Simply avoid optimizing in
such situations.
Jan Beulich [Fri, 21 Jun 2024 06:32:53 +0000 (08:32 +0200)]
gas: terminate buffer SB in do_repeat()
PR gas/31903
While elsewhere having realized that "one" doesn't point to a nul-
terminated string, it somehow didn't occur to me that the pre-existing
strstr() could have been wrong, and hence I blindly added a new use of
the function. Add the (already prior to 1e3c814459d8 ["gas: extend \+
support to .rept"]) missing call to sb_terminate(), leveraging that to
simplify the other two places where the lack of nul termination was
previously worked around.
Tom Tromey [Wed, 27 Mar 2024 16:43:57 +0000 (10:43 -0600)]
Handle "info symbol" in Rust language mode
When I changed the Rust parser to handle 128-bit ints, this
inadvertently broke some other gdb commands. For example, "info
symbol 0xffffffffffffffff" now fails, because the resulting value is
128 bits, but this is rejected by extract_integer.
This patch fixes the problem by changing extract_integer to allow
over-long integers as long as the high bytes are either 0, or (for
signed types) 0xff.
Regression tested on x86-64 Fedora 38.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31565 Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom de Vries [Thu, 20 Jun 2024 14:54:47 +0000 (16:54 +0200)]
[gdb/testsuite] Fix gdb.python/py-format-address.exp on arm
When running test-case gdb.python/py-format-address.exp on arm-linux, I get:
...
(gdb) python print("Got: " + gdb.format_address(0x103dd))^M
Got: 0x103dd <main at py-format-address.c:30>^M
(gdb) FAIL: $exp: symbol_filename=on: gdb.format_address, \
result should have an offset
...
What is expected here is:
...
Got: 0x103dd <main+1 at py-format-address.c:30>^M
...
Main starts at main_addr:
...
(gdb) print /x &main^M
$1 = 0x103dc^M
...
and we obtained next_addr 0x103dd by adding 1 to it:
...
set next_addr [format 0x%x [expr $main_addr + 1]]
...
Adding 1 to $main_addr results in an address for a thumb function starting at
address 0x103dc, which is incorrect because main is an arm function (because
I'm running with target board unix/-marm).
At some point during the call to format_addr, arm_addr_bits_remove removes
the thumb bit, which causes the +1 offset to be dropped, causing the FAIL.
Fix this by using the address of the breakpoint on main, provided it's not at
the very start of main.
Tom de Vries [Thu, 20 Jun 2024 13:37:48 +0000 (15:37 +0200)]
[gdb/testsuite] Fix duplicates in gdb.opt/inline-cmds.exp
With test-case gdb.opt/inline-cmds.exp on ppc64le-linux, I ran into:
...
PASS: gdb.opt/inline-cmds.exp: finish from marker
...
PASS: gdb.opt/inline-cmds.exp: finish from marker
DUPLICATE: gdb.opt/inline-cmds.exp: finish from marker
...
Tom de Vries [Thu, 20 Jun 2024 13:37:48 +0000 (15:37 +0200)]
[gdb/testsuite] Fix duplicates in gdb.fortran/huge.exp
With test-case gdb.fortran/huge.exp, on a system without fortran compiler, I
ran into a number of duplicates:
...
Running /home/vries/gdb/src/gdb/testsuite/gdb.fortran/huge.exp ...
gdb compile failed, default_target_compile: Can't find gfortran.
UNTESTED: gdb.fortran/huge.exp: huge.exp
...
gdb compile failed, default_target_compile: Can't find gfortran.
UNTESTED: gdb.fortran/huge.exp: huge.exp
DUPLICATE: gdb.fortran/huge.exp: huge.exp
UNSUPPORTED: gdb.fortran/huge.exp: require failed: expr $compilation_succeeded
...
Fix this by wrapping the compile in a with_test_prefix, getting us instead:
...
gdb compile failed, default_target_compile: Can't find gfortran.
UNTESTED: gdb.fortran/huge.exp: CRASH_GDB=2097152: huge.exp
...
gdb compile failed, default_target_compile: Can't find gfortran.
UNTESTED: gdb.fortran/huge.exp: CRASH_GDB=16: huge.exp
UNSUPPORTED: gdb.fortran/huge.exp: require failed: expr $compilation_succeeded
...
projects / thirdparty / binutils-gdb.git / log
