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.
Nelson Chu [Fri, 9 Jun 2023 00:47:17 +0000 (08:47 +0800)]
RISC-V: PR29823, defined the missing elf_backend_obj_attrs_handle_unknown.
bfd/
PR 29823
* elfnn-riscv.c (riscv_elf_obj_attrs_handle_unknown): New function.
(elf_backend_obj_attrs_handle_unknown): Defined to
riscv_elf_obj_attrs_handle_unknown.
Test behaviour of watchpoints triggered by libc's memset/memcpy/memmove.
These functions are frequently optimized with specialized instructions
that favor larger memory access operations, so make sure GDB behaves
correctly in their presence.
There's a separate watched variable for each function so that the testcase
can test whether GDB correctly identified the watchpoint that triggered.
Also, the watchpoint is 28 bytes away from the beginning of the buffer
being modified, so that large memory accesses (if present) are exercised.
gdb/nat/linux: Fix attaching to process when it has zombie threads
When GDB attaches to a multi-threaded process, it calls
linux_proc_attach_tgid_threads () to go through all threads found in
/proc/PID/task/ and call attach_proc_task_lwp_callback () on each of
them. If it does that twice without the callback reporting that a new
thread was found, then it considers that all inferior threads have been
found and returns.
The problem is that the callback considers any thread that it hasn't
attached to yet as new. This causes problems if the process has one or
more zombie threads, because GDB can't attach to it and the loop will
always "find" a new thread (the zombie one), and get stuck in an
infinite loop.
This is easy to trigger (at least on aarch64-linux and powerpc64le-linux)
with the gdb.threads/attach-many-short-lived-threads.exp testcase, because
its test program constantly creates and finishes joinable threads so the
chance of having zombie threads is high.
This problem causes the following failures:
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: attach (timeout)
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: no new threads (timeout)
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: set breakpoint always-inserted on (timeout)
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break break_fn (timeout)
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 1 (timeout)
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 2 (timeout)
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 3 (timeout)
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: reset timer in the inferior (timeout)
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: print seconds_left (timeout)
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: detach (timeout)
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: set breakpoint always-inserted off (timeout)
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: delete all breakpoints, watchpoints, tracepoints, and catchpoints in delete_breakpoints (timeout)
ERROR: breakpoints not deleted
The iteration number is random, and all tests in the subsequent iterations
fail too, because GDB is stuck in the attach command at the beginning of
the iteration.
The solution is to make linux_proc_attach_tgid_threads () remember when it
has already processed a given LWP and skip it in the subsequent iterations.
gdb/nat: Factor linux_proc_get_stat_field out of linux_common_core_of_thread
The new function will be used in a subsequent patch to read a different
stat field.
The new code is believed to be equivalent to the old code, so there
should be no change in GDB behaviour. The only material change was to
use std::string and string_printf rather than a fixed char array to
build the path to the stat file.
Also, take the opportunity to move the function's documentation comment to
the header file, to conform with GDB practice.
Reviewed-By: Luis Machado <luis.machado@arm.com> Approved-By: Pedro Alves <pedro@palves.net>
gdb/nat: Use procfs(5) indexes in linux_common_core_of_thread
The code and comment reference stat fields by made-up indexes. The
procfs(5) man page, which describes the /proc/PID/stat file, has a numbered
list of these fields so it's more convenient to use those numbers instead.
This is currently an implementation detail inside the function so it's
not really relevant with the code as-is, but a future patch will do some
refactoring which will make the index more prominent.
Therefore, make this change in a separate patch so that it's simpler to
review.
Reviewed-By: Luis Machado <luis.machado@arm.com> Approved-By: Pedro Alves <pedro@palves.net>
Andrew Burgess [Wed, 17 Apr 2024 13:47:49 +0000 (14:47 +0100)]
gdb/doc: document how filename arguments are formatted
In the following commits I intend to improve GDB's filename
completion. However, how filenames should be completed is a little
complex because GDB is not consistent with how it expects filename
arguments to be formatted.
This commit documents the current state of GDB when it comes to
formatting filename arguments.
Currently GDB will not correctly complete filenames inline with this
documentation; GDB will either fail to complete, or complete
incorrectly (i.e. the result of completion will not then be accepted
by GDB). However, later commits in this series will fix completion.
Introduced a bug in the error handling of the qRcmd packet. Prior to
this commit if a packet had status PACKET_OK then, if the packet
contained the text "OK" we considered the packet handled. But, if the
packet contained any other content (that was not an error message)
then the content was printed to the user.
After the above commit this was no longer the case, any non-error
packet that didn't contain "OK" would be treated as an error.
Currently, gdbserver doesn't exercise this path so it's not possible
to write a simple test for this case. When gdbserver wishes to print
output it sends back an 'O' string output packet, these packets are
handled earlier in the process. Then once gdbserver has finished
sending output an 'OK' packet is sent.
Tom Tromey [Sat, 27 Apr 2024 17:28:18 +0000 (11:28 -0600)]
Remove two unneeded forward declarations
I noticed a couple of forward declarations in the TUI that aren't
needed -- the declarations aren't used in the header files in which
they appear. This patch removes these.
Tom de Vries [Sat, 27 Apr 2024 15:48:22 +0000 (17:48 +0200)]
[gdb/remote] Fix abort on REMOTE_CLOSE_ERROR
When running test-case gdb.server/connect-with-no-symbol-file.exp on
aarch64-linux (specifically, an opensuse leap 15.5 container on a
fedora asahi 39 system), I run into:
...
(gdb) detach^M
Detaching from program: target:connect-with-no-symbol-file, process 185104^M
Ending remote debugging.^M
terminate called after throwing an instance of 'gdb_exception_error'^M
...
The detailed backtrace of the corefile is:
...
(gdb) bt
#0 0x0000ffff75504f54 in raise () from /lib64/libpthread.so.0
#1 0x00000000007a86b4 in handle_fatal_signal (sig=6)
at gdb/event-top.c:926
#2 <signal handler called>
#3 0x0000ffff74b977b4 in raise () from /lib64/libc.so.6
#4 0x0000ffff74b98c18 in abort () from /lib64/libc.so.6
#5 0x0000ffff74ea26f4 in __gnu_cxx::__verbose_terminate_handler() ()
from /usr/lib64/libstdc++.so.6
#6 0x0000ffff74ea011c in ?? () from /usr/lib64/libstdc++.so.6
#7 0x0000ffff74ea0180 in std::terminate() () from /usr/lib64/libstdc++.so.6
#8 0x0000ffff74ea0464 in __cxa_throw () from /usr/lib64/libstdc++.so.6
#9 0x0000000001548870 in throw_it (reason=RETURN_ERROR,
error=TARGET_CLOSE_ERROR, fmt=0x16c7810 "Remote connection closed", ap=...)
at gdbsupport/common-exceptions.cc:203
#10 0x0000000001548920 in throw_verror (error=TARGET_CLOSE_ERROR,
fmt=0x16c7810 "Remote connection closed", ap=...)
at gdbsupport/common-exceptions.cc:211
#11 0x0000000001548a00 in throw_error (error=TARGET_CLOSE_ERROR,
fmt=0x16c7810 "Remote connection closed")
at gdbsupport/common-exceptions.cc:226
#12 0x0000000000ac8f2c in remote_target::readchar (this=0x233d3d90, timeout=2)
at gdb/remote.c:9856
#13 0x0000000000ac9f04 in remote_target::getpkt (this=0x233d3d90,
buf=0x233d40a8, forever=false, is_notif=0x0) at gdb/remote.c:10326
#14 0x0000000000acf3d0 in remote_target::remote_hostio_send_command
(this=0x233d3d90, command_bytes=13, which_packet=17,
remote_errno=0xfffff1a3cf38, attachment=0xfffff1a3ce88,
attachment_len=0xfffff1a3ce90) at gdb/remote.c:12567
#15 0x0000000000ad03bc in remote_target::fileio_fstat (this=0x233d3d90, fd=3,
st=0xfffff1a3d020, remote_errno=0xfffff1a3cf38)
at gdb/remote.c:12979
#16 0x0000000000c39878 in target_fileio_fstat (fd=0, sb=0xfffff1a3d020,
target_errno=0xfffff1a3cf38) at gdb/target.c:3315
#17 0x00000000007eee5c in target_fileio_stream::stat (this=0x233d4400,
abfd=0x2323fc40, sb=0xfffff1a3d020) at gdb/gdb_bfd.c:467
#18 0x00000000007f012c in <lambda(bfd*, void*, stat*)>::operator()(bfd *,
void *, stat *) const (__closure=0x0, abfd=0x2323fc40, stream=0x233d4400,
sb=0xfffff1a3d020) at gdb/gdb_bfd.c:955
#19 0x00000000007f015c in <lambda(bfd*, void*, stat*)>::_FUN(bfd *, void *,
stat *) () at gdb/gdb_bfd.c:956
#20 0x0000000000f9b838 in opncls_bstat (abfd=0x2323fc40, sb=0xfffff1a3d020)
at bfd/opncls.c:665
#21 0x0000000000f90adc in bfd_stat (abfd=0x2323fc40, statbuf=0xfffff1a3d020)
at bfd/bfdio.c:431
#22 0x000000000065fe20 in reopen_exec_file () at gdb/corefile.c:52
#23 0x0000000000c3a3e8 in generic_mourn_inferior ()
at gdb/target.c:3642
#24 0x0000000000abf3f0 in remote_unpush_target (target=0x233d3d90)
at gdb/remote.c:6067
#25 0x0000000000aca8b0 in remote_target::mourn_inferior (this=0x233d3d90)
at gdb/remote.c:10587
#26 0x0000000000c387cc in target_mourn_inferior (
ptid=<error reading variable: Cannot access memory at address 0x2d310>)
at gdb/target.c:2738
#27 0x0000000000abfff0 in remote_target::remote_detach_1 (this=0x233d3d90,
inf=0x22fce540, from_tty=1) at gdb/remote.c:6421
#28 0x0000000000ac0094 in remote_target::detach (this=0x233d3d90,
inf=0x22fce540, from_tty=1) at gdb/remote.c:6436
#29 0x0000000000c37c3c in target_detach (inf=0x22fce540, from_tty=1)
at gdb/target.c:2526
#30 0x0000000000860424 in detach_command (args=0x0, from_tty=1)
at gdb/infcmd.c:2817
#31 0x000000000060b594 in do_simple_func (args=0x0, from_tty=1, c=0x231431a0)
at gdb/cli/cli-decode.c:94
#32 0x00000000006108c8 in cmd_func (cmd=0x231431a0, args=0x0, from_tty=1)
at gdb/cli/cli-decode.c:2741
#33 0x0000000000c65a94 in execute_command (p=0x232e52f6 "", from_tty=1)
at gdb/top.c:570
#34 0x00000000007a7d2c in command_handler (command=0x232e52f0 "")
at gdb/event-top.c:566
#35 0x00000000007a8290 in command_line_handler (rl=...)
at gdb/event-top.c:802
#36 0x0000000000c9092c in tui_command_line_handler (rl=...)
at gdb/tui/tui-interp.c:103
#37 0x00000000007a750c in gdb_rl_callback_handler (rl=0x23385330 "detach")
at gdb/event-top.c:258
#38 0x0000000000d910f4 in rl_callback_read_char ()
at readline/readline/callback.c:290
#39 0x00000000007a7338 in gdb_rl_callback_read_char_wrapper_noexcept ()
at gdb/event-top.c:194
#40 0x00000000007a73f0 in gdb_rl_callback_read_char_wrapper
(client_data=0x22fbf640) at gdb/event-top.c:233
#41 0x0000000000cbee1c in stdin_event_handler (error=0, client_data=0x22fbf640)
at gdb/ui.c:154
#42 0x000000000154ed60 in handle_file_event (file_ptr=0x232be730, ready_mask=1)
at gdbsupport/event-loop.cc:572
#43 0x000000000154f21c in gdb_wait_for_event (block=1)
at gdbsupport/event-loop.cc:693
#44 0x000000000154dec4 in gdb_do_one_event (mstimeout=-1)
at gdbsupport/event-loop.cc:263
#45 0x0000000000910f98 in start_event_loop () at gdb/main.c:400
#46 0x0000000000911130 in captured_command_loop () at gdb/main.c:464
#47 0x0000000000912b5c in captured_main (data=0xfffff1a3db58)
at gdb/main.c:1338
#48 0x0000000000912bf4 in gdb_main (args=0xfffff1a3db58)
at gdb/main.c:1357
#49 0x00000000004170f4 in main (argc=10, argv=0xfffff1a3dcc8)
at gdb/gdb.c:38
(gdb)
...
The abort happens because a c++ exception escapes to c code, specifically
opncls_bstat in bfd/opncls.c. Compiling with -fexceptions works around this.
Fix this by catching the exception just before it escapes, in stat_trampoline
and likewise in few similar spot.
Add a new template catch_exceptions to do so in a consistent way.
Tested on aarch64-linux.
Approved-by: Pedro Alves <pedro@palves.net>
PR remote/31577
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31577
Working backwards in terms of motivation for the patch:
- When accessing memory via the xfer_partial interface, the process
that we're accessing is indicated by inferior_ptid. This can be
either the same process as current inferior, or a fork child which
does not exist in the inferior list. This is not documented
currently. This commit fixes that.
- For target delegation to work, we must always make the inferior we
want to call the target method on, the current inferior. This
wasn't documented, AFAICT, so this commit fixes that too. I put
that in the intro comment to target_ops.
- I actually started writing a larger intro comment to target_ops, as
there was seemingly none, which I did find odd. However, I then
noticed the description closer to the top of the file. I missed it
the first time, because for some reason, that intro comment is no
longer at the top of the file, as #includes etc. have been added
above it over the years. This commit fixes that too, by moving that
intro comment to the top.
Change-Id: Id21f5462947f2a0f6f3ac0c42532df62ba355914 Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Tom Tromey <tom@tromey.com>
Pedro Alves [Wed, 10 Apr 2024 19:00:26 +0000 (20:00 +0100)]
gdb/linux-nat: Fix mem access ptrace fallback (PR threads/31579)
Old RHEL systems have a kernel that does not support writing memory
via /proc/pid/mem. On such systems, we fallback to accessing memory
via ptrace. That has a few downsides described in the "Accessing
inferior memory" section at the top of linux-nat.c.
The target_xfer interface for memory access uses inferior_ptid as
sideband argument to indicate which process to access. Memory access
is process-wide, it is not thread-specific, so inferior_ptid is
sometimes pointed at a process-wide ptid_t for the memory access
(i.e., a ptid that looks like {pid, 0, 0}). That is the case for any
code that uses scoped_restore_current_inferior_for_memory, for
example.
That is what causes the issue described in PR 31579, where thread_db
calls into the debugger to read memory, which reaches our
ps_xfer_memory function, which does:
...
ret = target_read_memory (core_addr, buf, len);
...
}
If linux_nat_target::xfer_partial falls back to inf_ptrace_target with
a pid-ptid, then the ptrace code will do the ptrace call targeting
pid, the leader LWP. That may fail with ESRCH if the leader is
currently running, or zombie. That is the case in the scenario in
question, because thread_db is consulted for an event of a non-leader
thread, before we've stopped the whole process.
Fix this by having the ptrace fallback code try to find a stopped LWP
to use with ptrace.
I chose to handle this in the linux-nat target instead of in common
code because (global) memory is a process-wide property, and this
avoids having to teach all the code paths that use
scoped_restore_current_inferior_for_memory to find some stopped thread
to access memory through, which is a ptrace quirk. That is
effectively what we used to do before we started relying on writable
/proc/pid/mem. I'd rather not go back there.
To trigger this on modern kernels you have to hack linux-nat.c to
force the ptrace fallback code, like so:
--- a/gdb/linux-nat.c
+++ b/gdb/linux-nat.c
@@ -3921,7 +3921,7 @@ linux_nat_target::xfer_partial (enum target_object object,
poke would incorrectly write memory to the post-exec address
space, while the core was trying to write to the pre-exec
address space. */
- if (proc_mem_file_is_writable ())
+ if (0 && proc_mem_file_is_writable ())
With that hack, I was able to confirm that the fix fixes hundreds of
testsuite failures. Compared to a test run with pristine master, the
hack above + this commit's fix shows that some non-stop-related tests
fail, but that is expected, because those are tests that need to
access memory while the program is running. (I made no effort to
temporarily pause an lwp if no ptrace-stopped lwp is found.)
Change-Id: I24a4f558e248aff7bc7c514a88c698f379f23180 Tested-By: Hannes Domani <ssbssa@yahoo.de> Approved-By: Andrew Burgess <aburgess@redhat.com>
Pedro Alves [Wed, 17 Apr 2024 18:47:51 +0000 (19:47 +0100)]
Fix gdb.base/attach.exp --pid test skipping on native-extended-gdbserver
When testing with the native-extended-gdbserver board,
gdb.base/attach.exp shows a couple failures, like so:
Running /home/pedro/gdb/src/gdb/testsuite/gdb.base/attach.exp ...
FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: start gdb with --pid
FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: info thread (no thread)
From gdb.log:
builtin_spawn /home/pedro/gdb/build/gdb/testsuite/../../gdb/gdb -nw -nx -q -iex set height 0 -iex set width 0 -data-directory /home/pedro/gdb/build
/gdb/data-directory -iex set auto-connect-native-target off -iex set sysroot -quiet --pid=2115260
Don't know how to attach. Try "help target".
(gdb) FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: start gdb with --pid
There is a check for [isnative] to skip the test on anything but
target native, but that is the wrong check. native-extended-gdbserver
is "isnative". Fix it by using a gdb_protocol check instead.
Change-Id: I37ee730b8d6f1913b12c118838f511bd1c0b3768 Approved-By: Tom Tromey <tom@tromey.com>
After the previous patches, gdb_is_target_remote,
gdb_is_target_native, and mi_is_target_remote aren't used anywhere.
This commit eliminates them, along with now unnecessary helpers.
Change-Id: I54f9ae1f5aed3f640e5758731cf4954e6dbb1bee Approved-By: Tom Tromey <tom@tromey.com>
Pedro Alves [Wed, 17 Apr 2024 19:43:53 +0000 (20:43 +0100)]
gdb_is_target_remote -> gdb_protocol_is_remote
This is similar to the previous patch, but for gdb_protocol_is_remote.
gdb_is_target_remote and its MI cousin mi_is_target_remote, use "maint
print target-stack", which is unnecessary when checking whether
gdb_protocol is "remote" or "extended-remote" would do. Checking
gdb_protocol is more efficient, and can be done before starting GDB
and running to main, unlike gdb_is_target_remote/mi_is_target_remote.
This adds a new gdb_protocol_is_remote procedure, and uses it in place
of gdb_is_target_remote/mi_is_target_remote throughout.
There are no uses of gdb_is_target_remote/mi_is_target_remote left
after this. Those will be eliminated in a following patch.
In some spots, we no longer need to defer the check until after
starting GDB, so the patch adjusts accordingly.
Change-Id: I90267c132f942f63426f46dbca0b77dbfdf9d2ef Approved-By: Tom Tromey <tom@tromey.com>
Pedro Alves [Wed, 17 Apr 2024 18:59:01 +0000 (19:59 +0100)]
gdb_is_target_native -> gdb_protocol_is_native
gdb_is_target_native uses "maint print target-stack", which is
unnecessary when checking whether gdb_protocol is empty would do.
Checking gdb_protocol is more efficient, and can be done before
starting GDB and running to main, unlike gdb_is_target_native.
This adds a new gdb_protocol_is_native procedure, and uses it in place
of gdb_is_target_native.
At first, I thought that we'd end up with a few testcases needing to
use gdb_is_target_native still, especially multi-target tests that
connect to targets different from the default board target, but no,
actually all uses of gdb_is_target_native could be converted.
gdb_is_target_native will be eliminated in a following patch.
In some spots, we no longer need to defer the check until after
starting GDB, so the patch adjusts accordingly.
Change-Id: Ia706232dbffac70f9d9740bcb89c609dbee5cee3 Approved-By: Tom Tromey <tom@tromey.com>
Pedro Alves [Wed, 17 Apr 2024 18:26:32 +0000 (19:26 +0100)]
Fix "attach" failure handling with GDBserver
This fixes the same issue as the previous patch, but for "attach"
instead of "run".
If attaching to a process with "attach" (vAttach packet) fails,
GDBserver throws an error that escapes all the way to the top level.
When an error escapes all the way like that, GDBserver interprets it
as a disconnection, and either goes back to waiting for a new GDB
connection, or exits, if --once was specified.
Here's an example:
On the GDB side:
...
(gdb) tar extended-remote :9999
...
Remote debugging using :9999
(gdb) attach 1
Attaching to process 1
Attaching to process 1 failed
(gdb)
On the GDBserver side:
$ gdbserver --once --multi :9999
Listening on port 9999
Remote debugging from host 127.0.0.1, port 37464
gdbserver: Cannot attach to process 1: Operation not permitted (1)
$ # gdbserver exited
This is wrong, as we've connected with extended-remote/--multi.
GDBserver should just report an error to vAttach, and continue
connected to GDB, waiting for other commands.
This commit fixes GDBserver by catching the error locally in
handle_v_attach.
Note we now let pid == 0 pass down to attach_inferior. That is so we
get a useful textual error message to report to GDB.
This fixes a couple KFAILs in gdb.base/attach.exp. Still, I thought
it would be useful to add a new testcase specifically for this
scenario, in case gdb.base/attach.exp is ever split and stops trying
to attach again after a failed attach, with the same GDB session.
Pedro Alves [Fri, 26 Jan 2024 18:00:42 +0000 (18:00 +0000)]
Improve vRun error reporting
After the previous commit, if starting the inferior process with "run"
(vRun packet) fails, GDBserver reports an error using the "E." textual
error packet. On the GDB side, however, GDB doesn't yet do anything
with the textual error string. This commit improves that.
This makes remote debugging output the same as native output, when
possible, another small step in the "local/remote parity" project.
E.g., before, against GNU/Linux GDBserver:
(gdb) run
Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox
Running ".../gdb.base/run-fail-twice/run-fail-twice.nox" on the remote target failed
After, against GNU/Linux GDBserver (same as native):
(gdb) run
Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox
During startup program exited with code 126.
To know whether we have a textual error message, extend packet_result
to carry that information. While at it, convert packet_result to use
factory methods, and change its std::string parameter to a plain const
char *, as that it always what we have handy to pass to it.
Change-Id: Ib386f267522603f554b52a885b15229c9639e870 Approved-By: Tom Tromey <tom@tromey.com>
Pedro Alves [Fri, 26 Jan 2024 18:00:42 +0000 (18:00 +0000)]
Fix "run" failure handling with GDBserver
If starting the inferior process with "run" (vRun packet) fails,
GDBserver throws an error that escapes all the way to the top level.
When an error escapes all the way like that, GDBserver interprets it
as a disconnection, and either goes back to waiting for a new GDB
connection, or exits, if --once was specified.
E.g., with the testcase program added by this commit, we see:
On GDB side:
...
(gdb) tar extended-remote :999
...
Remote debugging using :9999
(gdb) r
Starting program:
Running ".../gdb.base/run-fail-twice/run-fail-twice.nox" on the remote target failed
(gdb)
On GDBserver side:
$ gdbserver --once --multi :9999
Remote debugging from host 127.0.0.1, port 34344
bash: line 1: .../gdb.base/run-fail-twice/run-fail-twice.nox: Permission denied
bash: line 1: exec: .../gdb.base/run-fail-twice/run-fail-twice.nox: cannot execute: Permission denied
gdbserver: During startup program exited with code 126.
$ # gdbserver exited
This is wrong, as we've connected with extended-remote/--multi.
GDBserver should just report an error to vCont, and continue connected
to GDB, waiting for other commands.
This commit fixes GDBserver by catching the error locally in
handle_v_run.
Change-Id: Ib386f267522603f554b52a885b15229c9639e870 Approved-By: Tom Tromey <tom@tromey.com>
Pedro Alves [Fri, 2 Jun 2023 21:29:02 +0000 (22:29 +0100)]
Windows: Fix run/attach hang after bad run/attach
On Cygwin, gdb.base/attach.exp exposes that an "attach" after a
previously failed "attach" hangs:
(gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: attach to digits-starting nonsense is prohibited
attach 0
Can't attach to process 0 (error 2: The system cannot find the file specified.)
(gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: attach to nonexistent process is prohibited
attach 10644
FAIL: gdb.base/attach.exp: do_attach_failure_tests: first attach (timeout)
The problem is that windows_nat_target::attach always returns success
even if the attach fails. When we return success, the helper thread
begins waiting for events (which will never come), and thus the next
attach deadlocks on the do_synchronously call within
windows_nat_target::attach.
"run" has the same problem, which is exposed by the new
gdb.base/run-fail-twice.exp testcase added in a following patch:
(gdb) run
Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox
Error creating process .../gdb.base/run-fail-twice/run-fail-twice.nox, (error 6: The handle is invalid.)
(gdb) PASS: gdb.base/run-fail-twice.exp: test: bad run 1
run
Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox
FAIL: gdb.base/run-fail-twice.exp: test: bad run 2 (timeout)
The problem here is the same, except that this time it is
windows_nat_target::create_inferior that returns the incorrect result.
This commit fixes both the "attach" and "run" paths, and the latter
both the Cygwin and MinGW paths. The tests mentioned above now pass
on Cygwin. Confirmed the fixes manually for MinGW GDB.
Change-Id: I15ec9fa279aff269d4982b00f4ea7c25ae917239 Approved-By: Tom Tromey <tom@tromey.com>
Pedro Alves [Thu, 18 Apr 2024 19:22:36 +0000 (20:22 +0100)]
Document "E.MESSAGE" RSP errors
For many years, GDB has accepted a "E.MESSAGE" error reponse, in
addition to "E NN". For many packets, GDB strips the "E." before
giving the error message to the user. For others, GDB does not strip
the "E.", but still understands that it is an error, as it starts with
"E", and either prints the whole string, or ignores it and just
mentions an error occured (same as for "E NN").
This has been the case for as long as I remember. Now that I check, I
see that it's been there since 2006 (commit a76d924dffcb, also here:
https://sourceware.org/pipermail/gdb-patches/2006-September/047286.html).
All along, I actually thought it was documented. Turns out it wasn't.
This commit documents it, in the new "Standard Replies" section, near
where we document "E NN".
The original version of this 3-patch documentation series was a single
CodeSourcery patch that documented the textual error as
"E.NAME.MESSAGE", with MESSAGE being 8-bit binary encoded. But I
think the ship has sailed for that. GDBserver has been sending error
messages with more than one "." for a long while, and with no binary
encoding. Still, I've preserved the "Co-Authored-By" list of the
original larger patch.
The 'qRcmd' and 'm' commands are exceptions and do not accept this
reply format. The top of the "Standard Replies" section already says:
"All commands support these, except as noted in the individual
command descriptions."
So this adds a note to the description of 'qRcmd' and 'm', explicitly
stating that they do not support this error reply format.
Change-Id: Ie4fee3d00d82ede39e439bf162e8cb7485532fd8 Co-Authored-By: Jim Blandy <jimb@codesourcery.com> Co-Authored-By: Mike Wrighton <mike_wrighton@mentor.com> Co-Authored-By: Nathan Sidwell <nathan@codesourcery.com> Co-Authored-By: Hafiz Abid Qadeer <abidh@codesourcery.com> Approved-By: Eli Zaretskii <eliz@gnu.org>
Pedro Alves [Thu, 18 Apr 2024 19:22:36 +0000 (20:22 +0100)]
Centralize documentation of error and empty RSP responses
Currently, for each packet, we document the "E NN" response (error),
and the empty response (unsupported). This patch centralizes that in
a new "Standard Replies" section.
In the "Packets", "General Query Packets", "Tracepoint Packets"
sections, Remove explicit mention of empty and error replies, except
when they provide detail not covered in Standard Replies.
Note this hunk:
-@item E @var{NN}
-@var{NN} is errno
and this one:
-@item E00
-The request was malformed, or @var{annex} was invalid.
-
-@item E @var{nn}
-The offset was invalid, or there was an error encountered reading the data.
-The @var{nn} part is a hex-encoded @code{errno} value.
were really documenting things that don't really work that way.
The first is the documentation of the "m" packet. GDB does _not_
interpret the NN as an errno. It can't, in fact, because the
remote/target errno numbers have nothing to do with GDB/host errno
numbers in a cross debugging scenario.
The second hunk above is from the documentation of qXfer. Again, GDB
does not give any interpretation to the NN error code at all. Nor
does GDBserver. And again, an errno number can't be interpreted in a
cross debugging scenario.
Change-Id: I973695c80809cdb5a5e8d5be8b78ba4d1ecdb513 Co-Authored-By: Jim Blandy <jimb@codesourcery.com> Co-Authored-By: Mike Wrighton <mike_wrighton@mentor.com> Co-Authored-By: Nathan Sidwell <nathan@codesourcery.com> Co-Authored-By: Hafiz Abid Qadeer <abidh@codesourcery.com> Approved-By: Eli Zaretskii <eliz@gnu.org>
Andrew Burgess [Thu, 16 Nov 2023 15:20:10 +0000 (15:20 +0000)]
gdb: Add a SECURITY.txt document for GDB
This commit adds a SECURITY document to GDB. The idea behind this
document is to define what security expectations a user can reasonably
have when using GDB. In addition the document specifies which bugs
GDB developers consider a security bug, and which are just "normal"
bugs.
Discussion for the creation of this initial version can be found here:
Like any part of GDB, this is not intended as the absolute final
version, instead this is a living document, and this is just a
reasonable starting point from which we can iterate.
For now I've added this document as a text file but I am considering
merging this document into the manual at a later date, and having the
SECURITY.txt file just say "Read the manual"
This patch fixes a pretty funny issue on sh targets that occurred
because $pc (and similar registers) were typed as int. When $pc is in
the upper half of the address space (i.e. kernel code on sh), `x/i $pc'
would resolve to a negative value. At least in the case of a remote
target with an Xfer memory map, this leads to a spurious "cannot access
memory" error as negative addresses are out of bounds.
The issue is fixed by specifying pointer types for pc and other pointer
registers. Code pointer registers on sh include pc, pr (return address
of a call), vbr (interrupt handler) and spc (return address after
interrupt). Data pointers include r15 (stack pointer) and gbr (base
register for a few specific addressing modes).
Change-Id: I043a058f7cbc6494f380dc0461616a9f3e0d87e0 Approved-By: Simon Marchi <simon.marchi@efficios.com>
Jan Beulich [Fri, 26 Apr 2024 12:23:14 +0000 (14:23 +0200)]
objcopy: check input flavor before setting PE/COFF section alignment
coff_section_data() and elf_section_data() use the same underlying
field. The pointer being non-NULL therefore isn't sufficient to know
that pei_section_data() can validly be used on the incoming object.
Apparently in 64-bit-host builds the resulting memory corruption is
benign, whereas in 32-bit-host builds a segmentation fault occurs upon
de-referencing pei_section_data()'s return value.
Carl Love [Wed, 24 Apr 2024 18:14:10 +0000 (14:14 -0400)]
Fix end_sequence addresses for dw2-lines.exp
The patch:
From f0d556d14b1d1c3f8e2f9c13b08adca22e1b8c9c Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Wed, 17 Apr 2024 12:55:00 +0200
Subject: [PATCH] [gdb/testsuite] Fix end_sequence addresses
I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main:
... 00000000004102c4 <end_of_sequence>:
4102c4: 52800000 mov w0, #0x0 // #0
4102c8: 9100c3ff add sp, sp, #0x30
4102cc: d65f03c0 ret
...
is not described by the line table:
...
<snip>
The regression failure on PowerPC is due to the change in file
dw2-lines.exp,
David Faust [Thu, 25 Apr 2024 18:40:31 +0000 (11:40 -0700)]
bpf: fix calculation when deciding to relax branch
In certain cases we were calculating the jump displacement incorrectly
when deciding whether to relax a branch. This meant for some branches,
such as a very long backwards conditional branch, relaxation was not
done when it should have been. The result was to error later, because
the actual jump displacement was too large to fit in the original
instruction.
This patch fixes up the displacement calculation so that those branches
are correctly relaxed and no longer result in an error. In addition, it
changes md_convert_frag to install fixups for the JAL instructions in
the resulting relaxations rather than encoding the displacement value
directly.
gas/
* config/tc-bpf.c (relaxed_branch_length): Correct displacement
calculation when relaxing.
(md_convert_frag): Likewise. Install fixups for JAL
instructions resulting from relaxation.
* testsuite/gas/bpf/jump-relax-ja-be.d: Correct and expand test.
* testsuite/gas/bpf/jump-relax-ja.d: Likewise.
* testsuite/gas/bpf/jump-relax-ja.s: Likewise.
* testsuite/gas/bpf/jump-relax-jump-be.d: Likewise.
* testsuite/gas/bpf/jump-relax-jump.d: Likewise.
* testsuite/gas/bpf/jump-relax-jump.s: Likewise.
Simon Marchi [Tue, 23 Apr 2024 19:22:44 +0000 (15:22 -0400)]
gdb: remove gdbcmd.h
Most files including gdbcmd.h currently rely on it to access things
actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make
things easy, replace all includes of gdbcmd.h with includes of
cli/cli-cmds.h. This might lead to some unused includes of
cli/cli-cmds.h, but it's harmless, and much faster than going through
the 170 or so files by hand.
Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f Approved-By: Tom Tromey <tom@tromey.com>
Jinyang He [Mon, 22 Apr 2024 09:49:50 +0000 (17:49 +0800)]
LoongArch: gas: Simplify relocations in sections without code flag
Gas should not emit ADD/SUB relocation pairs for label differences
if they are in the same section without code flag even relax enabled.
Because the real value is not be affected by relaxation and it can be
compute out in assembly stage. Thus, correct the `TC_FORCE_RELOCATION
_SUB_SAME` and the label differences in same section without code
flag can be resolved in fixup_segment().
projects / thirdparty / binutils-gdb.git / log
