Andrew Burgess [Sun, 27 Oct 2024 08:55:16 +0000 (08:55 +0000)]
gdb/testsuite: avoid intermittent failures on a debuginfod test
I saw a failure in gdb.debuginfod/build-id-no-debug-warning.exp which
I could only produce one time.
Normally the test output looks like this:
file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Downloading separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo...
(gdb) PASS: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no war
But one time I saw this:
file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Downloading 6.77 K separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo...
(gdb) FAIL: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no warnings
The difference is the "Downloading separate debug info for ..." line
has gained an extra '6.77 K' component. When I got the FAIL the
machine was under heavy load, so I suspect everything was running
pretty slow. I think the size is only added when the debuginfod
download is taking its time.
Anyway, the test in question is not expecting to see a size, which is
why it failed.
Every other debuginfod test does allow for an optional size being
printed, so lets update this test to also accept an optional size,
this should prevent failures like this in the future.
Tom de Vries [Sat, 26 Oct 2024 12:48:44 +0000 (14:48 +0200)]
[gdb/testsuite] Fix gdb.dwarf2/dwp-symlink.exp with target board fission-dwp
There are two test-cases that only run when the target board produces .dwp
files, gdb.dwarf2/dwp-sepdebug.exp and gdb.dwarf2/dwp-symlink.exp.
When running those test-cases with target board fission-dwp, I run into:
...
(gdb) ptype main^M
warning: Could not find DWO CU dwp-symlink0.dwo(0x496f1a7405c37a61) \
referenced by CU at offset 0xa6 [in module dwp-symlink]^M
type = <unknown return type> ()^M
(gdb) FAIL: gdb.dwarf2/dwp-symlink.exp: binary default, dwp at symlink
...
coming from:
...
# This case cannot work.
gdb_test "ptype main" {type = int \(\)} "binary default, dwp at symlink"
...
I had a bit of difficulty understanding what the test-case does/tries to do,
so to build some understanding I reproduced the behaviour outside of the
test-case:
...
$ cat start.c
void _start (void) {}
$ gcc -gsplit-dwarf start.c -nostdlib
$ gdb -q -batch a.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ dwp -e a.out
$ rm start.dwo
$ gdb -q -batch a.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ ln -s a.out b.out
$ gdb -q -batch b.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ mv a.out.dwp b.out.dwp
$ gdb -q -batch b.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ gdb -q -batch a.out -ex "print _start"
During symbol reading: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \
referenced by CU at offset 0x0 [in module a.out]
warning: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \
referenced by CU at offset 0x0 [in module a.out]
$1 = {<text variable, no debug info>} 0x400144 <_start>
...
and agreed, that cannot work: the DWO CU required in a.out is in b.out.dwp,
and there's no way to find b.out.dwp starting from a.out.
The fact that a FAIL is produced is incorrect, gdb does nothing wrong.
Fix this by checking for the warning text instead.
While we're at it, fix this PATH as well:
...
(gdb) cd /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink^M
Working directory /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink.^M
(gdb) PASS: gdb.dwarf2/dwp-symlink.exp: cd \
/data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink
PATH: gdb.dwarf2/dwp-symlink.exp: cd \
/data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink
...
While we're at it, use string_to_regexp to simplify the test-case.
Tested on x86_64-linux, with target board fission-dwp.
[gdb/testsuite] Fix some test-cases for check-read1 (-lbl)
I notice that gdb.base/sect-cmd.exp would sometimes fail. The problem
is that by switching to line by line matching we now need to ensure
that the gdb_test_multiple patterns match up to the end of the line,
but don't actually include the trailing \r\n (yeah, our line by line
matching is weird). We need to be especially careful anywhere '.*' is
used as this can potentially match content on a subsequent line.
I have replaced '.*' with '\[^\r\n\]*(?=\r\n)', matching everything up
to the end of the line, but not the end of line itself, and I've made
use of '(?=\r\n)' in a couple of other places to ensure we match up to
the end of the line, but don't match the line terminator itself.
Tom de Vries [Sat, 26 Oct 2024 06:40:07 +0000 (08:40 +0200)]
[gdb] Don't create registry keys in destructor
Creating a registry key using emplace calls new:
...
DATA *result = new DATA (std::forward<Args> (args)...);
...
which can throw a bad alloc, which will terminate gdb if called from a
destructor.
Tom de Vries [Fri, 25 Oct 2024 10:48:18 +0000 (12:48 +0200)]
[gdb] Handle bad alloc in gdb_rl_callback_read_char_wrapper_noexcept
Say we simulate a bad alloc in exceptions_state_mc_init:
...
jmp_buf *
exceptions_state_mc_init ()
{
+ {
+ 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));
+ }
+ }
catchers.emplace_front ();
return &catchers.front ().buf;
}
...
After starting gdb and typing "q", gdb terminates:
...
$ gdb -q
(gdb) terminate called after throwing an instance of 'gdb_quit_bad_alloc'
what(): std::bad_alloc
...
because the bad alloc (thrown in TRY_SJLJ) is caught by the noexcept on
gdb_rl_callback_read_char_wrapper_noexcept:
...
static struct gdb_exception
gdb_rl_callback_read_char_wrapper_noexcept () noexcept
{
struct gdb_exception gdb_expt;
/* C++ exceptions can't normally be thrown across readline (unless
it is built with -fexceptions, but it won't by default on many
ABIs). So we instead wrap the readline call with a sjlj-based
TRY/CATCH, and rethrow the GDB exception once back in GDB. */
TRY_SJLJ
...
Fix this by renaming gdb_rl_callback_read_char_wrapper_noexcept to
gdb_rl_callback_read_char_wrapper_sjlj and calling it from a wrapper function
that catches the bad alloc expection:
...
static struct gdb_exception
gdb_rl_callback_read_char_wrapper_noexcept () noexcept
{
try
{
return gdb_rl_callback_read_char_wrapper_sjlj ();
}
catch (gdb_exception &ex)
{
return std::move (ex);
}
}
...
getting us instead:
...
$ gdb -q
(gdb) bad alloc
(gdb) q
...
Tom de Vries [Fri, 25 Oct 2024 04:14:03 +0000 (06:14 +0200)]
[gdb/testsuite] Fix gdb.cp/exceptprint.exp with check-read1
Fix test-case gdb.cp/exceptprint.exp with make target check-read1 by limiting
the output of skip_libstdcxx_probe_tests_prompt by making the used command
more precise: using "info probes stap libstdcxx" instead of "info probes".
Tom de Vries [Fri, 25 Oct 2024 04:14:03 +0000 (06:14 +0200)]
[gdb/testsuite] Fix gdb.threads/ia64-sigill.exp with check-read1
Fix test-case gdb.threads/ia64-sigill.exp with make target check-read1 by
using a custom line-by-line exp_continue clause:
...
-re "\r\n\[^\r\n\]*(?=\r\n\[^\r\n\]*\r\n)" {
exp_continue
}
...
which drops a line each time it finds two lines in the buffer.
This allows the other clauses to use two-line patterns.
Tom Tromey [Thu, 17 Oct 2024 23:16:54 +0000 (17:16 -0600)]
Add locking when reading BFD sections
This adds some per-BFD locking to gdb_bfd_map_section and
gdb_bfd_get_full_section_contents.
It turned out that the background DWARF reader could race with the
auto-load code, because the reader might try to mmap a section when
the main thread was trying to read in .debug_gdb_scripts.
The current BFD threading model is that only BFD globals will be
locked, so any multi-threaded use of a BFD has to be handled specially
by the application.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31626 Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Tom Tromey [Thu, 17 Oct 2024 22:57:03 +0000 (16:57 -0600)]
Use gdb_bfd_get_full_section_contents in auto-load.c
This changes auto-load.c ot use gdb_bfd_get_full_section_contents.
This shouldn't change any behavior, but makes it easier to add locking
in a subsequent patch.
Alan Modra [Mon, 21 Oct 2024 01:46:31 +0000 (12:16 +1030)]
Replace uses of asprintf with xasprintf
xasprintf has a nicer interface and behaves like xmalloc as far as
memory is concerned, ie. no need to check a return status and the
program exits with an error on OOM.
gdb/testsuite: introduce dwarf5 option to gdb_compile
A few tests on the testsuite require dwarf5 to work. Up until now, the
way to do this was to explicitly add the command line flag -gdwarf-5.
This isn't very portable, in case a compiler requires a different flag
to emit dwarf5.
This commit adds a new option to gdb_compile that would be able to add
the correct flag (if known) or error out in case we are unable to tell
which flag to use. It also changes the existing tests to use this
general option instead of hard coding -gdwarf-5.
Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Wed, 18 Sep 2024 18:44:42 +0000 (12:44 -0600)]
Implement 'Object_Size
This patch started as an attempt to allow the 'Size attribute to be
applied to types, and not just objects.
However, that turns out to be difficult due to the Ada semantcs of
'Size. In particular, Ada requires 'Size to denote the size of the
representation of the value, so for example Boolean'Size must be 1.
Implementing this properly requires information not readily available
to gdb... and while we could synthesize this information in many
cases, it also seemed to me that this wasn't strictly very useful when
debugging.
So instead, this patch adds support for the 'Object_Size attribute,
which is somewhat closer to 'sizeof'.
Note also that while 'Object_Size is defined for some dynamic types, I
chose not to implement this here, as again this information is not
readily available -- and I think it's preferable to error than to
print something that might be incorrect.
Michael Matz [Mon, 21 Oct 2024 15:58:32 +0000 (17:58 +0200)]
stringmerge: don't presize hash table
originally the reason for pre-sizing was that that's easier
for a multi-threaded use of the hash table. That hasn't materialized
yet, so there's not much sense in using the very very conservative
estimates for pre-sizing. Doing the resize on-demand, whenever we
actually need to add a new entry doesn't change performance.
bfd/
merge.c (sec_merge_hash_insert): Resize as needed from here ...
(record_section): ... not from here. Don't calculate estimates,
return bool instead of three-state, regard all errors as soft
errors.
(_bfd_merge_sections): Adjust.
Stephan Rohr [Wed, 16 Oct 2024 08:42:27 +0000 (01:42 -0700)]
gdbserver: use 'gdb::function_view' in 'find_*' and 'for_each_*'
Remove the templated versions of 'find_thread', 'for_each_thread' and
'find_thread_in_random' and replace the template function argument with
'gdb::function_view'. The usage of 'gdb::function_view' produces less
cryptic messages on errors and documents well the types of the
parameters taken by the callback and its return type.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Tue, 22 Oct 2024 07:23:26 +0000 (09:23 +0200)]
[gdb/testsuite] Handle maint set dwarf synchronous off default
I ran the testsuite with a patch setting dwarf_synchronous to false by
default, and ran into FAILs in test-cases gdb.dwarf2/dw2-inter-cu-error.exp
and gdb.dwarf2/dw2-inter-cu-error-2.exp, because the expected DWARF errors did
not show up as a result of the file command.
Fix this by forcing "maint set dwarf synchronous on".
Add the same in gdb.base/index-cache.exp, where this is also required.
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>
projects / thirdparty / binutils-gdb.git / log
