Tom de Vries [Tue, 22 Oct 2024 06:53:51 +0000 (08:53 +0200)]
[gdb] Handle EINTR in run_under_shell
When building gdb with -O2 -fsanitize=thread and running test-case
gdb.base/bg-exec-sigint-bp-cond.exp, I run into:
...
(gdb) c&^M
Continuing.^M
(gdb) Quit^M
(gdb) quit_count=1
^M
Breakpoint 2, foo () at bg-exec-sigint-bp-cond.c:23^M
23 return 0;^M
FAIL: $exp: no force memory write: \
SIGINT does not interrupt background execution
...
What happens is that:
- the breakpoint hits
- while evaluating the condition of the breakpoint,
$_shell("kill -INT <pid-of-gdb>") is called, handled by run_under_shell
- in run_under_shell, a vfork is issued
- in the vfork child, execl executes the kill command
- in the vfork parent, waitpid is called to wait for the result of the kill
command
- waitpid returns -1 with errno set to EINTR
- run_under_shell doesn't check the result of waitpid, and returns the
value of local variable status. Since waitpid returned -1, status was
not assigned a value, so it's uninitialized, and happens to be
non-zero
- the breakpoint condition evaluates to true, because
$_shell("kill -INT <pid-of-gdb>") != 0
- the breakpoint triggers a stop, which the test-case doesn't expect.
Fix this by using gdb::handle_eintr to call waitpid in run_under_shell.
Also handle the case that waitpid returns an error other than EINTR, using
perror_with_name.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR gdb/30695
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30695
Lulu Cai [Thu, 17 Oct 2024 07:08:47 +0000 (15:08 +0800)]
LoongArch: Force relocation for every reference to the global offset table
Local absolute symbols are resolved at assembly stage and the symbol
value is placed in the relocation addend. But non-zero addend will
cause an assertion failure during linking.
Forces emission of relocations to defer resolution of local abs symbols
until link time.
bfd/
* elfnn-loongarch.c (loongarch_elf_relax_section): Determine
absolute symbols in advance to avoid ld crash.
gas/
* config/tc-loongarch.c (loongarch_force_relocation): New
function to force relocation.
* config/tc-loongarch.h (TC_FORCE_RELOCATION): New macros
to force relocation.
(loongarch_force_relocation): Function declaration.
* testsuite/gas/loongarch/localpic.d: New test.
* testsuite/gas/loongarch/localpic.s: New test.
The first operator:
...
$ c++filt _ZN3foomlERS_
foo::operator*(foo&)
...
matches address 0x410250 which is defined here in the CU in the exec:
...
<1><10f1>: Abbrev Number: 13 (DW_TAG_subprogram)
<10f2> DW_AT_specification: <alt 0x93>
<10f6> DW_AT_decl_line : 72
<10f7> DW_AT_decl_column : 7
<10f7> DW_AT_object_pointer: <0x1106>
<10f9> DW_AT_low_pc : 0x410250
<1101> DW_AT_high_pc : 32
<1102> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<1104> DW_AT_call_all_calls: 1
...
and declared here in the PU in the .dwz file:
...
<2><93>: Abbrev Number: 20 (DW_TAG_subprogram)
<94> DW_AT_external : 1
<94> DW_AT_name : operator*
<98> DW_AT_decl_file : 2
<98> DW_AT_decl_line : 10
<99> DW_AT_decl_column : 9
<9a> DW_AT_linkage_name: _ZN3foomlERS_
<9e> DW_AT_accessibility: 1 (public)
<9e> DW_AT_declaration : 1
<9e> DW_AT_object_pointer: <0xa2>
...
When creating a new symbol for the operator, the DW_AT_decl_file attribute is
looked up, and found to be 2.
The 2 is supposed to be mapped using the PU, which has this file name table:
...
The File Name Table (offset 0x78, lines 3, columns 2):
Entry Dir Name
0 0 <dwz>
1 1 stddef.h
2 2 cplusfuncs.cc
...
Instead, it's mapped using the CU, which has this file name table:
...
The File Name Table (offset 0x34, lines 3, columns 2):
Entry Dir Name
0 1 cplusfuncs.cc
1 1 cplusfuncs.cc
2 2 stddef.h
...
This is PR symtab/30814. There's a similar PR for lto, PR symtab/25771, where
the same problem happens for two CUs.
Fix this by using the correct file name table.
Add a dwarf assembly test-case for PR25771.
Tested on aarch64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25771
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30814
As gdbreplay communicates with GDB, it outputs all the remote
protocol communication it reads from the remotelogfile to stderr.
This patch disables this behavior by default but adds the new
--debug-logging option which turns printing the packets
to stderr on again.
The motivation for this change is to make it possible to use
gdbreplay with TCL tests. Printing the whole remotelog file out
seems to overflow the expect cache wich causes gdbreplay to not
to get the packet its expects and results in going out of sync
with GDB. Other motivation is making communication between GDB
and gdbreplay faster as printing bigger remotelogfile takes
considerable amount of time.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Mon, 21 Oct 2024 13:07:02 +0000 (15:07 +0200)]
[gdb/contrib] Add spellcheck.sh --check
Add a new option --check to gdb/contrib/spellcheck.sh, to do the spell
check and bail out ASAP with an exit code of 1 if misspelled words were
found, or 0 otherwise.
Andrew Burgess [Sun, 6 Oct 2024 19:32:16 +0000 (20:32 +0100)]
gdb/guile: add get-basic-type
A question was asked on stackoverflow.com about the guile function
get-basic-type[1] which is mentioned in the docs along with an example
of its use.
The problem is, the function was apparently never actually added to
GDB. But it turns out that it's pretty easy to implement, so lets add
it now. Better late than never.
The implementation mirrors the Python get_basic_type function. I've
added a test which is a copy of the documentation example.
One issue is that the docs suggest that the type will be returned as
just "int", however, I'm not sure what this actually means. It makes
more sense that the function return a gdb:type object which would be
represented as "#<gdb:type int>", so I've updated the docs to show
this output.
Tom de Vries [Mon, 21 Oct 2024 06:04:07 +0000 (08:04 +0200)]
[gdb/build, c++20] Fix more deprecated implicit capture of this
When building gdb with -std=c++20 I run into:
...
gdb/dwarf2/cooked-index.c: In lambda function:
gdb/dwarf2/cooked-index.c:471:47: error: implicit capture of ‘this’ via \
‘[=]’ is deprecated in C++20 [-Werror=deprecated]
471 | gdb::thread_pool::g_thread_pool->post_task ([=] ()
| ^
gdb/dwarf2/cooked-index.c:471:47: note: add explicit ‘this’ or ‘*this’ capture
...
Fix this and two more spots by removing the capture default, and explicitly
listing all captures.
Andrew Burgess [Thu, 17 Oct 2024 10:56:47 +0000 (11:56 +0100)]
gdb: fix 'maint info inline-frames' after 'stepi'
There is an invalid assumption within 'maint info inline-frames' which
triggers an assert:
(gdb) stepi
0x000000000040119d 18 printf ("Hello World\n");
(gdb) maintenance info inline-frames
../../src/gdb/inline-frame.c:554: internal-error: maintenance_info_inline_frames: Assertion `it != inline_states.end ()' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
... etc ...
If you check out infrun.c and look in handle_signal_stop for the call
to skip_inline_frames then you'll find a rather large comment that
explains that we don't always compute the inline state information for
performance reasons. So the assertion is not valid.
I've updated the code so that if there is cached information we use
that, but if there is not then we just create our own information for
the current $pc of the current thread.
This means that, if there is cached information, GDB still correctly
shows which frame the inferior is in (it might not be in the inner
most frame).
If there is no cached information we will always display the inferior
as being in the inner most frame, but that's OK, because if
skip_inline_frames has not been called then GDB will have told the
user they are in the inner most frame, so everything lines up.
I've extended the test to check 'maint info inline-frames' after a
stepi which would previously have triggered the assertion.
Tom Tromey [Sat, 24 Aug 2024 14:37:15 +0000 (08:37 -0600)]
Capture the current directory and debug directory in DWARF reader
This changes the DWARF reader to capture the current working directory
and the current debug directory. This avoids races when the DWARF
reader is working in the background.
Tom Tromey [Sat, 24 Aug 2024 00:46:25 +0000 (18:46 -0600)]
Add cwd paramter to openp
This patch adds a cwd paramter to openp, so that the current directory
can be passed in by the caller. This is useful when background
threads call this function -- they can then avoid using the global and
thus avoid races with the user using "cd".
Tom Tromey [Sun, 29 Sep 2024 18:22:07 +0000 (12:22 -0600)]
Pass current directory to gdb_abspath
Currently, gdb_abspath uses the current_directory global. However,
background threads need to capture this global to avoid races with the
user using "cd".
This patch changes this function to accept a cwd parameter, in
prepration for this.
While trying to substitute some std::vector type A in the code with a
gdb::array_view:
...
- using A = std::vector<T>
+ using A = gdb::array_view<T>
....
I ran into the problem that the code was using A::iterator while
gdb::array_view doesn't define such a type.
Fix this by:
- adding types gdb::array_view::iterator and gdb::array_view::const_iterator,
- using them in gdb::array_view::(c)begin and gdb::array_view::(c)end, as is
usual, and
- using them explicitly in a unit test.
Tom de Vries [Sat, 19 Oct 2024 06:01:59 +0000 (08:01 +0200)]
[gdb/guile, c++20] Work around Werror=volatile in libguile.h
When building gdb with -std=c++20, I run into:
...
In file included from /usr/include/guile/2.0/libguile/__scm.h:479,
from /usr/include/guile/2.0/libguile.h:31,
from /data/vries/gdb/src/gdb/guile/guile-internal.h:30,
from /data/vries/gdb/src/gdb/guile/guile.c:37:
/usr/include/guile/2.0/libguile/gc.h: In function ‘scm_unused_struct* \
scm_cell(scm_t_bits, scm_t_bits)’:
/usr/include/guile/2.0/libguile/tags.h:98:63: error: using value of \
assignment with ‘volatile’-qualified left operand is deprecated \
[-Werror=volatile]
98 | # define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x))
| ~~~~~~~~~~~~~~~~~~~^~~~~
...
This was reported upstream [1].
Work around this by using SCM_DEBUG_TYPING_STRICTNESS == 0 instead of the
default SCM_DEBUG_TYPING_STRICTNESS == 1.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR guile/30767
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30767
Tom de Vries [Sat, 19 Oct 2024 05:57:21 +0000 (07:57 +0200)]
[gdb/symtab] Skip local variables in cooked index
Consider test-case gdb.dwarf2/local-var.exp. The corresponding source
contains a function with a local variable:
...
program test
logical :: local_var
local_var = .TRUE.
end
...
Currently, the local variable shows up in the cooked index:
...
[2] ((cooked_index_entry *) 0xfffec40063b0)
name: local_var
canonical: local_var
qualified: local_var
DWARF tag: DW_TAG_variable
flags: 0x2 [IS_STATIC]
DIE offset: 0xa3
parent: ((cooked_index_entry *) 0xfffec4006380) [test]
...
making the cooked index larger than necessary.
Fix this by skipping it in cooked_indexer::index_dies.
Ruud van der Pas [Wed, 16 Oct 2024 16:12:06 +0000 (16:12 +0000)]
gprofng: fix a memory leak in the mxv-pthreads example
Fix a bug where the main program does not free the rows of
the matrix. The memory for thread_data_arguments is also
not released. In function check_results, the memory for the
marker vector is not released.
The usage of the verbose veriable has been extended to
print more messages.
gprofng/ChangeLog
2024-10-16 Ruud van der Pas <ruud.vanderpas@oracle.com>
PR 32273
PR 32274
* mxv-pthreads/src/main.c: add calls to free() to
release the memory allocated for array A and vector
marker. Improve the usage of the verbose variable.
* mxv-pthreads/src/manage_data.c: add a diagnostic
printf statement.
* mxv-pthreads/src/mydefs.h: adapt prototype to
match the changes in main.c.
Tom de Vries [Thu, 17 Oct 2024 22:29:50 +0000 (00:29 +0200)]
[gdb] Handle bad alloc handling in gdb_bfd_open
Say we simulate a bad alloc in gdb_bfd_init_data:
...
+ {
+ static bool throw_bad_alloc = true;
+ if (throw_bad_alloc)
+ {
+ throw_bad_alloc = false;
+
+ va_list dummy;
+ throw gdb_quit_bad_alloc (gdb_exception_quit ("bad alloc", dummy));
+ }
+ }
gdata = new gdb_bfd_data (abfd, st);
...
That works out fine for doing "file a.out" once:
...
$ gdb -q -batch -ex "file a.out"
bad alloc
$
...
but doing so twice get us:
...
$ gdb -q -batch -ex "file a.out" -ex "file a.out"
bad alloc
The problem is in gdb_bfd_open, where we insert abfd into gdb_bfd_cache:
...
if (bfd_sharing)
{
slot = htab_find_slot_with_hash (gdb_bfd_cache, &search, hash, INSERT);
gdb_assert (!*slot);
*slot = abfd;
}
gdb_bfd_init_data (abfd, &st);
...
while the bad alloc means that gdb_bfd_init_data is interrupted and abfd is
not properly initialized.
Fix this by reversing the order, inserting abfd into gdb_bfd_cache only after
a successful call to gdb_bfd_init_data, such that we get:
...
$ gdb -q -batch -ex "file a.out" -ex "file a.out"
bad alloc
$
...
This is due do gcc PR110799 [1], generating wrong code with
-fhoist-adjacent-loads, and causing a false positive for
-fsanitize=threads.
Work around the gcc PR by forcing -fno-hoist-adjacent-loads for gcc <= 13
and -fsanitize=threads.
Tested in that same configuration on x86_64-linux. Remaining ThreadSanitizer
problems are the ones reported in PR31626 (gdb.rust/dwindex.exp) and
PR32247 (gdb.trace/basic-libipa.exp).
Tom de Vries [Thu, 17 Oct 2024 22:15:57 +0000 (00:15 +0200)]
[gdb/symtab] Fix qualified name for cooked index dump
While looking at the cooked index entry for local variable l4 of function test
in test-case gdb.fortran/logical.exp:
...
$ gdb -q -batch outputs/gdb.fortran/logical/logical \
-ex "maint print objfiles"
...
[9] ((cooked_index_entry *) 0x7fc6e0003010)
name: l4
canonical: l4
qualified: l4
DWARF tag: DW_TAG_variable
flags: 0x2 [IS_STATIC]
DIE offset: 0x17c
parent: ((cooked_index_entry *) 0x7fc6e0002f20) [test]
...
I noticed that while the entry does have a parent, that's not reflected in the
qualified name.
This makes it harder to write test-cases that check the parent of a cooked
index entry.
This is due to the implementation of full_name, which skips printing
parents if the language does not specify an appropriate separator.
Fix this by using "::" as default separator, getting us instead:
...
[9] ((cooked_index_entry *) 0x7f94ec0040c0)
name: l4
canonical: l4
qualified: test::l4
DWARF tag: DW_TAG_variable
flags: 0x2 [IS_STATIC]
DIE offset: 0x17c
parent: ((cooked_index_entry *) 0x7f94ec003fd0) [test]
...
Michael Matz [Thu, 17 Oct 2024 15:42:40 +0000 (17:42 +0200)]
Fix for -Wstringop-overflow false positive
the way the overflow check was written wasn't understood by some
GCC versions and produced false positives for the memset call being
called potentially with object sizes that are larger than half
address-space.
Michael Matz [Tue, 15 Oct 2024 16:47:15 +0000 (18:47 +0200)]
PR32260: Improve error handling on string merging
if the input sections are near the max supported size (4G)
we might fail to enlarge the hash table. The error handling
for this case didn't quite work. When this happens we can
gracefully fall back to just not deduplicate this section
(and continue with further mergable sections). We were mixing
that with the case of not being able to even allocate a small
structure (in which case we can as well error out completely),
this disentables both cases.
bfd/
PR ld/32260
* merge.c (sec_merge_maybe_resize): Check overflow in ultimate
target type.
(record_section): Return three-state, use new state when unable
to enlarge hash table.
(_bfd_merge_sections): Remove current section from merging
consideration when hashtable can't be enlarged.
Tom de Vries [Thu, 17 Oct 2024 13:54:08 +0000 (15:54 +0200)]
[gdb/testsuite] Fix gdb.ada/fixed_points.exp for gcc < 10
When running test-case gdb.ada/fixed_points.exp with system gcc 7, I run
into:
...
(gdb) PASS: gdb.ada/fixed_points.exp: scenario=all: print fp4_var / 1
get_compiler_info: gcc-7-5-0
p Float(Another_Fixed) = Float(Another_Delta * 5)^M
No definition of "another_delta" in current context.^M
(gdb) FAIL: gdb.ada/fixed_points.exp: scenario=all: value of another_fixed
...
This is a regression since commit 1411185a57e ("Introduce and use
gnat_version_compare"), which did:
...
# This failed before GCC 10.
- if {$scenario == "all" && [test_compiler_info {gcc-10-*}]} {
+ if {$scenario == "all" && [gnat_version_compare < 10]} {
gdb_test "p Float(Another_Fixed) = Float(Another_Delta * 5)" "true" \
"value of another_fixed"
}
...
Fix this by using gnat_version_compare >= 10 instead.
Lulu Cai [Mon, 30 Sep 2024 08:08:59 +0000 (16:08 +0800)]
LoongArch: Check PC-relative relocations for shared libraries
Building shared libraries should not be allowed for PC-relative
relocations against external symbols.
Currently LoongArch has no corresponding checks and silently
generates wrong shared libraries.
However, In the first version of the medium cmodel, pcalau12i+jirl was
used for function calls, in which case PC-relative relocations were
allowed.
Alan Modra [Tue, 15 Oct 2024 22:00:07 +0000 (08:30 +1030)]
Assertion fail at peicode.h:607
This is the assertion that vars->string_ptr < vars->end_string_ptr,
ie. when it fails we've overflowed the string buffer area. Caused by
allocating space for import_name but writing symbol_name, and they can
be different.
Alan Modra [Thu, 10 Oct 2024 00:13:16 +0000 (10:43 +1030)]
Add noxfail option to run_dump_test
The noxfail option is useful in situations like pr23658-1e which
fails on all microblaze ELF targets except microblaze-linux. This was
possible to handle by writing a small proc and use that as an xfail
predicate, or painstakingly listing all microblaze ELF targets, but
this is simpler. The patch also fixes some other FAILs and XPASSes of
the pr23658 tests.
Alan Modra [Sun, 13 Oct 2024 04:41:59 +0000 (15:11 +1030)]
PR32266, segv when linking libclang_rt.asan-powerpc64.so
Change the mmap support added with commit 9ba56acee518 to always mmap
memory with PROT_READ | PROT_WRITE. Prior to that commit most file
contents were read into a buffer allocated with bfd_alloc or
bfd_malloc and thus the memory was read/write. Even after that commit
any section contents with relocations must be read/write to apply the
relocs. Making them all read/write is not a major change, and it
should not introduce any measurable linker slowdown for contents that
are not modified. More importantly, it removes a BFD behaviour
difference that only triggers when large files are involved.
PR 32266
PR 32109
* libbfd.c (bfd_mmap_local): Remove prot param. Always mmap
with PROT_READ | PROT_WRITE. Adjust all calls.
(_bfd_mmap_temporary): Rename from _bfd_mmap_readonly_temporary.
(_bfd_munmap_temporary): Rename from _bfd_munmap_readonly_temporary.
_bfd_mmap_persistent): Rename from _bfd_mmap_readonly_persistent.
(_bfd_generic_get_section_contents): Use PROT_READ | PROT_WRITE
regardless of relocs.
* libbfd-in.h: Update decls to suit. Make non-USE_MMAP variants
static inline functions.
* elflink.c: Update all uses of _bfd_mmap functions.
* elf.c: Likewise.
(bfd_elf_get_str_section): Revert commit 656f8fbaae.
* libbfd.h: Regenerate.
Liwei Xu [Wed, 16 Oct 2024 02:25:35 +0000 (10:25 +0800)]
Support Intel AVX10.2 convert instructions
In this patch, we will support AVX10.2 convert instructions. All
of them are new instruction forms.
Among all the instructions, vcvtbiasph2[b,h]f8[,s] needs extra care.
Since Operand 2 could indicate memory size, we do not need suffix
under ATTmode. However, we could not fold all three templates but only
XMM/YMM since the dst operand size are the same for them. Also, a new
iterator <cvt8> is added to reduce redundancy.
Tom Tromey [Thu, 26 Sep 2024 14:48:03 +0000 (08:48 -0600)]
Introduce and use gnat_version_compare
While testing a modified GNAT, I found that this test in
fun_renaming.exp was returning 0 for GCC 13:
if {[test_compiler_info {gcc-6*}]}
This patch introduces a new, more robust way to check the GNAT
compiler version, and changes the gda.ada tests to use it. A small
update to version_compare was also needed.
Note that, in its current form, this new code won't really interact
well with non-GCC compilers (specifically gnat-llvm). This doesn't
seem like a major issue at this point, though, because gnat-llvm
doesn't properly emit debuginfo yet, and when it does, more changes
will be needed in these tests anyway.
mengqinggang [Thu, 10 Oct 2024 08:23:30 +0000 (16:23 +0800)]
LoongArch: Add more relaxation support for call36
Add relaxation support for call36 that jump to PLT entry.
Add relaxation support for call36 with IFUNC symbol.
Add relaxation support for call36 that jump to undefweak symbol.
For undefweak symbol, it can always be relaxed if it have no PLT entry.
Because we set the address of undefweak symbol without PLT entry to PC
like relocate_section.
A recent commit, "16a6f7d2ee3 gdb: avoid breakpoint::clear_locations
calls in update_breakpoint_locations", started checking if GDB correctly
relocates a breakpoint from inferior 1's declaration of the function
"bar" to inferior 2's declaration.
Unfortunately, inferior 2 never calls bar in its regular execution, and
because of that, clang would optimize that whole function away, making
it so there is no location for the breakpoint to be relocated to.
This commit changes the .c file so that the function is not optimized
away and the test fully passes with clang. It is important to actually
call bar instead of using __attribute__((used)) because the latter
causes the breakpoint locations to be inverted, 3.1 belongs to inferior
2 and 3.2 belongs to inferior 1, which will cause an unrelated failure.
Jan Beulich [Mon, 14 Oct 2024 12:38:02 +0000 (14:38 +0200)]
x86: also template-expand trailing mnemonic part
So far template expansion was limited to fields other than the insn
mnemonic. In order to be able to use <fop> also for AVX10.2 we want the
trailing mnemonic part to also be expanded. Split out the respective
piece of code into a helper function, which is then invoked twice.
Guinevere Larsen [Mon, 14 Oct 2024 11:58:29 +0000 (08:58 -0300)]
gdb: make frame_unwind_try_unwinder return bool
Before this commit, the function frame_unwind_try_unwinder would return
an int, where 1 meant the unwinder works, and 0 it doesn't. This is just
a boolean with extra steps, so this commit updates the function to
return bool instead.
The enum BFD_RELOC_[32/64] was mistakenly used in the macro instead
of the relocation in fixp. This can cause the second relocation
of a pair to be deleted when -mthin-add-sub is enabled. Apply the
correct macro to fix this.
Andrew Burgess [Fri, 11 Oct 2024 08:31:51 +0000 (09:31 +0100)]
Revert "gdbserver: pass osabi to GDB in target description"
This reverts commit 98bcde5e268ea7cd54186c5f2c27c65103218fc3. This
commit was causing build problems on at least sparc, ppc, and s390,
though I suspect some other targets might be impacted too.
Jan Beulich [Fri, 11 Oct 2024 06:19:34 +0000 (08:19 +0200)]
bfd/ELF: restrict file alignment for object files
While for executables properly aligning sections within the file can be
quite relevant, the same is of pretty little importance for relocatable
object files. Avoid passing "true" into
_bfd_elf_assign_file_position_for_section() when dealing with object
files, but compensate minimally by applying log_file_align in such
cases as a cap to the alignment put in place.
In disassembler part, for vnni instructions, we extended previous
VEX part using %XE in disassembler to promote them to EVEX by reusing
the original VEX table. For vmpsadbw, we will also use %XE. However,
it is hard to reuse the VEX table, so we are using new ones.
In assmbler part, we put the vnni table entries with previous vnni
instructions since they are just promotion from AVX-VNNI-INT{8,16}.
Since we will prefer VEX encoding, we need to use the different table
order in template <vnni>, which prefers EVEX due to earlier introduction
for AVX512_VNNI than AVX_VNNI. This means a new <vnni>. For vdpphps
and vmpsadbw, we put them at the end of the table, with future AVX10.2
instructions.
Nit: I will remove the arch requirement for avx_vnni_int{8,16} in
evex-promote testcases after AVX10.2 implies AVX-VNNI-INT{8,16}.
Andrew Burgess [Fri, 4 Oct 2024 18:30:04 +0000 (19:30 +0100)]
gdbserver: pass osabi to GDB in target description
On a Windows machine I built gdbserver, configured for the target
'x86_64-w64-mingw32', then on a GNU/Linux machine I built GDB with
support for all target (--enable-targets=all).
On the Windows machine I start gdbserver with a small test binary:
On the GNU/Linux machine I start GDB without the test binary, and
connect to gdbserver.
As I have not given GDB the test binary, my expectation is that GDB
would connect to gdbserver and then download the file over the remote
protocol, but instead I was presented with this message:
(gdb) target remote 192.168.129.25:54321
Remote debugging using 192.168.129.25:54321
warning: C:\some\directory\executable.exe: No such file or directory.
0x00007ffa3e1e1741 in ?? ()
(gdb)
What I found is that if I told GDB where to find the binary, like
this:
(gdb) file target:C:/some/directory/executable.exe
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading C:/some/directory/executable.exe from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading C:/some/directory/executable.exe from remote target...
Reading symbols from target:C:/some/directory/executable.exe...
(gdb)
then GDB would download the executable.
I eventually tracked the problem down to exec_file_find (solib.c).
The remote target was passing an absolute Windows filename (beginning
with "C:/" in this case), but in exec_file_find GDB was failing the
IS_TARGET_ABSOLUTE_PATH call, and so was treating the filename as
relative.
The IS_TARGET_ABSOLUTE_PATH call was failing because GDB thought that
the file system kind was "unix", and as the filename didn't start with
a "/" it assumed the filename was not absolute.
But I'm connecting to a Windows target, my 'target-file-system-kind'
was set to "auto", so should be figuring out that my file-system is
"dos-based".
Looking in effective_target_file_system_kind (filesystem.c), we find
that the logic of "auto" is delegated to the current gdbarch. However
in windows-tdep.c we see:
So if we are using a Windows gdbarch we should have "dos-based"
filesystems. What this means is that after connecting to the remote
target GDB has selected the wrong gdbarch.
What's happening is that the target description sent back by the
remote target only includes the x86-64 registers. There's no
information about which OS we're on. As a consequence, GDB picks the
first x86-64 gdbarch which can handle the provided register set, which
happens to be a GNU/Linux gdbarch.
And indeed, there doesn't appear to be anywhere in gdbserver that sets
the osabi on the target descriptions, though some target descriptions
do have their osabi set when the description is created, e.g. in:
gdb/arch/amd64.c - Sets GNU/Linux osabi when appropriate.
gdb/arch/i386.c - Likewise.
gdb/arch/tic6x.c - Always set GNU/Linux osabi.
Most target descriptions are created without an osabi, gdbserver does
nothing to fix this, and the description is returned to GDB without an
osabi included.
I propose that we always set the osabi name on the target descriptions
returned from gdbserver. We could try to do this when the description
is first created, but that would mean passing extra flags into the
tdesc creation code (or just passing the osabi string in), and I don't
think that's really necessary. If we consider the tdesc creation as
being about figuring out which registers are on the target, then it
makes sense that the osabi information is injected later.
So what I've done is require the osabi name to be passed to the
init_target_desc function. This is called, I believe, for all
targets, in the gdbserver code.
Now when I connect to the Windows remote the target description
returned includes the osabi name. With this extra information GDB
selects the correct gdbarch object, which means that GDB understands
the target has a "dos-based" file-system. With that correct GDB
understands that the filename it was given is absolute, and so fetches
the file from the remote as we'd like.
Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Tue, 8 Oct 2024 09:34:02 +0000 (10:34 +0100)]
gdb/gdbserver: change shared set_tdesc_osabi to take gdb_osabi
There is a single declaration of set_tdesc_osabi that is shared
between gdbserver/ and gdb/, this declaration takes a 'const char *'
argument which is the string representing an osabi.
Then in gdb/ we have an overload of set_tdesc_osabi which takes an
'enum gdb_osabi'.
In this commit I change the shared set_tdesc_osabi to be the version
which takes an 'enum gdb_osabi', and I remove the version which takes
a 'const char *'. All users of set_tdesc_osabi are updated to pass an
'enum gdb_osabi'.
The features/ code, which is generated from the xml files, requires a
new function to be added to osabi.{c,h} which can return a string
representation of an 'enum gdb_osabi'. With that new function in
place the features/ code is regenerated.
This change is being made to support the next commit. In the next
commit gdbserver will be updated to call set_tdesc_osabi in more
cases. The problem is that gdbserver stores the osabi as a string.
The issue here is that a typo in the gdbserver/ code might go
unnoticed and result in gdbserver sending back an invalid osabi
string.
To fix this we want gdbserver to pass an 'enum gdb_osabi' to the
set_tdesc_osabi function. With that requirement in place it seems to
make sense if all calls to set_tdesc_osabi pass an 'enum gdb_osabi'.
There should be no user visible changes after this commit.
Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Tue, 8 Oct 2024 09:21:59 +0000 (10:21 +0100)]
gdb: split osabi support between gdb/ and gdbsupport/ directories
In future commits I want to call set_tdesc_osabi from gdbserver/
code. Currently the only version of set_tdesc_osabi available to
gdbserver takes a string representing the osabi.
The problem with this is that, having lots of calls to set_tdesc_osabi
which all take a string is an invite for a typo to slip in. This typo
could potentially go unnoticed until someone tries to debug the wrong
combination of GDB and gdbserver, at which point GDB will fail to find
the correct gdbarch because it doesn't understand the osabi string.
It would be better if the set_tdesc_osabi calls in gdbserver could
take an 'enum gdb_osabi' value and then convert this to the "correct"
string internally. In this way we are guaranteed to always have a
valid, known, osabi string.
This commit splits the osabi related code, which currently lives
entirely on the GDB side, between gdb/ and gdbsupport/. I've moved
the enum definition along with the array of osabi names into
gdbsupport/. Then all the functions that access the names list, and
which convert between names and enum values are also moved.
I've taken the opportunity of this move to add a '.def' file which
contains all the enum names along with the name strings. This '.def'
file is then used to create 'enum gdb_osabi' as well as the array of
osabi name strings. By using a '.def' file we know that the enum
order will always match the name string array.
This commit is just a refactor, there are no user visible changes
after this commit. This commit doesn't change how gdbserver sets the
target description osabi string, that will come in the next commit.
Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
This can be replaced with a call to the first set_tdesc_osabi
function, so lets do that. I think that this makes the features/ code
slightly simpler and easier to understand.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Fri, 4 Oct 2024 17:45:04 +0000 (18:45 +0100)]
gdbserver: make arch and osabi names gdb::unique_xmalloc_ptr<char>
Convert target_desc::arch and target_desc::osabi from 'const char*' to
gdb::unique_xmalloc_ptr<char>. This also allows us to remove the user
defined ~target_desc destructor.
I doubt it ever actually occurred, but in theory at least, there was a
memory leak in set_tdesc_architecture and set_tdesc_osabi where the
member variables were assigned without freeing any previous
value... but I suspect that usually these fields are only set once.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Thu, 10 Oct 2024 10:41:40 +0000 (12:41 +0200)]
[gdb/breakpoints] Fix gdb.base/scope-hw-watch-disable.exp on arm-linux
On arm-linux, with test-case gdb.base/scope-hw-watch-disable.exp I run into:
...
(gdb) awatch a^M
Can't set read/access watchpoint when hardware watchpoints are disabled.^M
(gdb) PASS: $exp: unsuccessful attempt to create an access watchpoint
rwatch b^M
Can't set read/access watchpoint when hardware watchpoints are disabled.^M
(gdb) PASS: $exp: unsuccessful attempt to create a read watchpoint
continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0xf7ec82c8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M
(gdb) FAIL: $exp: continue until exit
...
Using "maint info break", we can see that the two failed attempts to set a
watchpoint each left behind a stale "watchpoint scope" breakpoint:
...
-5 watchpoint scope del y 0xf7ec569a inf 1
-5.1 y 0xf7ec569a inf 1
stop only in stack frame at 0xfffef4f8
-6 watchpoint scope del y 0xf7ec569a inf 1
-6.1 y 0xf7ec569a inf 1
stop only in stack frame at 0xfffef4f8
...
The SIGSEGV is a consequence of the stale "watchpoint scope" breakpoint: the
same happens if we:
- have can-use-hw-watchpoints == 1,
- set one of the watchpoints, and
- continue to exit.
The problem is missing symbol info on libc which is supposed to tell which
code is thumb. After doing "set arm fallback-mode thumb" the SIGSEGV
disappears.
Extend the test-case to check the "maint info break" command before and after
the two failed attempts, to make sure that we catch the stale
"watchpoint scope" breakpoints also on x86_64-linux.
Fix this in watch_command_1 by moving creation of the "watchpoint scope"
breakpoint after the call to update_watchpoint.
gas/
* config/tc-s390.c (s390_parse_cpu): New entry for arch15.
* doc/c-s390.texi: Document arch15 march option.
* doc/as.texi: Likewise.
* testsuite/gas/s390/s390.exp: Run the arch15 related tests.
* testsuite/gas/s390/zarch-arch15.d: Tests for arch15
instructions.
* testsuite/gas/s390/zarch-arch15.s: Likewise.
Signed-off-by: Andreas Krebbel <krebbel@linux.ibm.com> Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Tom de Vries [Thu, 10 Oct 2024 06:19:26 +0000 (08:19 +0200)]
[gdb/testsuite] Fix gdb.dwarf2/enum-type-c++.exp with clang
When running test-case gdb.dwarf2/enum-type-c++.exp with clang, we get:
...
FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::A::val1
FAIL: gdb.dwarf2/enum-type-c++.exp: val2 has correct parent
FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::ec::val2
...
The problem is that the debug info produced by clang does not contain any
references to enumerators val1 and val2, or the corresponding enumeration
types.
Instead, the variables u1 and u2 are considered to be simply of type int:
...
<1><fb>: Abbrev Number: 2 (DW_TAG_variable)
<fc> DW_AT_name : u1
<fd> DW_AT_type : <0x106>
<101> DW_AT_external : 1
<103> DW_AT_location : (DW_OP_addrx <0>)
<1><106>: Abbrev Number: 3 (DW_TAG_base_type)
<107> DW_AT_name : int
<108> DW_AT_encoding : 5 (signed)
<109> DW_AT_byte_size : 4
<1><10a>: Abbrev Number: 2 (DW_TAG_variable)
<10b> DW_AT_name : u2
<10c> DW_AT_type : <0x106>
<110> DW_AT_external : 1
<112> DW_AT_location : (DW_OP_addrx <0x1>)
...
Fix this by checking whether val1 and val2 are present in the cooked index
before checking whether they have the correct parent.
This cannot be expressed efficiently with gdb_test_lines, so factor out
gdb_get_lines and use that instead.
The test-case still calls "maint print objfiles" twice, but the first time is
for have_index. We should probably use a gdb_caching_proc for this.
Tom de Vries [Wed, 9 Oct 2024 09:17:41 +0000 (11:17 +0200)]
[gdb/testsuite] Fix gdb.base/reggroups.exp with check-read1
On aarch64-linux, with make target check-read1, I run into:
...
(gdb) info reg vector^M
...
d19 {f = 0x0, u = 0x0, s = 0x0} {f =FAIL: gdb.base/reggroups.exp: fetch reggroup regs vector (timeout)
0, u = 0, s = 0}^M
...
The problem is that while (as documented) the corresponding gdb_test_multiple
doesn't work for vector registers, it doesn't skip them either. This causes
the timeout, and it also causes the registers after a vector register not to
be found.
Fix this by using -lbl style matching.
Make which reggroups and registers are found more explicit using verbose -log,
which makes us notice that regnames with underscores are skipped, so fix that
as well.
While we're at it, this:
...
set invalid_register_re "Invalid register .*"
...
and this:
...
-re $invalid_register_re {
fail "$test (unexpected invalid register response)"
}
...
means that the prompt may or may not be consumed. Fix this by limiting the
regexp to one line, and using exp_continue.
While we're at it, improve readability of the complex regexp matching a single
register by factoring out regexps.
Tom de Vries [Tue, 8 Oct 2024 20:31:12 +0000 (22:31 +0200)]
[gdb/testsuite] Fix gdb.base/break-interp.exp with check-read1
When running test-case gdb.base/break-interp.exp with check-read1, I run into:
...
(gdb) info files^M
...
0x00007ffff7e75980 - 0x00007ffff7e796a0 @ 0x001f1970 is .bss in /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.base/break-interp/break-interp-BINprelinkNOdebugNOFAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: symbol-less: info files (timeout)
pieNO.d/libc.so.6^M
...
The code has two adaptations to deal with the large output:
- nested gdb_test_multiple, and
- an exp_continue in the inner gdb_test_multiple.
The former seems unnecessary, and the latter doesn't trigger often enough
because of an incomplete hex number regexp, causing the timeout.
Andrew Burgess [Sat, 5 Oct 2024 11:34:14 +0000 (12:34 +0100)]
gdb: include --enable-targets in 'show configuration' output
Include the value of configuration flag --enable-targets in the output
of GDB command 'show configuration' and also in the output printed for
'gdb --configuration'. This will make it easier to see how GDB was
built.
No tests added or updated as we can't really check for a specific flag
appearing or not appearing on the configuration output. But we do
print the configuration within lib/gdb.exp to check which features are
built into GDB, so if this change broke configuration printing then
plenty of tests should stop working (they don't).
gdb: only insert thread-specific breakpoints in the relevant inferior
added a couple of calls to breakpoint::clear_locations() inside
update_breakpoint_locations().
The intention of these calls was to avoid leaving redundant locations
around when a thread- or inferior-specific breakpoint was switched
from one thread or inferior to another.
Without the clear_locations() calls the tests gdb.multi/tids.exp and
gdb.multi/pending-bp.exp have some failures. A b/p is changed such
that the program space it is associated with changes. This triggers a
call to breakpoint_re_set_one() but the FILTER_PSPACE argument will be
the new program space. As a result GDB correctly calculates the new
locations and adds these to the breakpoint, but the old locations, in
the old program space, are incorrectly retained. The call to
clear_locations() solves this by deleting the old locations.
However, while working on another patch I realised that the approach
taken here is not correct. The FILTER_PSPACE argument passed to
breakpoint_re_set_one() and then on to update_breakpoint_locations()
might not be the program space to which the breakpoint is associated.
Consider this example:
(gdb) file /tmp/hello.x
Reading symbols from /tmp/hello.x...
(gdb) start
Temporary breakpoint 1 at 0x401198: file hello.c, line 18.
Starting program: /tmp/hello.x
Temporary breakpoint 1, main () at hello.c:18
18 printf ("Hello World\n");
(gdb) break main thread 1
Breakpoint 2 at 0x401198: file hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000401198 in main at hello.c:18
stop only in thread 1
(gdb) add-inferior -exec /tmp/hello.x
[New inferior 2]
Added inferior 2 on connection 1 (native)
Reading symbols from /tmp/hello.x...
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y <PENDING> main
stop only in thread 1.1
Notice that after creating the second inferior and loading a file the
thread-specific breakpoint was incorrectly made pending. Loading the
exec file in the second inferior triggered a call to
breakpoint_re_set() with the new, second, program space as the
current_program_space.
This program space ends up being passed to
update_breakpoint_locations().
In update_breakpoint_locations this condition is true:
if (all_locations_are_pending (b, filter_pspace) && sals.empty ())
and so we end up discarding all of the locations for this breakpoint,
making the breakpoint pending.
What we really want to do in update_breakpoint_locations() is, for
thread- or inferior- specific breakpoints, delete any locations which
are associated with a program space that this breakpoint is NOT
associated with.
But then I realised the answer was easier than that.
The ONLY time that a b/p can have locations associated with the
"wrong" program space like this is at the moment we change the thread
or inferior the b/p is associated with by calling
breakpoint_set_thread() or breakpoint_set_inferior().
And so, I think the correct solution is to hoist the call to
clear_locations() out of update_breakpoint_locations() and place a
call in each of the breakpoint_set_{thread,inferior} functions.
I've done this, and added a couple of new tests. All of which are
now passing.
Tom de Vries [Tue, 8 Oct 2024 11:45:21 +0000 (13:45 +0200)]
[gdb/testsuite] Fix gdb.ada/tagged-lookup.exp with read1+readnow
When running test-case gdb.ada/tagged-lookup.exp with target board readnow and
make target check-read1:
...
$ ( cd build/gdb; \
make check-read1 \
RUNTESTFLAGS="--target_board=readnow gdb.ada/tagged-lookup.exp" )
...
I run into:
...
(gdb) PASS: gdb.ada/tagged-lookup.exp: set debug symtab-create 1
print *the_local_var^M
$1 = (n => 2)^M
(gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded
...
The problem is that the corresponding gdb_test_multiple uses line-by-line
matching (using -lbl) which doesn't work well with the multiline pattern
matching both the prompt and the line before it:
...
-re -wrap ".* = \\\(n => $decimal\\\)" {
...
Fix this by making it a one-line pattern:
...
-re -wrap "" {
...
While we're at it, replace an if-then-pass-else-fail with a gdb_assert.
Tom de Vries [Tue, 8 Oct 2024 10:27:20 +0000 (12:27 +0200)]
[gdb/symtab] Fix gdb.dwarf2/enum-type-c++.exp with cc-with-debug-types
When running test-case gdb.dwarf2/enum-type-c++.exp with target board
cc-with-debug-types, we run into:
...
(gdb) FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
...
because val1 has no parent:
...
[31] ((cooked_index_entry *) 0x7efedc002e90)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0xef
parent: ((cooked_index_entry *) 0)
Fix this by:
- adding a cooked index entry for DIE 0xcb (and consequently for child DIE
0xd3), by marking it interesting,
- making sure that the entry for DIE 0xcb has a name, and
- using the entry for DIE 0xd3 as parent entry for DIE 0xdd.
Tom de Vries [Tue, 8 Oct 2024 10:27:20 +0000 (12:27 +0200)]
[gdb/symtab] Fix parent of enumerator
As mentioned in commit 489b82720f5 ('[gdb/symtab] Revert "Change handling of
DW_TAG_enumeration_type in DWARF scanner"'), when doing "maint print objfiles" in
test-case gdb.dwarf2/enum-type.exp, for val1 we get an entry without parent:
...
[27] ((cooked_index_entry *) 0x7fbbb4002ef0)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0x124
parent: ((cooked_index_entry *) 0)
...
This happens here in cooked_indexer::index_dies:
...
info_ptr = recurse (reader, info_ptr,
is_enum_class ? this_entry : parent_entry,
fully);
...
when we're passing down a nullptr parent_entry, while the parent of this_entry
is deferred.
Fix this in cooked_indexer::index_dies by passing down a deffered parent
instead, such that we get:
...
[27] ((cooked_index_entry *) 0x7ff0e4002ef0)^M
name: val1^M
canonical: val1^M
qualified: ns::val1^M
DWARF tag: DW_TAG_enumerator^M
flags: 0x0 []^M
DIE offset: 0x124^M
parent: ((cooked_index_entry *) 0x7ff0e4002f20) [ns]^M
...
Tom de Vries [Tue, 8 Oct 2024 06:24:13 +0000 (08:24 +0200)]
[gdb/contrib] Add more separators in spellcheck.sh
Add two more separators in spellcheck.sh: colon and comma.
Doing so triggers the "inbetween->between" rule, which gives an incorrect
result. Override this with "inbetween->between, in between, in-between" [1],
in a new file gdb/contrib/common-misspellings.txt.
Fix the following common misspellings:
...
everytime -> every time
sucess -> success
thru -> through
transfered -> transferred
inbetween -> between, in between, in-between
...
Verified with spellcheck.sh. Tested on x86_64-linux.
Tom de Vries [Tue, 8 Oct 2024 06:24:13 +0000 (08:24 +0200)]
[gdb/contrib] Factor out grep_or and sed_or in spellcheck.sh
While trying to add more separators here:
...
# Separators: space, slash, tab.
grep_separator=" |/| "
sed_separator=" \|/\|\t"
...
I mistakingly used "|" instead of "\|" in sed_separator.
Factor out new variables grep_or and sed_or, and construct the grep_separator
and sed_separator variables by joining the elements of a list using grep_or
and sed_or.
Verified with shellcheck, and tested by rerunning on x86_64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Alan Modra [Mon, 7 Oct 2024 23:35:39 +0000 (10:05 +1030)]
Revised "Don't return (null) from bfd_elf_sym_name"
Commit 68bbe1183379 results in a lot of follow up work, much of which
likely is still to be done. (And yes, since this is all for corrupted
or fuzzed object files, a whole lot of work doesn't much benefit
anyone. It was a bad idea to put NULL in asymbol->name.) So I'm
changing the approach to instead put a unique empty string for symbols
with a corrupted st_name. An empty string won't require much work to
ensure nm, objcopy, objdump etc. won't crash, since these tools
already must work with unnamed local symbols.
The unique empty string is called bfd_symbol_error_name. This patch
uses that name string for corrupted symbols in the ELF and COFF
backends. Such symbols are displayed by nm and objdump as the
translated string "<corrupt>", which is what the COFF backend used to
put directly into corrupted symbols.
ie. it's the way I should have written the original patch, plus a few
tides and cleanups I retained from the reverted patches.
projects / thirdparty / binutils-gdb.git / log
