Tom Tromey [Fri, 26 Apr 2024 16:32:07 +0000 (10:32 -0600)]
Remove fflush call from tui_refresh_cmd_win
tui_refresh_cmd_win calls fflush, but there's a comment explaining
that the reason for the call is unknown. This patch removes the call.
I don't think it can be useful, since gdb doesn't generally use stdout
in this way -- only through ui_file.
Andrew Burgess [Sat, 11 May 2024 08:44:07 +0000 (09:44 +0100)]
gdb/doc: don't delete *.pod files too early
When doing 'make -C gdb/doc man' to build the man pages, I noticed
that the outputs were being rebuilt each time the make command was
rerun, even when the input files hadn't changed.
Which split the generation of the .pod file from the actual creation
of the man page file. Prior to this split it was OK to delete the
.pod file at the end of the recipe, the rule depending on the .texi
input file, and output was the .1 or .5 man page file.
Now however, with the split, the man page creation depends on the .pod
file, if we delete this after creating the .1 or .5 man page file then
the next time we run 'make' the .pod file is missing and is
regenerated, which in turn triggers the regeneration of the man page
file.
Fix this by leaving the .pod file around, and only cleaning up these
files in the 'mostlyclean' target.
Which leads to a second problem, the POD_FILE_TMPS is not created
correctly, so we don't actually clean up the .pod files! This too is
fixed in this commit.
After this commit running 'make -C gdb/doc man' will build the manual
pages the first time, and each subsequent run will do nothing.
Running 'make -C gdb/doc mostlyclean' will now delete the .pod files.
While working on another patch I needed to pass -Wl,-soname,NAME as a
compiler flag. I initially looked for other tests that did this, and
found a few examples, so I copied what they did.
But when I checked the gdb.log file I noticed that we were actually
getting -Wl,-soname passed twice.
I tracked the repeated option to 'proc gdb_compile_shlib_1' in
lib/gdb.exp. It turns out that we always add -Wl,-soname when
compiling a shared library.
Here's an example of a build command from gdb.base/prelink.exp:
I believe that all of the places where tests add '-Wl,-soname,NAME' as
a build option, are unnecessary.
In this commit I propose we remove them all.
As part of this change I've switched from calling gdb_compile_shlib
directly, to instead call build_executable and adding the 'shlib'
flag.
I've tested with gcc and clang and see no changes in the test results
after this commit. All the compile commands still have -Wl,-soname
added, but now it's only added once, from within lib/gdb.exp.
There should be no change in what is tested after this commit.
Jason Merrill [Fri, 10 May 2024 20:33:20 +0000 (16:33 -0400)]
Adjust C++ destructor type tests
In gcc-15-95-ga12cae97390 I dropped the unnecessary artificial "in-charge"
parameter from destructors of classes with no virtual bases; Linaro's CI
informed me that the gdb testsuite needs to be adjusted to match.
Fix Segmentation Fault in AIX during multi process debugging.
Due to the recent commit in aix-thread.c, we see a segmentation fault
in AIX while debugging multiple process involving multiple threads.
One example is a thread that can fork. The GDB output in AIX for the same is
Reading symbols from //gdb_tests/multi-thread-fork...
(gdb) set detach-on-fork off
(gdb) r
Starting program: /gdb_tests/multi-thread-fork
[New Thread 258 (tid 67110997)]
[New Thread 515 (tid 127404289)]
[New inferior 2 (process 16580940)]
Hello from Parent!
[process 16580940 exited]
[New inferior 3 (process 14549318)]
Hello from Parent!
[process 14549318 exited]
Fatal signal: Segmentation fault
----- Backtrace -----
This is because in sync_threadlists () in aix-thread.c there when we
delete threads in unknown state we iterate through all the threads.
When we have one or more threads with the same user thread ID but of different
process then we delete a wrong thread. Since we just check only the pdtid
in in_queue_threads.count (priv->pdtid) == 0 this happened.
This patch is a fix for the same.
The output after we apply this patch is:
Reading symbols from //gdb_tests/multi-thread-fork...
(gdb) set detach-on-fork off
(gdb) r
Starting program: /gdb_tests/multi-thread-fork
[New Thread 258 (tid 75565441)]
[New Thread 515 (tid 63244397)]
[New inferior 2 (process 10813892)]
Hello from Parent!
[New inferior 3 (process 19005888)]
Hello from Parent!
Thread 1.1 received signal SIGINT, Interrupt.
0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
(gdb) info threads
Id Target Id Frame
* 1.1 Thread 1 (tid 66062355) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
1.2 Thread 258 (tid 75565441) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50
1.3 Thread 515 (tid 63244397) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50
2.1 Thread 515 (tid 32113089) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o)
3.1 Thread 258 (tid 64489699) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o)
(gdb) q
A debugging session is active.
Richard Earnshaw [Mon, 29 Apr 2024 12:59:38 +0000 (13:59 +0100)]
arm: opcodes: remove Maverick disassembly.
Remove the patterns to match Maverick co-processor instructions from
the disassembly tables.
This required fixing a couple of tests in the assembler testsuite
where we, probably incorrectly, disassembled generic co-processor
instructions as a Maverick instruction (it particularly made no sense
to do this for Armv6t2 in Thumb state).
Richard Earnshaw [Mon, 29 Apr 2024 12:27:30 +0000 (13:27 +0100)]
arm: remove Maverick support from the assembler.
Delete all the Maverick instructions and register handling from the
assembler. We continue to recognize -mcpu=ep9312, but treat it as an
alias for arm920t. We no-longer recognize -mfpu=maverick.
Tom de Vries [Sat, 11 May 2024 07:56:45 +0000 (09:56 +0200)]
[gdb/testsuite] Fix Wreturn-mismatch in gdb.base/list-dot-nodebug.exp
When running test-case gdb.base/list-dot-nodebug.exp in a fedora rawhide
container, I run into:
...
temp/$pid/static-libc.c: In function 'main':
temp/$pid/static-libc.c:2:42: error: 'return' with a value, in function
returning void [-Wreturn-mismatch]
2 | void main (void) { return 0; }
| ^
...
UNTESTED: gdb.base/list-dot-nodebug.exp: Can't statically link
...
Tom Tromey [Wed, 24 Apr 2024 16:03:08 +0000 (10:03 -0600)]
Add symbol, line, and location to DAP disassemble result
The DAP spec allows a number of attributes on the resulting
instructions that gdb currently does not emit. A user requested some
of these, so this patch adds the 'symbol', 'line', and 'location'
attributes. While the spec lets the implementation omit 'location' in
some cases, it was simpler in the code to just always emit it, as then
no extra tracking was needed.
Tom Tromey [Wed, 24 Apr 2024 17:58:38 +0000 (11:58 -0600)]
Implement tp_richcompare for gdb.Block
I noticed that two gdb.Block objects will never compare as equal with
'=='. This patch fixes the problem by implementing tp_richcompare, as
was done for gdb.Frame.
Tom Tromey [Wed, 24 Apr 2024 15:53:55 +0000 (09:53 -0600)]
Simplify DAP make_source callers
A couple callers of make_source call basename by hand. Rather than
add another caller like this, I thought it would be better to put this
ability into make_source itself.
Alan Modra [Fri, 10 May 2024 12:45:06 +0000 (22:15 +0930)]
Re: PR31692, objdump fails .debug_info size check
The fuzzers found a hole. bfd_section_size_insane doesn't check
!SEC_HAS_CONTENTS sections against file size for obvious reasons,
which allows fuzzed debug sections to be stupidly large. Real debug
sections of course always have contents.
PR 31692
* objdump.c (load_specific_debug_section): Don't allow sections
without contents.
Andrew Burgess [Sun, 5 May 2024 10:00:04 +0000 (11:00 +0100)]
gdb: add gdbarch_stack_grows_down function
In another patch I'm working on I needed to ask: does the stack grow
down, or grow up?
Looking around I found in infcall.c some code where we needed to ask
the same question, what we do there is ask:
gdbarch_inner_than (gdbarch, 1, 2)
which should do the job. However, I don't particularly like copying
this, it feels like we're asking something slightly different that
just happens to align with the question we're actually asking.
I propose adding a new function `gdbarch_stack_grows_down`. This is
not going to be a gdbarch method that can be overridden, instead, this
will just call the gdbarch_inner_than function. We already have some
gdbarch methods like this, checkout arch-utils.c for examples.
I think it's now clearer what we're actually doing.
A new self-test ensures that all architectures have a stack that
either grows down, or grows up.
There should be no user visible changes after this commit.
Pedro Alves [Thu, 9 May 2024 12:01:53 +0000 (13:01 +0100)]
gdb sim testing, set gdb_protocol to "sim"
Bernd reported that when testing with riscv-unknown-elf target using
the simulator, before commit c7a2ee649115 ("gdb_is_target_native ->
gdb_protocol_is_native"), he had:
PASS: gdb.base/load-command.exp: probe for target native
PASS: gdb.base/load-command.exp: check initial value of the_variable
PASS: gdb.base/load-command.exp: manually change the_variable
PASS: gdb.base/load-command.exp: check manually changed value of the_variable
PASS: gdb.base/load-command.exp: reload: re-load binary
PASS: gdb.base/load-command.exp: reload: check initial value of the_variable
and now:
UNSUPPORTED: gdb.base/load-command.exp: the native target does not support the load command
The problem is that the sim board/config isn't setting gdb_protocol
anywhere, so gdb_protocol_is_native returns true.
This commit fixes it by making gdb/testsuite/config/sim.exp set
gdb_protocol to "sim".
Tom de Vries [Fri, 10 May 2024 06:46:21 +0000 (08:46 +0200)]
[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust (fixup)
In commit 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register
more robust") I added this code in unwind_infopy_add_saved_register:
...
if (value->optimized_out () || !value->entirely_available ())
...
which may throw c++ exceptions.
This needs to be caught and transformed into a python exception.
Fix this by using GDB_PY_HANDLE_EXCEPTION.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com> Fixes: 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust")
Bernd Edlinger [Thu, 9 May 2024 05:58:08 +0000 (07:58 +0200)]
sim: riscv: Fix build issue due to recent binutils commit
The commit c144f6383379 removed INSN_CLASS_A and
added INSN_CLASS_ZAAMO and INSN_CLASS_ZALRSC instead,
which broke the build of the sim for riscv targets.
Fix that by using the new INSN_CLASS types.
Fixes: c144f6383379 ("RISC-V: Support B, Zaamo and Zalrsc extensions.") Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Mon, 6 May 2024 18:54:27 +0000 (19:54 +0100)]
gdb: add a new build_id_equal function
Add two versions of a new function build_id_equal which can be used to
compare build-ids, then make use of these functions in GDB. It seems
better to have a specific function for the task of comparing build-ids
rather than having a length check followed by a memcmp call.
There should be no user visible changes after this commit.
When running 'make check', the default gprofng test suite creates a
shell script for which it used a hardcoded shebang of '/usr/bin/bash'
this script would not run if bash is in a different location, like
/bin/bash
This commit adds 'AC_PATH_PROG(BASH, bash)' to configure.ac so the
installation path of bash is detected at configuration time. The
configuration is propagated to the runtest command line where it is
needed.
Andrew Burgess [Fri, 12 Apr 2024 16:47:20 +0000 (17:47 +0100)]
gdb/doc: use silent-rules.mk in the Makefile
Make use of silent-rules.mk when building the GDB docs.
During review it was requested that there be more specific rules than
just reusing the general 'GEN' rule everywhere in the doc/ directory,
so I've added:
Then I've made use of these new silent rules and added lots of uses of
SILENT to reduce additional clutter.
As the man page generation is done in two phases, first the creation
of a .pod file, then the creation of the final man page file, I've
restructured the man page rules. Previously we had one rule for each
of the 5 man pages. I now have one general rule that will generate
all of the 5 .pod files, then I have two rules that convert the .pod
files into the final man pages.
I needed two rules for the man page generation as some man pages match
%.1 and some match %.5. I could combine these by using the GNU Make
.SECONDARYEXPANSION extension, but I think having two rules like this
is probably clearer, and the duplication is minimal.
Cleaning up the temporary .pod files is now moved into the
'mostlyclean' target rather than being done as soon as the man page is
created.
I've added a new SILENT_Q_FLAG to silent-rules.mk, this is like
SILENT_FLAG, but is set to '-q' when in silent mode, this can be used
with the 'dvips' and 'texi2dvi' commands, both of which use '-q' to
mean: only report errors.
As with the rest of the GDB makefiles, I've only converted the
"generation" rules to use silent-rules.mk, the install / uninstall
rules are left unchanged.
When looking at the 'diststuff' target, which generates the info and
man pages, I noticed the recipe for this rule just deleted a temporary
file. As that temporary file is already cleaned up as part of the
'clean' rule I've removed the deletion from the 'diststuff' target.
There are still a few "generation" targets that produce output, there
seems to be no flag to silence the 'tex' and 'pdftex' commands which
some recipes use, I've not worried about these for now, e.g. the
refcard.dvi and refcard.pdf targets still produce some output.
Luckily, when doing a 'make all' in the gdb/ directory, we only build
the info docs by default, and those rules are now nice and silent, so
a complete GDB build is now looking nice and quiet by default.
While working on this patch I noticed that 'make -j all-doc' doesn't
work (reliably), this is a preexisting bug in the way that dvi/pdf
targets are generated. For example gdb.dvi and gdb.pdf both use the
texi2dvi tool, which relies on temporary files to hold state. If both
these rules run in parallel then one (or both) of the recipes will
fail.
Luckily, the default docs target (all), which is what gets run when we
do 'make all' in the gdb/ directory, doesn't build the dvi and pdf
targets, so we're OK in that case.
I've not tried to fix this problem in this commit as it already
existed, and I don't want to do too much in one commit. I mention it
only because I ran into this issue while testing this commit.
Guinevere Larsen [Tue, 13 Feb 2024 14:36:23 +0000 (15:36 +0100)]
gdb: Change "list ." command's error when no debuginfo is available
Currently, when a user tries to list the current location, there are 2
different error messages that can happen, either:
(gdb) list .
No symbol table is loaded. Use the "file" command.
or
(gdb) list .
No debug information available to print source lines.
The difference here is if gdb can find any symtabs at all or not, which
is not something too important for end-users - and isn't informative at
all. This commit changes it so that the error always says that there
isn't debug information available, with these two variants:
(gdb) list .
Insufficient debug info for showing source lines at current PC (0x55555555511d).
or
(gdb) list .
Insufficient debug info for showing source lines at default location.
The difference now is if the inferior has started already, which is
controlled by the user and may be useful.
Unfortunately, it isn't as easy to differentiate if the symtab found for
other list parameters is correct, so other invocations, such as "list +"
still retain their original error message.
Co-Authored-By: Simon Marchi <simark@simark.ca> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
Fix AIX thread exit events not being reported and UI to show kernel thread ID.
In AIX when a thread exits we were not showing that a thread exit event happened
and GDB continued to keep the terminated threads.
If we have terminated threads then the UI on info threads command will look like
(gdb) info threads
Id Target Id Frame
* 1 Thread 1 (tid 26607979, running) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthreads.a(_shr_xpg5.o)
2 Thread 258 (tid 30998799, finished) aix-thread: ptrace (52, 30998799) returned -1 (errno = 3 The process does not exist.)
If we see the frame is not getting displayed correctly.
The reason for the same is that in AIX we were not managing thread states. In particular we do not know
when a thread terminates.
The reason being in sync_threadlists () the pbuf and gbuf lists remain the same though certain threads exit.
This patch is a fix to the same.
Also certain UI is changed.
On a new thread born and exit the UI in AIX will be similar to Linux with both user and kernel thread information.
and info threads will look like
(gdb) info threads
Id Target Id Frame
* 1 Thread 1 (tid 31326579) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
Also a small change to testcase gdb.threads/thread_events.exp to make sure this test runs on AIX as well.
Tom de Vries [Wed, 8 May 2024 12:13:11 +0000 (14:13 +0200)]
[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust
On arm-linux, until commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register
from non-FreeBSD target descriptions") I ran into:
...
FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: \
backtrace when the unwind is broken at frame 5
...
What happens is the following:
- the TestUnwinder from inline-frame-cycle-unwind.py calls
gdb.UnwindInfo.add_saved_register with reg == tpidruro and value
"<unavailable>",
- pyuw_sniffer calls value->contents ().data () to access the value of the
register, which throws an UNAVAILABLE_ERROR,
- this causes the TestUnwinder unwinder to fail, after which another unwinder
succeeds and returns the correct frame, and
- the test-case fails because it's counting on the TestUnwinder to succeed and
return an incorrect frame.
Fix this by checking for !value::entirely_available as well as
valued::optimized_out in unwind_infopy_add_saved_register.
Tested on x86_64-linux and arm-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR python/31437
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31437
Nelson Chu [Mon, 5 Feb 2024 01:39:37 +0000 (09:39 +0800)]
RISC-V: Support B, Zaamo and Zalrsc extensions.
* https://github.com/riscv/riscv-b/tags
Added standard B extension back, which implies Zba, Zbb and Zbs extensions.
* https://github.com/riscv/riscv-zaamo-zalrsc/tags
Splited standard A extension into two new extensions, Zaamo and Zalrsc.
The A extension implies Zaamo and Zalrsc extensions.
Not sure if we need to do the similar check as i and zicsr/zifencei.
==28392== Invalid read of size 1
==28392== at 0x79E97E: lookup_global_or_static_symbol(char const*, block_enum, objfile*, domain_enum) (symtab.h:503)
==28392== by 0x79F859: lookup_global_symbol(char const*, block const*, domain_enum) (symtab.c:2641)
==28392== by 0x79F8E9: language_defn::lookup_symbol_nonlocal(char const*, block const*, domain_enum) const (symtab.c:2473)
==28392== by 0x7A66EE: lookup_symbol_aux(char const*, symbol_name_match_type, block const*, domain_enum, language, field_of_this_result*) (symtab.c:2150)
==28392== by 0x7A68C9: lookup_symbol_in_language(char const*, block const*, domain_enum, language, field_of_this_result*) (symtab.c:1958)
==28392== by 0x7A6A25: lookup_symbol(char const*, block const*, domain_enum, field_of_this_result*) (symtab.c:1970)
==28392== by 0x77120F: select_source_symtab() (source.c:319)
==28392== by 0x7EE2D5: tui_get_begin_asm_address(gdbarch**, unsigned long*) (tui-disasm.c:401)
==28392== by 0x807558: tui_display_main() (tui-winsource.c:55)
==28392== by 0x7937B5: clear_symtab_users(enum_flags<symfile_add_flag>) (functional:2464)
==28392== by 0x794F40: reread_symbols(int) (symfile.c:2690)
==28392== by 0x6497D1: run_command_1(char const*, int, run_how) (infcmd.c:398)
==28392== Address 0x4e67848 is 3,864 bytes inside a block of size 4,064 free'd
==28392== at 0x4A0A430: free (vg_replace_malloc.c:446)
==28392== by 0x936B63: _obstack_free (obstack.c:280)
==28392== by 0x79541E: reread_symbols(int) (symfile.c:2579)
==28392== by 0x6497D1: run_command_1(char const*, int, run_how) (infcmd.c:398)
==28392== by 0x4FFC45: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:2735)
==28392== by 0x7DAB50: execute_command(char const*, int) (top.c:575)
==28392== by 0x5D2B43: command_handler(char const*) (event-top.c:552)
==28392== by 0x5D3A50: command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) (event-top.c:788)
==28392== by 0x5D1F4B: gdb_rl_callback_handler(char*) (event-top.c:259)
==28392== by 0x857B3F: rl_callback_read_char (callback.c:290)
==28392== by 0x5D215D: gdb_rl_callback_read_char_wrapper_noexcept() (event-top.c:195)
==28392== by 0x5D232F: gdb_rl_callback_read_char_wrapper(void*) (event-top.c:234)
The problem is that tui_display_main is called by the all_objfiles_removed
hook, which tries to access the symbol cache.
This symbol cache is actually stale at this point, and would have been
flushed immediately afterwards by that same all_objfiles_removed hook.
It's not possible to tell the hook to call the observers in a specific
order, but in this case the tui_all_objfiles_removed observer is actually
not needed, since it only calls tui_display_main, and a 'main' can only
be found if objfiles are added, not removed.
So the fix is to simply remove the tui_all_objfiles_removed observer.
The clearing of the source window (if symbols were removed by e.g. 'file'
without arguments) still works, since this is done by the
tui_before_prompt observer.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31697 Approved-By: Tom Tromey <tom@tromey.com>
gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32
I worried that there could be other paths that might result in an xcr0
value which has X86_XSTATE_MPX set in x32 mode. As everyone
eventually calls amd64_create_target_description to build their target
description, I figured we could assert in here that if X86_XSTATE_MPX
is set then we should not be an x32 target, this will uncover any
other bugs in this area.
I'm not currently able to build/run any x32 binaries, so I have no way
to test this, but the author of commit 4bb20a6244b7091 did test this
series with that assert in place and didn't see any problems.
Andrew Burgess [Thu, 25 Jan 2024 14:10:42 +0000 (14:10 +0000)]
gdbserver: convert have_ptrace_getregset to a tribool
Convert the have_ptrace_getregset global within gdbserver to a
tribool. This brings the flag into alignment with the corresponding
flag in GDB.
The gdbserver have_ptrace_getregset variable is already used as a
tribool, it just doesn't have the tribool type.
In a future commit I plan to share more code between GDB and
gdbserver, and having this variable be the same type in both code
bases will make the sharing much easier.
There should be no user visible changes after this commit.
Approved-By: John Baldwin <jhb@FreeBSD.org> Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
Andrew Burgess [Tue, 2 Apr 2024 12:42:37 +0000 (13:42 +0100)]
gdbserver/ipa/x86: remove unneeded declarations
Spotted some declarations in gdbserver/linux-amd64-ipa.cc that are no
longer needed. These are:
1. 'init_registers_amd64_linux' - the comment claims this function
is auto generated, but I don't believe that this is still the case.
Also the function is not used in this file,
2. 'tdesc_amd64_linux' - this variable doesn't seem to exist any
more, I suspect this was renamed to 'tdesc_amd64_linux_no_xml', but
neither are used in this file, so lets remove the declaration.
The amd64 in-process-agent still builds fine after this commit.
There should be no user visible changes after this commit.
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
Pedro Alves [Tue, 7 May 2024 11:30:39 +0000 (12:30 +0100)]
gdb.base/watchpoint-running.exp: Run sw watch tests even if no hw watch
The code in gdb.base/watchpoint-running.exp that is trying to skip
testing with hardware watchpoints also skips testing with software
watchpoints if hardware watchpoints aren't supported by the target.
This fixes it.
The issue is that the body to execute under the lock is executed in the
context of with_rocm_gpu_lock (uplevel 1 used in with_lock) instead of
in the context of the "original" caller.
This patch adjusted with_rocm_gpu_lock to account for the new extra
frame in the call stack between the caller of with_rocm_gpu_lock and
where the code execution is triggered.
Approved-By: Tom de Vries <tdevries@suse.de>
Change-Id: I79ce2c9615012215867ed5bb60144abe7dce28fe
Lulu Cai [Tue, 23 Apr 2024 07:49:09 +0000 (15:49 +0800)]
LoongArch: Fix ld test failures caused by using instruction aliases
Different versions of objdump may take different forms of output
for instructions. Use -M no-aliases to avoid the failure of ld
test cases caused by objdump using aliases.
Bernd Edlinger [Mon, 6 May 2024 05:07:07 +0000 (07:07 +0200)]
Fix build issues with mingw toolchain
With a x86_64-pc-mingw32 toolchain there is a build issue
whether or not the --disable-threading option is used.
The problem happens because _WIN32_WINNT is defined to 0x501
before #include <mutex> which makes the compilation abort
due to missing support for __gthread_cond_t in std_mutex.h,
which is conditional on _WIN32_WINNT >= 0x600.
Fix the case when --disable-threading is used, by only
including <mutex> in gdb/complaints.c when STD_CXX_THREAD
is defined.
Additionally make the configure script try to #include <mutex>
to automatically select --disable-threading when the header file
is not able to compile.
Tom de Vries [Mon, 6 May 2024 12:23:25 +0000 (14:23 +0200)]
[gdb/exp] Redo cast handling for indirection
In commit ed8fd0a342f ("[gdb/exp] Fix cast handling for indirection"), I
introduced the behaviour that even though we have:
...
(gdb) p *a_loc ()
'a_loc' has unknown return type; cast the call to its declared return type
...
we get:
...
(gdb) p (char)*a_loc ()
$1 = 97 'a'
...
In other words, the unknown return type of a_loc is inferred from the cast,
effectually evaluating:
...
(gdb) p (char)*(char *)a_loc ()
...
This is convient for the case that errno is defined as:
...
#define errno (*__errno_location ())
...
and the return type of __errno_location is unknown but the macro definition is
known, such that we can use:
...
(gdb) p (int)errno
...
instead of
...
(gdb) p *(int *)__errno_location ()
...
However, as Pedro has pointed out in post-commit review [1], this makes it
harder to reason about the semantics of an expression.
For instance, this:
...
(gdb) p (long long)*a_loc ()"
...
would be evaluated without debug info as:
...
(gdb) p (long long)*(long long *)a_loc ()"
...
but with debug info as:
...
(gdb) p (long long)*(char *)a_loc ()"
...
Fix this by instead simply erroring out for this case:
...
(gdb) p (char)*a_loc ()
'a_loc' has unknown return type; cast the call to its declared return type
...
Tested on x86_64-linux.
Approved-By: Pedro Alves <pedro@palves.net>
[1] https://sourceware.org/pipermail/gdb-patches/2024-May/208821.html
x86: Drop using extension_opcode to encode vvvv register
gas/ChangeLog:
* config/tc-i386.c (build_modrm_byte): Dropped the use of
extension_opcode to encode the vvvv register.
* testsuite/gas/i386/x86-64-sse2avx.d: Added new testcases.
* testsuite/gas/i386/x86-64-sse2avx.s: Diito.
opcodes/ChangeLog:
* i386-opc.tbl: Added DstVVVV to some extension_opcode instructions.
* i386-tbl.h: Regenerated.
Cui, Lili [Mon, 6 May 2024 06:15:49 +0000 (14:15 +0800)]
x86: Use vexvvvv as the switch state to encode the vvvv register
Use vexvvvv as the switch state, and replace VexVVVV with Src1VVVV.
Src1VVVV means using VEX.vvvv encodes the first source register
operand. The old logic did not check vexvvvv first, which made the
logic here very complicated.
gas/ChangeLog:
* config/tc-i386.c (optimize_encoding): Replaced 1 with Src1VVVV.
(build_modrm_byte): Used vexvvvv to encode the vvvv register.
(s_insn): Replaced 1 with Src1VVVV.
opcodes/ChangeLog:
* i386-opc.h (VexVVVV_DST): Adjusted the value.
(Src1VVVV): New.
* i386-opc.tbl: Replaced part VexVVVV with Src1VVVV.
* i386-tbl.h: Regenerated.
Hannes Domani [Sat, 4 May 2024 16:55:20 +0000 (18:55 +0200)]
Fix heap-use-after-free in index-cached with --disable-threading
If threads are disabled, either by --disable-threading explicitely, or by
missing std::thread support, you get the following ASAN error when
loading symbols:
==7310==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000002128 at pc 0x00000098794a bp 0x7ffe37e6af70 sp 0x7ffe37e6af68
READ of size 1 at 0x614000002128 thread T0
#0 0x987949 in index_cache_store_context::store() const ../../gdb/dwarf2/index-cache.c:163
#1 0x943467 in cooked_index_worker::write_to_cache(cooked_index const*, deferred_warnings*) const ../../gdb/dwarf2/cooked-index.c:601
#2 0x1705e39 in std::function<void ()>::operator()() const /gcc/9/include/c++/9.2.0/bits/std_function.h:690
#3 0x1705e39 in gdb::task_group::impl::~impl() ../../gdbsupport/task-group.cc:38
0x614000002128 is located 232 bytes inside of 408-byte region [0x614000002040,0x6140000021d8)
freed by thread T0 here:
#0 0x7fd75ccf8ea5 in operator delete(void*, unsigned long) ../../.././libsanitizer/asan/asan_new_delete.cc:177
#1 0x9462e5 in cooked_index::index_for_writing() ../../gdb/dwarf2/cooked-index.h:689
#2 0x9462e5 in operator() ../../gdb/dwarf2/cooked-index.c:657
#3 0x9462e5 in _M_invoke /gcc/9/include/c++/9.2.0/bits/std_function.h:300
It's happening because cooked_index_worker::wait always returns true in
this case, which tells cooked_index::wait it can delete the m_state
cooked_index_worker member, but cooked_index_worker::write_to_cache tries
to access it immediately afterwards.
Fixed by making cooked_index_worker::wait only return true if desired_state
is CACHE_DONE, same as if threading was enabled, so m_state will not be
prematurely deleted.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31694 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Mon, 1 Apr 2024 23:03:45 +0000 (17:03 -0600)]
Remove call to dwarf2_per_objfile::adjust from read_attribute_value
Currently, read_attribute_value calls dwarf2_per_objfile::adjust on
any address. This seems wrong, because the address may not even be in
the text section.
Luckily, this call is also not needed, because read_func_scope calls
'relocate', which does the same work.
Tom Tromey [Mon, 1 Apr 2024 23:05:18 +0000 (17:05 -0600)]
Remove call to dwarf2_per_objfile::adjust from read_call_site_scope
read_call_site_scope does not need to call 'adjust', because in
general the call site is not a symbol address, but rather just the
address of some particular call.
Tom Tromey [Fri, 8 Mar 2024 20:37:50 +0000 (13:37 -0700)]
Remove more calls to dwarf2_per_objfile::adjust
As with the previous patch, this patch removes some calls to
dwarf2_per_objfile::adjust. These calls are not needed by the cooked
indexer, as it does not create symbols or look up symbols by address.
The call in dwarf2_ranges_read is similarly not needed, as it is only
used to update an addrmap; and in any case I believe this particular
call is only reached by the indexer.
Tom Tromey [Mon, 1 Apr 2024 23:00:21 +0000 (17:00 -0600)]
Remove call to dwarf2_per_objfile::adjust from ranges readers
dwarf2_per_objfile::adjust applies gdbarch_adjust_dwarf2_addr to an
address, leaving the result unrelocated. However, this adjustment is
only needed for text-section symbols -- it isn't needed for any sort
of address mapping. Therefore, these calls can be removed from
read_addrmap_from_aranges and create_addrmap_from_gdb_index.
Tom de Vries [Sat, 4 May 2024 08:41:09 +0000 (10:41 +0200)]
[gdb/testsuite] Use unique portnum in parallel testing (check//% case)
Make target check//% is the gdb variant of a similar gcc make target [1].
When running tests using check//%:
...
$ cd build/gdb
$ make check//unix/{-fPIE/-pie,-fno-PIE/-no-pie} -j2 TESTS=gdb.server/*.exp
...
we get:
...
$ cat build/gdb/testsuite.unix.-fPIE.-pie/cache/portnum
2427
$ cat build/gdb/testsuite.unix.-fno-PIE.-no-pie/cache/portnum
2423
...
The problem is that there are two portnum files used in parallel.
Fix this by:
- creating a common lockdir build/gdb/testsuite.lockdir for make target
check//%,
- passing this down to the runtests invocations using variable GDB_LOCK_DIR,
and
- using GDB_LOCK_DIR in lock_dir.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31632
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31632
Tom de Vries [Sat, 4 May 2024 08:41:09 +0000 (10:41 +0200)]
[gdb/testsuite] Use unique portnum in parallel testing
When instrumenting get_portnum using:
...
puts "PORTNUM: $res"
...
and running:
...
$ cd build/gdb
$ make check-parallel -j2 TESTS=gdb.server/*.exp
...
we run into:
...
Running gdb.server/abspath.exp ...
PORTNUM: 2345
...
and:
...
Running gdb.server/bkpt-other-inferior.exp ...
PORTNUM: 2345
...
This is because the test-cases are run in independent runtest invocations.
Fix this by handling the parallel case in get_portnum using:
- a file $objdir/cache/portnum to keep the portnum variable, and
- a file $objdir/cache/portnum.lock to serialize access to it.
Tom de Vries [Sat, 4 May 2024 08:41:09 +0000 (10:41 +0200)]
[gdb/testsuite] Move gpu-parallel.lock to cache dir
The lock directory returned by lock_dir is currently $objdir.
It seems possible to leave a stale lock file that blocks progress in a
following run.
Fix this by using a directory that is guaranteed to be initially empty when
using GDB_PARALLEL, like temp or cache.
In gdb/testsuite/README I found:
...
cache in particular is used to share data across invocations of runtest
...
which seems appropriate, so let's use cache for this.
Tom de Vries [Sat, 4 May 2024 08:41:09 +0000 (10:41 +0200)]
[gdb/testsuite] Factor out proc get_portnum
In gdbserver_start, we have some code that determines what port number to use:
...
# Port id -- either specified in baseboard file, or managed here.
if [target_info exists gdb,socketport] {
set portnum [target_info gdb,socketport]
} else {
# Bump the port number to avoid conflicts with hung ports.
incr portnum
}
...
Pedro Alves [Fri, 3 May 2024 16:39:16 +0000 (17:39 +0100)]
Adjust gdb_continue_to_end for Windows
On Cygwin, supposely single-threaded programs are always
multi-threaded, due to the extra threads spawned by the Cygwin
runtime. Because of that, any gdb_continue_to_end call that doesn't
specify "allow_extra" fails, like so:
(gdb) PASS: gdb.base/langs.exp: show language at main
continue
Continuing.
[Thread 16140.0x1fbc exited with code 0]
[Thread 16140.0x2458 exited with code 0]
[Thread 16140.0x3494 exited with code 0]
[Inferior 1 (process 16140) exited normally]
(gdb) FAIL: gdb.base/langs.exp: continue until exit at first session (the program exited)
Similarly, with this simple program compiled with MinGW:
$ cat ~/sleeper.c
#include <windows.h>
int main ()
{
Sleep (2000);
return 0;
}
and with a MinGW GDB, I see:
(gdb) start
...
(gdb) info threads
Id Target Id Frame
* 1 Thread 15292.0x3850 main () at /home/alves/sleeper.c:5
2 Thread 15292.0x3048 0x00007ff9630d2fb7 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll
(gdb) c
Continuing.
[Thread 15292.0x3850 exited with code 0]
[Inferior 1 (process 15292) exited normally]
(gdb)
This commit adjusts gdb_continue_to_end to expect the thread exited
messages, on Cygwin and MinGW.
Change-Id: I5e410a7252c11cd9ecea632f1e00c2a7fcd69098 Approved-By: Andrew Burgess <aburgess@redhat.com>
Commit 0ee25f97d21e ("Fix regression on aarch64-linux gdbserver")
removed the last use of i in gdbserver/linux-aarch64-low.cc
(aarch64_target::low_stopped_data_address). Breaking the build on
aarch64 with:
gdbserver/linux-aarch64-low.cc: In member function ?virtual CORE_ADDR aarch64_target::low_stopped_data_address()?:
gdbserver/linux-aarch64-low.cc:557:12: error: unused variable ?i? [-Werror=unused-variable]
557 | int pid, i;
| ^
cc1plus: all warnings being treated as errors
Fix this by removing the variable i completely.
Fixes: 0ee25f97d21e ("Fix regression on aarch64-linux gdbserver")
Tom de Vries [Fri, 3 May 2024 13:07:33 +0000 (15:07 +0200)]
[gdb/testsuite] Use save_vars to restore GDBFLAGS
There's a pattern of using:
...
set saved_gdbflags $GDBFLAGS
set GDBFLAGS "$GDBFLAGS ..."
<do something with GDBFLAGS>
set GDBFLAGS $saved_gdbflags
...
Simplify this by using save_vars:
...
save_vars { GDBFLAGS } {
set GDBFLAGS "$GDBFLAGS ..."
<do something with GDBFLAGS>
}
...
Tom de Vries [Fri, 3 May 2024 13:07:33 +0000 (15:07 +0200)]
[gdb/testsuite] Update INTERNAL_GDBFLAGS example
In commit 31c50280179 ("[gdb/testsuite] Add -q to INTERNAL_GDBFLAGS") I added
-q to the INTERNAL_GDBFLAGS, but I forgot to update the INTERNAL_GDBFLAGS
example in gdb/testsuite/README.
Tom de Vries [Fri, 3 May 2024 07:37:19 +0000 (09:37 +0200)]
[gdb/exp] Fix cast handling for indirection
Consider a test-case compiled without debug info, containing:
...
char a = 'a';
char *
a_loc (void)
{
return &a;
}
...
We get:
...
(gdb) p (char)*a_loc ()
Cannot access memory at address 0x10
...
There's a bug in unop_ind_base_operation::evaluate that evaluates
"(char)*a_loc ()" the same as:
...
(gdb) p (char)*(char)a_loc ()
Cannot access memory at address 0x10
...
Fix this by instead evaluating it the same as:
...
(gdb) p (char)*(char *)a_loc ()
$1 = 97 'a'
...
Jan Beulich [Fri, 3 May 2024 07:27:25 +0000 (09:27 +0200)]
x86: tidy <sse*> templates
Some of them no longer need a separate vvvv attribute, thus allowing
them to be simplified. For <aes> the situation is slightly different:
None of the remaining uses make use of vvvv anymore.
Jan Beulich [Fri, 3 May 2024 07:27:00 +0000 (09:27 +0200)]
x86/APX: further extend SSE2AVX coverage
Since {vex}/{vex3} are respected on legacy mnemonics when -msse2avx is
in use, {evex} should be respected, too. So far this is the case only
for insns where eGPR-s can come into play. Extend coverage to insns with
only %xmm register and possibly immediate operands.
Jan Beulich [Fri, 3 May 2024 07:26:25 +0000 (09:26 +0200)]
x86/APX: extend SSE2AVX coverage
Legacy encoded SIMD insns are converted to AVX ones in that mode. When
eGPR-s are in use, i.e. with APX, convert to AVX10 insns (where
available; there are quite a few which can't be converted).
Note that LDDQU is represented as VMOVDQU32 (and the prior use of the
sse3 template there needs dropping, to get the order right).
Note further that in a few cases, due to the use of templates, AVX512VL
is used when AVX512F would suffice. Since AVX10 is the main reference,
this shouldn't be too much of a problem.
Jan Beulich [Fri, 3 May 2024 07:24:48 +0000 (09:24 +0200)]
x86: zap value-less Disp8MemShift from non-EVEX templates
In order to allow to continue to use templatized SSE2AVX templates when
enhancing those to also cover eGPR usage, Disp8MemShift wants using to
deviate from what general template attributes supply. That requires
using Disp8MemShift in a way also affecting non-EVEX templates, yet
having this attribute set would so far implicitly mean EVEX encoding.
Recognize the case and instead zap the attribute if no other attribute
indicates EVEX encoding.
Tom Tromey [Fri, 19 Apr 2024 13:54:19 +0000 (07:54 -0600)]
Fix regression on aarch64-linux gdbserver
Commit 9a03f218 ("Fix gdb.base/watchpoint-unaligned.exp on aarch64")
fixed a watchpoint bug in gdb -- but did not touch the corresponding
code in gdbserver.
This patch moves the gdb code into gdb/nat, so that it can be shared
with gdbserver, and then changes gdbserver to use it, fixing the bug.
This is yet another case where having a single back end would prevent
bugs.
I tested this using the AdaCore internal gdb testsuite.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423 Approved-By: Luis Machado <luis.machado@arm.com>
Tom de Vries [Wed, 1 May 2024 09:46:05 +0000 (11:46 +0200)]
[gdb/testsuite] Fix stray file in get_compiler_info
When running test-case gdb.dwarf2/gdb-index-nodebug.exp with host board
local-remote-host and target board remote-gdbserver-on-localhost, I get:
...
$ ls build/gdb/testsuite
cache compiler.i config.log config.status gdb.log gdb.sum lib Makefile
outputs site.bak site.exp temp
...
The file compiler.i is there because get_compiler_info uses:
...
set ppout "$outdir/compiler.i"
...
The file is a temporary, and as such belongs in a temp dir. Fix this by using
standard_temp_file, moving the file to build/gdb/testsuite/temp/<pid>/compiler.i.
Tom de Vries [Wed, 1 May 2024 09:11:24 +0000 (11:11 +0200)]
[gdb/testsuite] Fix stray file in gdb.dwarf2/gdb-index-nodebug.exp
After running test-case gdb.dwarf2/gdb-index-nodebug.exp I have:
...
$ ls build/gdb/testsuite
cache config.status gdb.log lib outputs site.exp
config.log gdb-index-nodebug.gdb-index gdb.sum Makefile site.bak temp
...
The file gdb-index-nodebug.gdb-index doesn't belong there.
It happens to be there because we do:
...
set index_file ${testfile}.gdb-index
set cmd "save gdb-index [file dirname ${index_file}]"
...
which results in:
...
(gdb) save gdb-index .
...
The intention was possibly to use $binfile instead of $testfile, but using
that wouldn't work for remote host.
projects / thirdparty / binutils-gdb.git / log
