__SVE_VQ_BYTES is only available if SVE definitions are available in
the system's headers, and this is not true for all systems.
For this purpose, we define SVE_VQ_BYTES. This patch fixes the
name of the constant being used.
This warning is triggered only when a stack parameter is given to
the linker.
ld/ChangeLog:
* emultempl/nto.em: Add warning when several QNX .note are
detected.
Up to now, the linker would always create a QNX stack note from scratch.
However, object files could already have such note, ending up into
duplicates. QNX loader doesn't handle that.
Update the mechanism to first search through the input files for a .note
section holding a QNX stack note. If none are found, then a new section
is created into the stub file as before. This requires this search to be
done once the file have been opened, moving the whole logic a bit later
in the emulation process.
As part for this update, also allow to request an executable stack
without necessarily having to provide its size as well. In this case, s
etup a default lazy stack of 0x1000.
ld/ChangeLog:
* emultempl/nto.em (nto_create_QNX_note_section): New Function.
(nto_lookup_QNX_note_section): New Function.
(nto_add_note_section): Move the creation of the note section
in the above new functions.
(nto_create_output_section_statements): rename nto_after_open
* testsuite/ld-aarch64/aarch64-nto.exp: add new test.
* testsuite/ld-aarch64/nto-stack-note-3.d: New test.
* testsuite/ld-aarch64/nto-stack-note.s: New test.
The elf psabi allows for mapping symbols to be of the form $x<ISA>.<any>
opcodes/
* riscv-dis.c (riscv_get_map_state): allow mapping symbol to
be suffixed by a unique identifier .<any>
A user pointed out that the -lsocket check in gdb should also apply to
gdbserver -- otherwise it can't find the Solaris socketpair. This
patch makes the change. It also removes a couple of redundant
function checks from gdb's configure.ac.
This was tested by the person who reported the bug.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30927
Approved-By: Pedro Alves <pedro@palves.net>
Simon pointed out that the new file-then-restart.exp test fails with
the extended-remote target board.
The problem is that the test suite doesn't use gdb_file_cmd -- which
handles things like "set remote exec-file". This patch changes
gdb_file_cmd to make the "kill" command optional, and then switches
the test case to use it.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30933
Approved-By: Simon Marchi <simon.marchi@efficios.com>
In GDB we have a problem with the BFD cache.
As GDB runs for a potentially extended period of time, if the BFD
cache holds a file descriptor for an open on-disk file, this can, on
some targets (e.g. Win32) prevent the OS writing to the file.
This might, for example, prevent a user from recompiling their
executable as GDB is (via the BFD cache) holding an open reference to
that file.
Another problem, relates to bfd_stat, for BFDs that are using the BFD
cache (i.e. they call cache_bstat to implement bfd_stat). The
cache_bstat function finds the BFD in the cache, opening the file if
needed, and then uses fstat on the open file descriptor.
What this means is that, if the on-disk file changes, but the cache
was holding an open reference to the file, the bfd_stat will return
the 'struct stat' for the old file, not the new file.
Now, for this second problem, we might be tempted to make use of an
actual stat call, instead of calling bfd_stat, however, this isn't
ideal as we have some BFDs that use a custom iovec, and implement the
various functions over GDB's remote protocol. By using bfd_stat we
can have a single call that should work for both local files, and for
remote files.
To solve both of these problems GDB has calls to bfd_cache_close_all
sprinkled around its code base. And in theory this should work fine.
However, I recently ran into a case where we had missed a
bfd_cache_close_all call, and as a result some BFDs were held open.
This caused a bfd_stat call to return an unexpected result (old file
vs new file).
What I'd like is some way within GDB that I can do:
gdb_assert ( /* Nothing is held open in the cache. */ );
As this would allow GDB to quickly identify when we've missed some
bfd_cache_close_all calls.
And so, to support this, I would like to add a new bfd_cache_size
function. This function returns an integer, which is the number of
open files in the cache. I can then start adding:
gdb_assert (bfd_cache_size() == 0);
to GDB in some strategic spots, and start fixing all of the missing
bfd_cache_close_all calls that crop up as a result.
Within bfd/cache.c change the type for max_open_files and open_files
variables from int to unsigned. As a consequence of this, the return
type for bfd_cache_max_open() is also changed from int to unsigned.
Within bfd_cache_max_open I've left the local 'max' variable as an
int, this should ensure that if the sysconf call fails, and returns
-1, then the computed max value will be less than 10, which means
max_open_files will be set to 10. If 'max' was changed to unsigned
then, should the sysconf call fail, we'd end up with max becoming a
very large positive number ... which is clearly not what we want.
And, while I was auditing how open_files is used, I added an assert
within bfd_cache_delete to ensure that we don't try to reduce
open_files below zero.
There should be no user visible change with this commit.
I was looking for cases where a GCC patch under evaluation would cause test
results to change. Quite surprisingly the mcore-elf port showed test
differences. After a fair amount of digging my conclusion was the sequences
before/after the patch should have been semantically the same.
Of course if the code is supposed to behave the same, then that points to
problems elsewhere (assembler, linker, simulator). Sure enough the mcore
simulator was mis-handling the sign extension instructions. The simulator
implementation of sextb is via paired shift-by-24 operations. Similarly the
simulator implements sexth via paired shift-by-16 operations.
The temporary holding the value was declared as a "long" thus this approach
worked fine for hosts with a 32 bit wide long and failed miserably for hosts
with a 64 bit wide long.
This patch makes the shift count automatically adjust based on the size of the
temporary. It includes a simple test for sextb and sexth. I have _not_ done a
full audit of the mcore simulator for more 32->64 bit issues.
This also fixes 443 execution tests in the GCC testsuite
The old application name (er_archive) is used in many places.
gprofng/ChangeLog
2023-10-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/Experiment.cc: Replace er_archive with gp-archive.
* src/Experiment.cc: Likewise.
When execute the following command on LoongArch:
make check-gdb TESTS="gdb.base/infcall-nested-structs-c++.exp"
there exist some failed testcases:
=== gdb Summary ===
# of expected passes 5533
# of unexpected failures 367
The root cause is related with a struct containing floating-point
members as function argument or return value for a dummy call.
(1) Structure consists of one floating-point member within FRLEN bits
wide, it is passed in an FAR if available.
(2) Structure consists of two floating-point members both within FRLEN
bits wide, it is passed in two FARs if available.
(3) Structure consists of one integer member within GRLEN bits wide and
one floating-point member within FRLEN bits wide, it is passed in a
GAR and an FAR if available.
Note that in the above cases, empty structure or union members are also
ignored even in C++.
Here is a simple test on LoongArch:
loongson@bogon:~$ cat test.c
#include<stdio.h>
struct test {
long a;
double b __attribute__((aligned(16)));
};
struct test val = { 88, 99.99 };
int check_arg_struct (struct test arg)
{
printf("arg.a = %ld\n", arg.a);
printf("arg.b = %f\n", arg.b);
printf("sizeof(val) = %d\n", sizeof(val));
return 1;
}
int main()
{
check_arg_struct (val);
return 0;
}
loongson@bogon:~$ gcc -g test.c -o test
loongson@bogon:~$ ./test
arg.a = 88
arg.b = 99.990000
sizeof(val) = 32
Before:
loongson@bogon:~$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:19
19 check_arg_struct (val);
(gdb) p check_arg_struct (val)
arg.a = 140737488286128
arg.b = -nan
sizeof(val) = 32
$1 = 1
...
After:
loongson@bogon:~$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:19
19 check_arg_struct (val);
(gdb) p check_arg_struct (val)
arg.a = 88
arg.b = 99.990000
sizeof(val) = 32
$1 = 1
...
With this patch, there are no failed testcases:
make check-gdb TESTS="gdb.base/infcall-nested-structs-c++.exp"
=== gdb Summary ===
# of expected passes 5900
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
As reported in bug 30630 [1], we hit a case where the remote target's
async flag is marked while the target is not configured (yet) to work
async. This should not happen. It is caught thanks to this assert in
remote_target::wait:
/* Start by clearing the flag that asks for our wait method to be called,
we'll mark it again at the end if needed. If the target is not in
async mode then the async token should not be marked. */
if (target_is_async_p ())
rs->clear_async_event_handler ();
else
gdb_assert (!rs->async_event_handler_marked ());
This is helpful, but I think that we could have caught the problem earlier than
that, at the moment we marked the handler. Catching problems earlier
makes them easier to debug.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=30630
Change-Id: I7e229c74b04da82bef6a817d5a676be5cf52e833
Approved-By: Andrew Burgess <aburgess@redhat.com>
A subsequent patch will want to know if the remote is async within a
remote_state method. Add a helper method for that, and for "can async"
as well, for symmetry.
Change-Id: Id0f648ee4896736479fa942f5453eeeb0e5d4352
Approved-By: Andrew Burgess <aburgess@redhat.com>
Make remote_async_inferior_event_token private (rename to
m_async_event_handler_token) and add methods for the various operations
we do on it. This will help by:
- allowing to break on those methods when debugging
- allowing to add assertions in the methods
Change-Id: Ia3b8a2bc48ad4849dbbe83442c3f83920f03334d
Approved-By: Andrew Burgess <aburgess@redhat.com>
inferior::set_arch calls registers_changed, which invalidates all
regcaches. It would be enough to invalidate only regcaches of threads
belonging to this inferior. Call registers_changed_ptid instead, with
the proper process target / ptid. If the inferior does not have a
process target, there should be no regcaches for that inferior, so no
need to invalidate anything.
Change-Id: Id8b5500acb7f373b01a534f16d3a7d028dc0d882
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
This function is just a wrapper around the current inferior's gdbarch.
I find that having that wrapper just obscures where the arch is coming
from, and that it's often used as "I don't know which arch to use so
I'll use this magical target_gdbarch function that gets me an arch" when
the arch should in fact come from something in the context (a thread,
objfile, symbol, etc). I think that removing it and inlining
`current_inferior ()->arch ()` everywhere will make it a bit clearer
where that arch comes from and will trigger people into reflecting
whether this is the right place to get the arch or not.
Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
set_target_gdbarch is basically a setter for the current inferior's
arch, that notifies other parts of GDB of the architecture change. Move
the code of set_target_gdbarch to the inferior::set_arch method.
Add gdbarch_initialized_p, so we can keep the assertion.
Change-Id: I276e28eafd4740c94bc5233c81a86c01b4a6ae90
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
This is to make it explicit which inferior's architecture just changed,
and that the callbacks should not assume it is the current inferior.
Update the only caller, pyuw_on_new_gdbarch, to add the parameter,
although it doesn't use it currently.
Change-Id: Ieb7f21377e4252cc6e7b1ce2cc812cd1a1840e0e
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Make the inferior's gdbarch field private, and add getters and setters.
This helped me by allowing putting breakpoints on set_arch to know when
the inferior's arch was set. A subsequent patch in this series also
adds more things in set_arch.
Change-Id: I0005bd1ef4cd6b612af501201cec44e457998eec
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Guard against fuzzed files where .plt size isn't commensurate with
plt relocations.
* elf32-arm.c (elf32_arm_plt0_size): Add data_size param.
Return -1 if data_size is too small.
(elf32_arm_plt_size): Likewise. Delete temp var. Formatting.
(elf32_arm_get_synthetic_symtab): Adjust to suit.
This fixes multiple places in read_and_display_attr_value dealing with
range and location lists that can segfault when debug_info_p is NULL.
Fuzzed object files can contain arbitrary DW_FORMs.
* dwarf.c (read_and_display_attr_value): Don't dereference NULL
debug_info_p.
With specially crafted compressed sections, it's possible to tickle a
problem when decompressing: If the compression headers says the
uncompressed size is zero, this will be seen as an error return from
bfd_compress_section_contents. On errors the caller should free any
malloc'd input buffers, but this isn't really an error and the section
contents have been updated to a bfd_alloc'd buffer which can't be
freed.
* compress.c (bfd_compress_section_contents): Return -1 as error
rather than 0.
(bfd_init_section_compress_status, bfd_compress_section): Adjust.
This commit adds a new Python function, gdb.notify_mi, that can be used
to emit custom async notification to MI channel. This can be used, among
other things, to implement notifications about events MI does not support,
such as remote connection closed or register change.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
This commit generalizes serialize_mi_result() to make usable in
different contexts than printing result of custom MI command.
To do so, the check whether passed Python object is a dictionary has been
moved to the caller - at the very least, different uses require different
error messages. Also it has been renamed to serialize_mi_results() to better
match GDB/MI output syntax (see corresponding section in documentation,
in particular rules 'result-record' and 'async-output'.
Since it is now more generic function, it has been moved to py-mi.c.
This is a preparation for implementing Python support for sending custom
MI async events.
Approved-By: Andrew Burgess <aburgess@redhat.com>
For the instructions of R_LARCH_B16/B21, if the immediate overflow,
add a B instruction and R_LARCH_B26 relocation.
For example:
.L1
...
blt $t0, $t1, .L1
R_LARCH_B16
change to:
.L1
...
bge $t0, $t1, .L2
b .L1
R_LARCH_B26
.L2
Add the abilitity to print a v9 .gdb_index section.
The v9 section contains an extra table, which is printed as follows:
...
Shortcut table:
Language of main: Fortran 95
Name of main: contains_keyword
...
[ For the example, I used the exec of gdb test-case
gdb.fortran/nested-funcs-2-exp when running the test-case with target board
cc-with-gdb-index. ]
Tested on x86_64-linux.
Approved-By: Nick Clifton <nickc@redhat.com>
This patch adds a new section to the DWARF index containing the name
and the language of the main function symbol, gathered from
`cooked_index::get_main`, if available. Currently, for lack of a better name,
this section is called the "shortcut table". The way this name is both saved and
applied upon an index being loaded in mirrors how it is done in
`cooked_index_functions`, more specifically, the full name of the main function
symbol is saved and `set_objfile_main_name` is used to apply it after it is
loaded.
The main use case for this patch is in improving startup times when dealing with
large binaries. Currently, when an index is used, GDB has to expand symtabs
until it finds out what the language of the main function symbol is. For some
large executables, this may take a considerable amount of time to complete,
slowing down startup. This patch bypasses that operation by having both the name
and language of the main function symbol be provided ahead of time by the index.
In my testing (a binary with about 1.8GB worth of DWARF data) this change brings
startup time down from about 34 seconds to about 1.5 seconds.
When testing the patch with target board cc-with-gdb-index, test-case
gdb.fortran/nested-funcs-2.exp starts failing, but this is due to a
pre-existing issue, filed as PR symtab/30946.
Tested on x86_64-linux, with target board unix and cc-with-gdb-index.
PR symtab/24549
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549
Approved-By: Tom de Vries <tdevries@suse.de>
This thread:
https://inbox.sourceware.org/gdb-patches/20231003195338.334948-1-thiago.bauermann@linaro.org/
pointed out that within gdb.base/maint.exp, some regexps within a
gdb_test_multiple were failing to match a complete line, while later
regexps within the gdb_test_multiple made use of the '^' anchor, and
so assumed that earlier lines had been completely matched and removed
from expect's buffer.
When testing with READ1 set this assumption was failing.
Fix this by extending the offending patterns with a trailing '\r\n'.
Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Now that the GDB 14 branch has been created,
this commit bumps the version number in gdb/version.in to
15.0.50.DATE-git
For the record, the GDB 14 branch was created
from commit 8f12a1a841.
Also, as a result of the version bump, the following changes
have been made in gdb/testsuite:
* gdb.base/default.exp: Change $_gdb_major to 15.
Some older kernels cannot handle the newly generated R_LARCH_32/64_PCREL,
so the assembler generates R_LARCH_ADD32/64+R_LARCH_SUB32/64 by default,
and use the assembler option mthin-add-sub to generate R_LARCH_32/64_PCREL
as much as possible.
The Option of mthin-add-sub does not affect the generation of R_LARCH_32_PCREL
relocation in .eh_frame.
On x86_64-linux, with test-case gdb.arch/i386-signal.exp I run into:
...
builtin_spawn -ignore SIGHUP gcc -fno-stack-protector i386-signal.c \
-fdiagnostics-color=never -fno-pie -g -no-pie -lm -o i386-signal^M
/tmp/cc2xydTG.s: Assembler messages:^M
/tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'^M
compiler exited with status 1
output is:
/tmp/cc2xydTG.s: Assembler messages:^M
/tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'^M
gdb compile failed, /tmp/cc2xydTG.s: Assembler messages:
/tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'
UNTESTED: gdb.arch/i386-signal.exp: failed to compile
...
This is with gas 2.41, it compiles without problems with gas 2.40. Some more
strict checking was added in commit 5cc007751c ("x86: further adjust
extend-to-32bit-address conditions"). This may or may not be a gas regression
( https://sourceware.org/pipermail/binutils/2023-October/129818.html ).
The offending bit is:
...
" push $sigframe\n"
...
which refers to a function:
...
" .globl sigframe\n"
"sigframe:\n"
...
The test-case passes with target board unix/-m32.
Make the test-case work by using pushq instead of push for the
is_amd64_regs_target case.
Tested on x86_64-linux, with target boards:
- unix/-m64 (is_amd64_regs_target == 1), and
- unix/-m32 (is_amd64_regs_target == 0),
PR testsuite/30928
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30928
Linux kernel commit commit 317c8194e6ae ("rseq: Introduce feature size
and alignment ELF auxiliary vector entries") introduced two new auxvs:
AT_RSEQ_FEATURE_SIZE and AT_RSEQ_ALIGN. Support them in GDB. This
fixes auxv.exp on kernels >= v6.3.
Change-Id: I8966c4d5c73eb7b45de6d410a9b28a6628edad2e
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30540
Approved-By: Tom Tromey <tom@tromey.com>
