| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
While the patch already committed for pr30793 prevents the asan error,
there is a problem: Now the last element of bundle_words never gets
written. That's very likely wrong, or KVXMAXBUNDLEWORDS is too big.
So this patch rearranges things a little to support writing of all of
bundle_words and does the parallel bit checking only when filling
bundle_words. In the normal case, kvx_reassemble_bundle will see
bundle_words[word_count-1] with the parallel bit clear and all other
words having it set. In the error case where all words in
bundle_words have the parallel bit set, kvx_reassemble_bundle will be
passed a wordcount of KVXMAXBUNDLEWORDS + 1. I've also made
kvx_reassemble_bundle return true for success rather than zero, and
removed the unnecessary check for zero wordcount.
PR 30793
* kvx-dis.c (kvx_reassemble_bundle): Return bool, true on success.
Fail if wordcount is too large. Don't check for wordcount zero.
Don't check kvx_has_parallel_bit.
(print_insn_kvx): Rewrite code reading bundle_words as a for loop.
Don't stop reading at KVXMAXBUNDLEWORDS - 1.
(decode_prologue_epilogue_bundle): Similarly.
|
|
This bug points out that if one uses -var-set-visualizer with "None"
-- to disable a pretty-printer for a varobj -- then
-var-evaluate-expression will still use pretty-printing.
This is a combination of bugs. First, setting the visualizer does not
update the display text; and second, computing the display text should
use "raw" when Python is available but no visualizer is desired.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11738
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
variable_default_display has a single caller now, so remove it.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
varobj_set_display_format takes an enum and exhaustively switches on
the values -- but also has a default. This default case is dead code.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
A user noticed that, while a pretty-printer can return Python strings
from its "children" method, this does not really work for MI. I
tracked this down to my_value_of_variable calling into
c_value_of_variable, which specially handles arrays and structures --
not using the actual contents of the string.
Now, this part of MI seems bad to me, but rather than change that,
this applies the fix to only dynamic varobjs, which is the only
scenario where a string like this can really be returned.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18282
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
With test-case gdb.ada/same_enum.exp and target board dwarf4-gdb-index we run
into:
...
(gdb) print red^M
No definition of "red" in current context.^M
(gdb) FAIL: gdb.ada/same_enum.exp: print red
...
[ This is a regression since commit 844a72efbce ("Simplify gdb_index writing"),
so this is broken in gdb 12 and 13. ]
The easiest way to see what's going wrong is with readelf. We have in section
.gdb_index:
...
[7194] pck__red:
2 [static, variable]
3 [static, variable]
...
which points to the CUs 2 and 3 in the CU list (shown using "2" and "3"), but
should be pointing to the TUs 2 and 3 in the TU list (shown using "T2" and
"T3").
Fix this by removing the counter / types_counter distinction in
write_gdbindex, such that we get the expected:
...
[7194] pck__red:
T2 [static, variable]
T3 [static, variable]
...
[ While reading write_gdbindex I noticed a few oddities related to dwz
handling, I've filed PR30829 about this. ]
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30827
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30827
|
|
When running test-case gdb.ada/local-enum.exp with target board debug-types, I
run into:
...
(gdb) print v1(three)^M
No name 'three' in enumeration type 'local__e1'^M
(gdb) FAIL: gdb.ada/local-enum.exp: print v1 element
...
The array V1 is of type A1 which is an array with index type E1, containing
"three" as enumerator:
...
type E1 is (one, two, three);
type A1 is array (E1) of Integer;
V1 : A1 := (0, 1, 2);
...
There's also a type E2 that contains three as enumerator:
...
type E2 is (three, four, five);
...
When doing "print v1(three)", it's the job of ada_resolve_enum to resolve
"three" to type E1 rather than type E2.
When using target board debug-types, the enums E1 and E2 are replicated in the
.debug_types section, and consequently in ada_resolve_enum the type
equivalence check using a pointer comparison fails:
...
for (int i = 0; i < syms.size (); ++i)
{
/* We already know the name matches, so we're just looking for
an element of the correct enum type. */
if (ada_check_typedef (syms[i].symbol->type ()) == context_type)
return i;
}
...
Fix this by also trying a structural comparison using
ada_identical_enum_types_p.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR ada/29335
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29335
|
|
When running test-case gdb.ada/arr_acc_idx_w_gap.exp with target board
cc-with-dwz, I run into:
...
(gdb) print enum_with_gaps'enum_rep(lit3)^M
'Enum_Rep requires argument to have same type as enum^M
(gdb) FAIL: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep
...
With target_board unix, we have instead:
...
(gdb) print enum_with_gaps'enum_rep(lit3)^M
$16 = 13^M
(gdb) PASS: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep
...
Conversely, when I add this test to the test-case:
...
gdb_test "print enum_with_gaps'enum_rep(lit3)" " = 13" \
"enum_rep"
+ gdb_test "print enum_subrange'enum_rep(lit3)" " = 13" \
+ "other enum_rep"
...
the extra test passes with target board cc-with-dwz, but fails with target
board unix.
The problem is here in remove_extra_symbols:
...
if (symbols_are_identical_enums (syms))
syms.resize (1);
...
where one of the two identical enums is picked before the enum_rep handling
can resolve lit3 to one of the two.
Fix this by moving the code to ada_resolve_variable.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR ada/30726
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30726
|
|
block_find_symbol takes a callback function, but only two callbacks
are ever passed to it -- and they are similar enough that it seems
cleaner to just have block_find_symbol do the work itself. Also,
block_find_symbol can take a lookup_name_info as an argument,
following the general idea of pushing the construction of these
objects as high in the call chain as feasible.
Regression tested on x86-64 Fedora 38.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
Following the commit f818c32ba459 ("gdb/mi: fix ^running record with
multiple MI interpreters"), I thought it would make sense to make
current_token a field of mi_interp. This variable contains the token of
the currently handled MI command, like the 222 in:
222-exec-continue
I didn't find any bug related to that, it's just a "that seems nicer"
cleanup, since the current token is a fundamentally per-interp thing.
mi_execute_command needs a check similar to what we already have in
mi_cmd_gdb_exit: when invoked from Python's gdb.execute_mi, the current
interpreter is not an mi_interp. When using the Python gdb.execute_mi
function, there is no such concept of token, so we can just skip that.
There should be no user-visible change.
Change-Id: Ib52b3c0cba4b7c9d805b432c809692a86e4945ad
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Change-Id: Ib841a77a9494648aee9f970141424363664ff6e8
|
|
|
|
Subtraction for labels that require static relocation
usually generates ADD32/64 and SUB32/64.
If subsy of BFD_RELOC_32/64 and PC in same segment,
and disable relax or PC at start of subsy or enable
relax but not in SEC_CODE, we generate 32/64_PCREL
to replace a pair of ADD32/64 and SUB32/64.
|
|
The vendor operands should be named starting with `X', and preferably the
second letter (or multiple following letters) is enough to differentiate
them from other vendors.
Therefore, added letter `t' after `X' for t-head operands, to differentiate
from future different vendor's operands.
bfd/
* elfxx-riscv.c (riscv_supported_vendor_x_ext): Removed the vendor
document link since it should already be recorded in the
gas/doc/c-riscv.texi.
gas/
* config/tc-riscv.c (validate_riscv_insn): Added `t' after `X' for
t-head operands. Minor updates for indents and comments.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Minor updates.
opcodes/
* riscv-dis.c (print_insn_args): Added `t' after `X' for t-head
operands. Minor updates for indents and comments.
* riscv-opc.c (riscv_opcode): Likewise.
|
|
The std::basic_string template type is only specified for
instantiations using character types. Newer (LLVM) libc++
implementations no longer allow non-character integer types
to be used.
gold/
* output.cc: Include <uchar.h>.
(Output_section::add_merge_input_section): Use char16_t and
char32_t for 2- and 4-byte entry size, respectively.
* stringpool.cc: Include <uchar.h>.
(Stringpool_template): Explicitly instantiate for char16_t,
char32_t instead of uint16_t, uint32_t.
* merge.cc (Output_merge_string): Likewise.
|
|
|
|
Commit 3bab069c29b3 carelessly allowed "string" to be released from
the notes obstack twice, with the second call to obstack_free
releasing memory for a fixup that just happened to be the same size as
the original string. The fixup then of course was overwritten.
This patch fixes that problem, and another that could occur on an
error path.
PR 30828
* stabs.c (s_stab_generic): Don't free string twice. Don't
blow away entire notes obstack on a missing string.
|
|
Test-case gdb.ada/same_enum.exp is supposed to be a regression test for this
bit of code in remove_extra_symbols:
...
if (symbols_are_identical_enums (syms))
syms.resize (1);
...
The test-case does "print red" and expects one of these two choices to be
picked by remove_extra_symbols:
...
type Color is (Black, Red, Green, Blue, White);
type RGB_Color is new Color range Red .. Blue;
...
but because only the type Color is used:
...
FC : Color := Red;
SC : Color := Green;
...
the RGB_Color type is eliminated from the debug info, and consequently
remove_extra_symbols has no effect for the test-case.
In other words, we have:
...
(gdb) ptype Color ^M
type = (black, red, green, blue, white)^M
(gdb) ptype RGB_Color^M
No definition of "rgb_color" in current context.^M
...
Fix this by changing the type of SC to RGB_Color, and add prints of the two
types to check that they're both available.
With the test-case fixed, if we disable the bit of code in
remove_extra_symbols we get:
...
(gdb) print red^M
Multiple matches for red^M
[0] cancel^M
[1] pck.color'(pck.red) (enumeral)^M
[2] pck.rgb_colorB'(pck.red) (enumeral)^M
> FAIL: gdb.ada/same_enum.exp: print red (timeout)
...
in other words, the test-case now properly functions as a regression test.
Tested on x86_64-linux.
|
|
When running test-case gdb.python/py-symbol.exp with target board
cc-with-dwz-m, we run into:
...
(gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
4^M
(gdb) FAIL: gdb.python/py-symbol.exp: \
print (len (gdb.lookup_static_symbols ('rr')))
...
while with target board unix we have instead:
...
(gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
2^M
(gdb) PASS: gdb.python/py-symbol.exp: \
print (len (gdb.lookup_static_symbols ('rr')))
...
The problem is that the loop in gdbpy_lookup_static_symbols loops over compunits
representing both CUs and PUs:
...
for (compunit_symtab *cust : objfile->compunits ())
...
When doing a lookup on a PU, the user link is followed until we end up at a CU,
and the lookup is done in that CU.
In other words, when doing a lookup in the loop for a PU we duplicate the
lookup for a CU that is already handled by the loop.
Fix this by skipping PUs in the loop in gdb.lookup_static_symbols.
Tested on x86_64-linux.
PR symtab/25261
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25261
|
|
When running test-case gdb.base/setshow.exp with target board cc-with-dwz I
run into:
...
(gdb) info line 1^M
Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M
Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M
(gdb) FAIL: gdb.base/setshow.exp: test_setshow_annotate: annotation_level 1
...
while the expected output is:
...
Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.
��setshow.c:1:0:beg:0x400527
...
The second line of the expected output is missing due to the first line of the
expected output being repeated, so the problem is that the "Line 1" line is
printed twice.
This happens because the PU imported by the CU reuses the filetab of the CU,
and both the CU and PU are visited by iterate_over_some_symtabs.
Fix this by skipping PUs in iterate_over_some_symtabs.
Tested on x86_64-linux, target boards unix, cc-with-dwz and cc-with-dwz-m.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30797
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30797
|
|
Without this, a simulator build breaks when building from a tarball
made by "./src-release.sh -b sim", when building e.g. bfd and
libsframe. See also previous similar commits for GDB_SUPPORT_DIRS.
The libctf library does not needed to be built, but building
libsframe requires libctf/swap.h, with no dependencies on built or
configured contents. Do as for the single gdb files and include
explicitly only that file.
|
|
|
|
In gprofng testing, we need a tempory gprofng installation to resolve run-time
dependencies on libraries (libgprofng, libopcodes, libbfd, etc).
We set LD_LIBRARY_PATH and GPROFNG_SYSCONFDIR to find our libraries and
configuration file. These variables must be set for all gprofng tests.
Tested on aarch64 and x86_64 with and without --enable-shared and --target=<>.
gprofng/ChangeLog
2023-08-31 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/30808
* testsuite/config/default.exp: Make a temporary install dir.
Set LD_LIBRARY_PATH, GPROFNG_SYSCONFDIR.
* testsuite/lib/Makefile.skel: Move LD_LIBRARY_PATH and
GPROFNG_SYSCONFDIR setting in testsuite/config/default.exp.
|
|
When a GDB stub is run via "target remote |", it sometimes produces
extra output that ends up mixed with GDB's own output. For example,
QEMU's built-in GDB stub responds to the vKill packet by printing
nios2-elf-qemu-system: QEMU: Terminated via GDBstub
before exiting.
This patch fixes the regexp in gdb.base/hook-stop.exp to allow such
messages between GDB's "continuing" and "Inferior killed" messages.
Reviewed-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
These testcases assume host==build or that the remote host has a Posix
shell to run commands in. Don't try to run them if that's not the case.
Reviewed-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This patch fixes some testcases that formerly had patterns with
hardwired "/" pathname separators in them, which broke when testing on
(remote) Windows host.
Reviewed-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Some embedded targets don't have full support for argc/argv. argv
may print as "0x0" or as an address with a symbol name following.
This causes problems for the regexps in the style.exp line-wrapping
tests that assume it always prints as an ordinary address in backtrace
output.
This patch generalizes the regexps to handle these additional forms
and reworks some of the line-wrapping tests to account for the argv
address string being shorter or longer than a regular address.
Reviewed-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This changes the no-op pretty printers -- used by DAP -- to handle
array- and string-like objects known by the gdb core. Two new tests
are added, one for Ada and one for Rust.
|
|
gdb's language code may know how to display values specially. For
example, the Rust code understands that &str is a string-like type, or
Ada knows how to handle unconstrained arrays. This knowledge is
exposed via val-print, and via varobj -- but currently not via DAP.
This patch adds some support code to let DAP also handle these cases,
though in a somewhat more generic way.
Type.is_array_like and Value.to_array are added to make Python aware
of the cases where gdb knows that a structure type is really
"array-like".
Type.is_string_like is added to make Python aware of cases where gdb's
language code knows that a type is string-like.
Unlike Value.string, these cases are handled by the type's language,
rather than the current language.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Right now, if a program uses multiple languages, DAP value formatting
will always use the language of the innermost frame. However, it is
better to use the variable's defining frame instead. This patch does
this by selecting the frame first.
This also fixes a possibly latent bug in the "stepOut" command --
"finish" is sensitive to the selected frame, but the DAP code may
already select other frames when convenient. The DAP stepOut request
only works on the newest frame, so be sure to select it before
invoking "finish".
|
|
This adds the type::is_array_like method and the value_to_array
function.
The former can be used to see whether a given type is known to be
"array-like". This is the currently the case for certain
compiler-generated structure types; in particular both the Ada and
Rust compilers do this.
|
|
Ada has a few complexities when it comes to array handling. Currently
these are all handled in Ada-specific code -- but unfortunately that
means they aren't really accessible to Python.
This patch changes the Python code to defer to Ada when given an Ada
array. In order to make this work, one spot in ada-lang.c had to be
updated to set the "GNAT-specific" flag on an array type.
The test case for this will come in a later patch.
|
|
This adds a new enum constant, TYPE_SPECIFIC_RUST_STUFF, and changes
the DWARF reader to set this on Rust types. This will be used as a
flag in a later patch.
Note that the size of the type_specific_field bitfield had to be
increased. I checked that this did not impact the size of main_type.
|
|
This patch exposes rust_slice_type_p and introduces
rust_slice_to_array, in preparation for subsequent patches that will
need these.
|
|
This moves rust_language::lookup_symbol_nonlocal to rust-lang.c.
There's no need to have it in rust-lang.h and moving it lets us avoid
adding new includes in a later patch.
|
|
If the length of a register name was greater than 15,
print_spaces was called with a negative number, which
prints random data from the heap instead of the requested
number of spaces.
This could happen if a target-description file was used
to specify additional long-named registers.
Fix is simple - don't ask for fewer than 1 space (since
we still want column separation).
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
An upstream bug report points out this bug: if the user switches from
one Ada executable to another without "kill"ing the inferior, then the
"start" command will fail.
What happens here is that the Ada "main" name is found in a constant
string in the executable. But, if the inferior is running, then the
process_stratum target reads from the inferior memory.
This patch fixes the problem by changing the main name code to set
trust-readonly-sections, causing the target stack to read from the
executable instead.
I looked briefly at changing GNAT to emit DW_AT_main_subprogram
instead, but this looks to be pretty involved.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25811
|
|
A user noticed that gdb would crash when showing a backtrace.
Investigation showed this to be a crash in the DWARF reader when
handling a "pragma export" symbol. The bug here is that earlier code
decides to eliminate the symbol, but the export code tries to add it
anyway -- but to a NULL list.
|
|
PR 30684
* readelf.c (extra_sym_info): New variable. (section_name_valid): Also check for filedata being NULL. (section_name_print): Delete. (section_index_real): New function. Returns true if the given section index references a real section. (print_symbol): Rename to print_sumbol_name. (printable_section_name): Use a rotating array of static buffers for the return string. (printable_section_name_from_index): Merge code from dump_relocations and get_symbol_index_type into here. (long_option_values): Add OPTION_NO_EXTRA_SYM_INFO. (options): Add "extra-sym-info" and "no-extra-sym-info". (usage): Mention new options. (parse_args): Parse new options. (get_symbol_index_type): Delete. (print_dynamic_symbol_size): Rename to print_symbol_size. (print_dynamic_symbol): Rename to print_symbol. (print_symbol_table_heading): New function. (process_symbol_table): Use new function.
* doc/binutils.texi: Document the new option.
* NEWS: Mention the new feature.
|
|
There's no need to have almost identical code twice. Do away with
M_VMSGEU and instead simply use an unused (for these macros) field to
tell apart both variants.
|
|
This commit implements support for 'Svadu' extension. Because it does not
add any instructions or CSRs (but adds bits to existing CSRs), this commit
only adds extension name support and implication to the 'Zicsr' extension.
This is based on the "Hardware Updating of PTE A/D Bits (Svadu)"
specification, version 1.0-rc1 (Frozen):
<https://github.com/riscv/riscv-svadu/releases/tag/v1.0-rc1>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_implicit_subsets): Add implication from
'Svadu' to 'Zicsr'. (riscv_supported_std_s_ext) Add 'Svadu'.
|
|
gas/ChangeLog:
* testsuite/gas/riscv/csr.s: Fix typo. mhcounteren is superseded
by minstretcfg, not mcyclecfg.
|
|
This commit adds now stable and approved 'Smcntrpmf' extension defined by
the RISC-V Cycle and Instret Privilege Mode Filtering specification.
Note that, because mcyclecfg and minstretcfg CSRs conflict with the
privileged specification version 1.9.1, CSRs for this extension are only
enabled on the privileged specification version 1.10 or later.
By checking the base privileged specification, we no longer need to change
the design of base CSR handling.
This is based on the specification version v1.0_rc1 (Frozen):
<https://github.com/riscv/riscv-smcntrpmf/commit/32b752c40d59c1b5e95de83399c1f54be6669163>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_implicit_subsets): Add implication rule from
the new 'Smcntrpmf' extension. (riscv_supported_std_s_ext): Add
'Smcntrpmf' to the supported S extension list.
gas/ChangeLog:
* config/tc-riscv.c (enum riscv_csr_class): Add new CSR classes
CSR_CLASS_SMCNTRPMF and CSR_CLASS_SMCNTRPMF_32.
(riscv_csr_address): Add handling for new CSR classes.
* testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs. Move
"mscounteren" and "mhcounteren" CSRs and note that they are now
aliases.
* testsuite/gas/riscv/csr-dw-regnums.d: Reflect the change.
* testsuite/gas/riscv/csr.s: Add new CSRs. Move "mscounteren"
and "mhcounteren" CSRs and note that they are now reused for
the 'Smcntrpmf' extension.
* testsuite/gas/riscv/csr-version-1p9p1.d: Reflect the changes of
csr.s.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
include/ChangeLog:
* opcode/riscv-opc.h: Add new CSRs noting that this extension is
incompatible with the privileged specification version 1.9.1.
Move "mscounteren" and "mhcounteren" CSRs, make them aliases and
reuse the CSR numbers from the 'Smcntrpmf' extension.
(CSR_MSCOUNTEREN, CSR_MHCOUNTEREN) Remove as "mscounteren" and
"mhcounteren" are now aliases and new CSR macros are used instead.
(CSR_MCYCLECFG, CSR_MINSTRETCFG, CSR_MCYCLECFGH, CSR_MINSTRETCFGH):
New CSR macros.
|
|
According to the ratified privileged specification (version 20211203),
it says:
> The hypervisor extension depends on an "I" base integer ISA with 32 x
> registers (RV32I or RV64I), not RV32E, which has only 16 x registers.
Also in the latest draft, it also prohibits RV64E with the 'H' extension.
This commit prohibits the combination of 'E' and 'H' extensions.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_parse_check_conflicts): Prohibit 'E' and
'H' combinations.
gas/ChangeLog:
* testsuite/gas/riscv/march-fail-rv32eh.d: New failure test to
make sure that RV32E + 'H' is prohibited.
* testsuite/gas/riscv/march-fail-rv32eh.l: Likewise.
|
|
|
|
Error messages such as "conflicting CPU architectures 10/16" are not
very to understand, so this patch replaces the numbers with the
description they actually mean:
"conflicting CPU architectures ARM v7E-M vs Pre v4"
2023-09-01 Christophe Lyon <christophe.lyon@linaro.org>
bfd/
* elf32-arm.c (tag_cpu_arch_combine): Add name_table parameter and
use it.
(elf32_arm_merge_eabi_attributes): Update call to
tag_cpu_arch_combine.
ld/
* testsuite/ld-arm/attr-merge-9.out: Update expected error
message.
* testsuite/ld-arm/attr-merge-arch-2.d: Likewise.
|
|
When running test-case gdb.base/add-symbol-file-attach.exp with target board
unix/-m32, we run into:
...
(gdb) attach 3955^M
Attaching to process 3955^M
Load new symbol table from "add-symbol-file-attach"? (y or n) y^M
Reading symbols from add-symbol-file-attach/add-symbol-file-attach...^M
Reading symbols from /lib/libm.so.6...^M
Reading symbols from /usr/lib/debug/lib/libm-2.31.so-i386.debug...^M
Reading symbols from /lib/libc.so.6...^M
Reading symbols from /usr/lib/debug/lib/libc-2.31.so-i386.debug...^M
Reading symbols from /lib/ld-linux.so.2...^M
Reading symbols from /usr/lib/debug/lib/ld-2.31.so-i386.debug...^M
0xf7f53549 in __kernel_vsyscall ()^M
(gdb) FAIL: gdb.base/add-symbol-file-attach.exp: attach
...
The test fails because this regexp is used:
...
-re ".*in \[_A-Za-z0-9\]*pause.*$gdb_prompt $" {
...
The regexp attempts to detect that the exec is somewhere in pause ():
...
int
main (int argc, char **argv)
{
pause ();
return 0;
}
...
but when the exec is blocked in pause, the backtrace is:
...
(gdb) bt
#0 0xf7fd2549 in __kernel_vsyscall ()
#1 0xf7d84966 in __libc_pause () at ../sysdeps/unix/sysv/linux/pause.c:29
#2 0x0804844c in main (argc=1, argv=0xffffce84)
at /data/vries/gdb/src/gdb/testsuite/gdb.base/add-symbol-file-attach.c:26
...
We could simply extend the regexp to also match __kernel_vsyscall, but the
more fundamental problem is that the test is racy.
The attach can happen before the exec is blocked in pause (), somewhere in the
dynamic linker resolving the call to pause, in main or even earlier.
Note that for the test-case to be effective, the exec is not required to be in
pause (). I added a "while (1);" loop at the start of main, reverted the
patch fixing the corresponding PR and reproduced the problem it's supposed to
detect.
Fix this by simply matching the "Reading symbols from" line, similar to what
an earlier test is doing.
While we're at it, rewrite the earlier test to also use the -wrap idiom.
Tested on x86_64-linux.
|
|
|
|
|
|
On a machine with AVX512 support (AMD EPYC 9634), I see these failures:
$ make check TESTS="gdb.arch/i386-avx512.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
...
FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[16] after writing ZMM regs
FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[17] after writing ZMM regs
FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[18] after writing ZMM regs
...
The problem can be reduced to:
(gdb) print $zmm16.v8_int64
$1 = {0, 0, 0, 0, 0, 0, 0, 0}
(gdb) print $zmm16.v8_int64 = {11,22,33,44,55,66,77,88}
$2 = {11, 22, 33, 44, 55, 66, 77, 88}
(gdb) print $zmm16.v8_int64
$3 = {11, 22, 33, 44, 55, 66, 77, 88}
(gdb) step
5 ++x;
(gdb) print $zmm16.v8_int64
$4 = {11, 22, 77, 88, 0, 0, 0, 0}
Writing to the local regcache in GDB works fine, but the writeback to
gdbserver (which happens when resuming / stepping) doesn't work (the
code being stepped doesn't touch AVX registers, so we don't expect the
value of zmm16 to change when stepping).
The problem is on the gdbserver side, the zmmh and ymmh portions of the
zmm register are not memcpied at the right place in the xsave buffer. Fix
that. Note now how the two modified memcpy calls match the memcmp calls
just above them.
With this patch, gdb.arch/i386-avx512.exp passes completely for me.
Change-Id: I22c417e0f5e88d4bc635a0f08f8817a031c76433
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30818
|
