ctf_dedup's intern() function does not return a dynamically allocated
string, so I just spent ten minutes auditing for obvious memory leaks
that couldn't actually happen. Update the comment to note what it
actually returns (a pointer into an atoms table: i.e. possibly not
a new string, and not so easily leakable).
libctf/
* ctf-dedup.c (intern): Update comment.
GCC 11+ complains that sym is uninitialized in ctf_symbol_next. It
isn't, but it's not quite smart enough to figure that out (it requires
domain-specific knowledge of the state of the ctf_next_t iterator
over multiple calls).
libctf/
* ctf-lookup.c (ctf_symbol_next): Initialize sym to a suitable
value for returning if never reset during the function.
If no suitable qsort_r is found in libc, we fall back to an
implementation in ctf-qsort.c. But this implementation routinely calls
the comparison function with two identical arguments. The comparison
function that ensures that the order of output types is stable is not
ready for this, misinterprets it as a type appearing more that once (a
can-never-happen condition) and fails with an assertion failure.
Fixed, audited for further instances of the same failure (none found)
and added a no-qsort test to my regular testsuite run.
libctf/:
PR libctf/30013
* ctf-dedup.c (sort_output_mapping): Inputs are always equal to
themselves.
Internal AdaCore DAP testing on Windows has had occasional failures
that show:
assert threading.current_thread() is _dap_thread
I think this is a race in DAP startup: the _dap_thread global is only
set on return from start_thread, but it seems possible that the thread
itself could already run and encounter a @in_dap_thread decorator.
This patch fixes the problem by setting the global before running any
of the code in the new thread. This also lets us remove a FIXME.
There were reports of gdb throwing internal errors when calling
inferior_thread ()/get_current_regcache () on a system with
Pointer Authentication enabled.
In such cases, gdb produces the following backtrace:
../../../repos/binutils-gdb/gdb/thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0xaaaae04a571f gdb_internal_backtrace_1
../../../repos/binutils-gdb/gdb/bt-utils.c:122
0xaaaae04a57f3 _Z22gdb_internal_backtracev
../../../repos/binutils-gdb/gdb/bt-utils.c:168
0xaaaae0b52ccf internal_vproblem
../../../repos/binutils-gdb/gdb/utils.c:401
0xaaaae0b5310b _Z15internal_verrorPKciS0_St9__va_list
../../../repos/binutils-gdb/gdb/utils.c:481
0xaaaae0e24b8f _Z18internal_error_locPKciS0_z
../../../repos/binutils-gdb/gdbsupport/errors.cc:58
0xaaaae0a88983 _Z15inferior_threadv
../../../repos/binutils-gdb/gdb/thread.c:86
0xaaaae0956c87 _Z20get_current_regcachev
../../../repos/binutils-gdb/gdb/regcache.c:428
0xaaaae035223f aarch64_remove_non_address_bits
../../../repos/binutils-gdb/gdb/aarch64-tdep.c:3572
0xaaaae03e8abb _Z31gdbarch_remove_non_address_bitsP7gdbarchm
../../../repos/binutils-gdb/gdb/gdbarch.c:3109
0xaaaae0a692d7 memory_xfer_partial
../../../repos/binutils-gdb/gdb/target.c:1620
0xaaaae0a695e3 _Z19target_xfer_partialP10target_ops13target_objectPKcPhPKhmmPm
../../../repos/binutils-gdb/gdb/target.c:1684
0xaaaae0a69e9f target_read_partial
../../../repos/binutils-gdb/gdb/target.c:1937
0xaaaae0a69fdf _Z11target_readP10target_ops13target_objectPKcPhml
../../../repos/binutils-gdb/gdb/target.c:1977
0xaaaae0a69937 _Z18target_read_memorymPhl
../../../repos/binutils-gdb/gdb/target.c:1773
0xaaaae08be523 ps_xfer_memory
../../../repos/binutils-gdb/gdb/proc-service.c:90
0xaaaae08be6db ps_pdread
../../../repos/binutils-gdb/gdb/proc-service.c:124
0x40001ed7c3b3 _td_fetch_value
/build/glibc-RIFKjK/glibc-2.31/nptl_db/fetch-value.c:115
0x40001ed791ef td_ta_map_lwp2thr
/build/glibc-RIFKjK/glibc-2.31/nptl_db/td_ta_map_lwp2thr.c:194
0xaaaae07f4473 thread_from_lwp
../../../repos/binutils-gdb/gdb/linux-thread-db.c:413
0xaaaae07f6d6f _ZN16thread_db_target4waitE6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
../../../repos/binutils-gdb/gdb/linux-thread-db.c:1420
0xaaaae0a6b33b _Z11target_wait6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
../../../repos/binutils-gdb/gdb/target.c:2586
0xaaaae0789cf7 do_target_wait_1
../../../repos/binutils-gdb/gdb/infrun.c:3825
0xaaaae0789e6f operator()
../../../repos/binutils-gdb/gdb/infrun.c:3884
0xaaaae078a167 do_target_wait
../../../repos/binutils-gdb/gdb/infrun.c:3903
0xaaaae078b0af _Z20fetch_inferior_eventv
../../../repos/binutils-gdb/gdb/infrun.c:4314
0xaaaae076652f _Z22inferior_event_handler19inferior_event_type
../../../repos/binutils-gdb/gdb/inf-loop.c:41
0xaaaae07dc68b handle_target_event
../../../repos/binutils-gdb/gdb/linux-nat.c:4206
0xaaaae0e25fbb handle_file_event
../../../repos/binutils-gdb/gdbsupport/event-loop.cc:573
0xaaaae0e264f3 gdb_wait_for_event
../../../repos/binutils-gdb/gdbsupport/event-loop.cc:694
0xaaaae0e24f9b _Z16gdb_do_one_eventi
../../../repos/binutils-gdb/gdbsupport/event-loop.cc:217
0xaaaae080f033 start_event_loop
../../../repos/binutils-gdb/gdb/main.c:411
0xaaaae080f1b7 captured_command_loop
../../../repos/binutils-gdb/gdb/main.c:475
0xaaaae0810b97 captured_main
../../../repos/binutils-gdb/gdb/main.c:1318
0xaaaae0810c1b _Z8gdb_mainP18captured_main_args
../../../repos/binutils-gdb/gdb/main.c:1337
0xaaaae0338453 main
../../../repos/binutils-gdb/gdb/gdb.c:32
---------------------
../../../repos/binutils-gdb/gdb/thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
We also see failures across the testsuite if the tests get executed on a target
that has native support for the pointer authentication feature. But
gdb.base/break.exp and gdb.base/access-mem-running.exp are two examples of
tests that run into errors and internal errors.
This issue started after commit d88cb738e6a7a7179dfaff8af78d69250c852af1, which
enabled more broad use of pointer authentication masks to remove non-address
bits of pointers, but wasn't immediately detected because systems with native
support for pointer authentication are not that common yet.
The above crash happens because gdb is in the middle of handling an event,
and do_target_wait_1 calls switch_to_inferior_no_thread, nullifying the
current thread. This means a call to inferior_thread () will assert, and
attempting to call get_current_regcache () will also call inferior_thread (),
resulting in an assertion as well.
target_has_registers was one function that seemed useful for detecting these
types of situation where we don't have a register cache. The problem with that
is the inconsistent state of inferior_ptid, which is used by
target_has_registers.
Despite the call to switch_to_no_thread in switch_to_inferior_no_thread from
do_target_wait_1 in the backtrace above clearing inferior_ptid, the call to
ps_xfer_memory sets inferior_ptid momentarily before reading memory:
static ps_err_e
ps_xfer_memory (const struct ps_prochandle *ph, psaddr_t addr,
gdb_byte *buf, size_t len, int write)
{
scoped_restore_current_inferior restore_inferior;
set_current_inferior (ph->thread->inf);
scoped_restore_current_program_space restore_current_progspace;
set_current_program_space (ph->thread->inf->pspace);
scoped_restore save_inferior_ptid = make_scoped_restore (&inferior_ptid);
inferior_ptid = ph->thread->ptid;
CORE_ADDR core_addr = ps_addr_to_core_addr (addr);
int ret;
if (write)
ret = target_write_memory (core_addr, buf, len);
else
ret = target_read_memory (core_addr, buf, len);
return (ret == 0 ? PS_OK : PS_ERR);
}
Maybe this shouldn't happen, or maybe it is just an unfortunate state to be
in. But this prevents the use of target_has_registers to guard against the
lack of registers, since, although current_thread_ is still nullptr,
inferior_ptid is valid and is not null_ptid.
There is another crash scenario after we kill a previously active inferior, in
which case the gdbarch will still say we support pointer authentication but we
will also have no current thread (inferior_thread () will assert etc).
If the target has support for pointer authentication, gdb needs to use
a couple (or 4, for bare-metal) mask registers to mask off some bits of
pointers, and for that it needs to access the registers.
At some points, like the one from the backtrace above, there is no active
thread/current regcache because gdb is in the middle of doing event handling
and switching between threads.
Simon suggested the use of inferior_ptid to fetch the register cache, as
opposed to relying on the current register cache. Though we need to make sure
inferior_ptid is valid (not null_ptid), I think this works nicely.
With inferior_ptid, we can do safety checks along the way, making sure we have
a thread to fetch a register cache from and checking if the thread is actually
stopped or running.
The following patch implements this idea with safety checks to make sure we
don't run into assertions or errors. If any of the checks fail, we fallback to
using a default mask to remove non-address bits of a pointer.
I discussed with Pedro the possibility of caching the mask register values
(which are per-process and can change mid-execution), but there isn't a good
spot to cache those values. Besides, the mask registers can change constantly
for bare-metal debugging when switching between exception levels.
In some cases, it is just not possible to get access to these mask registers,
like the case where threads are running. In those cases, using a default mask
to remove the non-address bits should be enough.
This can happen when we let threads run in the background and then we attempt
to access a memory address (now that gdb is capable of reading memory even
with threads running). Thus gdb will attempt to remove non-address bits
of that memory access, will attempt to access registers, running into errors.
Regression-tested on aarch64-linux Ubuntu 20.04.
In proc mi_expect_stop there's a proc argument reason that's handled like so:
...
set r "reason=\"$reason\","
...
That's fine for say:
...
set reason "foo"
...
for which this evaluates to:
...
set r "reason=\"foo\","
...
But there are more complex uses, for instance:
...
set reason "breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal"
...
which evaluates to:
...
set r "\"breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal\""
...
Note how in this reason argument, the first two '\"' seems to form a pair
surrounding ',disp=', which is not the case, which is confusing.
Fix this by only adding the quotes in mi_expect_stop if the string doesn't
already contain quotes, such that we have the more readable:
...
set reason "\"breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal\""
...
Tested on x86_64-linux.
In commit 722c4596034 ("[gdb/testsuite] Fix gdb.cp/*.exp for remote host"), I
needed to change ".*/" into "(.*/)?" in:
...
gdb_test "info variable everywhere" \
"File .*/m-static\[.\]h.*const int gnu_obj_4::everywhere;"
...
However, due to the fact that I got this output:
...
(gdb) info variable everywhere^M
All variables matching regular expression "everywhere":^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
8: const int gnu_obj_4::everywhere;^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M
8: const int gnu_obj_4::everywhere;^M
...
I decided to make the matching somewhat stricter, to make sure that the two
matched lines were subsequent.
The commit turned out to be more strict than intended, and caused a regression
on Ubuntu 20.04, where the output was instead:
...
(gdb) info variable everywhere^M
All variables matching regular expression "everywhere":^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
8: const int gnu_obj_4::everywhere;^M
...
At that point I realized I'm looking at a bug (filed as PR symtab/30265),
which manifests on openSUSE Leap 15.4 for native and readnow, and on Ubuntu
20.04 for readnow, but not for native.
Before my commit, the test-case passed whether the bug manifested or not.
After my commit, the test-case only passed when the bug manifested.
Fix the test-case regression by reverting to the situation before the commit:
pass whether the bug manifests or not. We could add an xfail for the PR, but
I'm expecting a fix soon, so that doesn't look worth the effort.
Tested on x86_64-linux, both on openSUSE Leap 15.4 and Ubuntu 20.04, both with
native and readnow.
Reported-By: Simon Marchi <simon.marchi@efficios.com>
This input sequence is accepted by DAP:
...
{"seq": 4, "type": "request", "command": "configurationDone"}Content-Length: 84
...
This input sequence has the same effect:
...
{"seq": 4, "type": "request", "command": "configurationDone"}ignorethis
Content-Length: 84
...
but the 'ignorethis' part is silently ignored.
Log the ignored bit, such that we have:
...
READ: <<<{"seq": 4, "type": "request", "command": "configurationDone"}>>>
WROTE: <<<{"request_seq": 4, "type": "response", "command": "configurationDone"
, "success": true}>>>
+++ run
IGNORED: <<<b'ignorethis'>>>
...
Simon reported that doing:
...
$ while make check-parallel TESTS='gdb.opencl/*.exp' -j 100; do true; done
...
could run into:
...
ERROR: remote_download to target of \
/data/vries/gdb/src/gdb/testsuite/lib/opencl_kernel.cl to opencl_kernel.cl: \
cp: cannot create regular file 'opencl_kernel.cl': File exists
...
Fix this by using gdb_remote_download (instead of plain remote_download) in
allow_opencl_test, which takes care of:
- downloading to a location which is safe for parallel testing, by
using standard_output_file, and
- cleaning up the downloaded file, meaning we can remove the corresponding
"remote_file target delete ${clprogram}" lines in allow_opencl_test.
Tested on x86_64-linux.
Reported-by: Simon Marchi <simon.marchi@efficios.com>
Insert two stubs in a BTI enabled binary when fixing long calls: The
first is near the call site and uses an indirect jump like before,
but it targets the second stub that is near the call target site and
uses a direct jump.
This is needed when a single stub breaks BTI compatibility.
The stub layout is kept fixed between sizing and building the stubs,
so the location of the second stub is known at build time, this may
introduce padding between stubs when those are relaxed. Stub layout
with BTI disabled is unchanged.
This commit is initial support for SystemTap for RISC-V Linux. The
following two tests exercise SystemTap functionality, and are showing
many failures, which are all fixed by this commit:
gdb.cp/exceptprint.exp
gdb.base/stap-probe.exp
One thing I wasn't sure about is if the SystemTap support should be
Linux specific, or architecture specific. For aarch64, arm, ia64, and
ppc, the SystemTap support seems to libe in the ARCH-linux-tdep.c
file, while for amd64, i386, and s390 the implementation lives in
ARCH-tdep.c. I have no idea which of these is the better choice -- or
maybe both choices are correct in the right circumstances, and I'm
just not aware of how to choose between them.
Anyway, for this patch I selected riscv-tdep.c (though clearly, moving
the changes to riscv-linux-tdep.c is trivial if anyone thinks that's a
more appropriate location).
The stap-probe.exp file tests immediate, register, and register
indirect operands, all of which appear to be working fine with this
commit. The generic expression support doesn't appear to be
architecture specific, so I'd expect that to work fine too.
The comment on the gdbarch_displaced_step_fixup gdbarch method
indicates that this method is optional and that GDB will perform some
default if this method is not supplied. As such we define a predicate
gdbarch_displaced_step_fixup_p.
It may have been true at one point that the fixup method was optional,
but it is no longer true. If this method is not defined and GDB tries
to complete a displaced step, then GDB is going to crash.
Additionally the gdbarch_displaced_step_fixup_p predicate is not used
anywhere in GDB.
In this commit I have removed the gdbarch_displaced_step_fixup_p
predicate, and I have updated the validation check for the
gdbarch_displaced_step_fixup method; if the
gdbarch_displaced_step_copy_insn method is defined then the fixup
method must also be defined.
I believe I've manually checked all the current places where
gdbarch_displaced_step_copy_insn is defined and they all also define
the fixup method, so this change should cause no problems for anyone.
There should be no user visible changes after this commit.
Approved-By: Pedro Alves <pedro@palves.net>
I found an upcast from template_symbol to symbol. This was necessary
long ago, but since symbols use inheritance now, it is not. This
patch removes it. Tested by rebuilding.
Commit 904d9b02a185 ("gdb: make "maintenance info line-table" show
relocated addresses again") changed the format of that command, but
failed to adjust some test cases that relied on it. This patch fixes
it.
The failures fixed are:
FAIL: gdb.base/maint.exp: maint info line-table w/o a file name
FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: END with address 1 eliminated
FAIL: gdb.dwarf2/dw2-ranges-base.exp: count END markers in line table
Change-Id: I946580d5e100f1beeac99a9e90d7819c6bb4ac6c
When running test-cases gdb.cp/annota{2,3}.exp with target board
native-extended-gdbserver, we run into a few FAILs, due to the test-cases
trying to match inferior output together with gdb output.
Fix this by ignoring the inferior output in this case.
Tested on x86_64-linux.
Commit 1acc9dca423f ("Change linetables to be objfile-independent")
changed "maintenance info line-table" to print unrelocated addresses
instead of relocated. This breaks a few tests on systems where that
matters. The ones I see are:
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ...
FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix)
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ...
FAIL: gdb.base/async.exp: stepi&
FAIL: gdb.base/async.exp: nexti&
FAIL: gdb.base/async.exp: finish&
These tests run "maintenance info line-table" to record the address of
some lines, and then use these addresses in expected patterns. It
therefore expects these addresses to match the runtime addresses,
therefore the relocated addresses.
Add back the relocated addresses, next to the unrelocated addresses,
like so:
INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END
0 6 0x0000555555555119 0x0000000000001119 Y
1 7 0x000055555555511d 0x000000000000111d Y
2 8 0x0000555555555123 0x0000000000001123 Y
3 END 0x0000555555555125 0x0000000000001125 Y
The unrelocated addresses can always be useful trying to map this
information with a DWARF info dump.
Adjust the is_stmt_addresses proc in the testsuite to match the new
output.
Change-Id: I59558f167e13e63421c9e0f2cad192e7c95c10cf
We can't free "internal" on errors, since bfd_coff_swap_sym_in may
call bfd_alloc. For example, _bfd_XXi_swap_sym_in may even create new
sections, which use bfd_alloc'd memory. If "internal" is freed, all
more recently bfd_alloc'd memory is also freed.
* coffgen.c (coff_get_normalized_symtab): Don't bfd_release on
error.
* coff-mcore.c (coff_mcore_relocate_section): Sanity check sym
string offset when setting up name for use by error messages.
* coff-sh.c (sh_relocate_section): Likewise.
As far as I can see the only place that sets obj_coff_strings without
setting obj_coff_strings_len is pe_ILF_build_a_bfd. Fix that and we
can simplify the sym string offset check. This is just a tidy.
pe_ILF_build_a_bfd doesn't create bad symbols and
_bfd_coff_read_string_table will always result in non-zero
obj_coff_strings_len when obj_coff_strings is non-NULL.
PR 17910
* coffgen.c (_bfd_coff_internal_syment_name): Always sanity
check sym string offset.
* peicode.h (pe_ILF_build_a_bfd): Set obj_coff_strings_len.
It's an odd thing to have objdump -x show a different section table
to objdump -h, but that can happen if swapping in symbols leads to
creating sections. Setting SEC_LINKER_CREATED stops the display of
these sections, so that you get shown what is in the object file.
* peXXigen.c (_bfd_XXi_swap_sym_in): Set SEC_LINKER_CREATED on
fake section created for C_SECTION syms. Don't zero asection
fields that are already zero.
Free memory on closing bfds. The COFF close_and_cleanup does more
work than _bfd_generic_close_and_cleanup (defined as
_bfd_archive_close_and_cleanup).
* coff-rs6000.c (_bfd_xcoff_close_and_cleanup): Define as
_bfd_coff_close_and_cleanup.
* coff64-rs6000.c (rs6000_xcoff64_vec, rs6000_xcoff64_aix_vec): Use
_bfd_coff_close_and_cleanup.
The recent commit:
commit 2a8339b71f37f2d02f5b2194929c9d702ef27223
Author: Carl Love <cel@us.ibm.com>
Date: Thu Mar 9 16:10:18 2023 -0500
PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp
PPC64 multiple entry points, a normal entry point and an alternate entry
point. The alternate entry point is to setup the Table of Contents (TOC)
register before continuing at the normal entry point. When the TOC is
already valid, the normal entry point is used, this is typically the case.
The alternate entry point is typically referred to as the global entry
point (GEP) in IBM. The normal entry point is typically referred to as
the local entry point (LEP).
.....
Is causing regression failures on on PowerPC platforms. The regression
failures are in tests:
gdb.reverse/finish-precsave.exp
gdb.btrace/tailcall.exp
gdb.mi/mi-reverse.exp
gdb.btrace/step.exp
gdb.reverse/until-precsave.exp
gdb.reverse/finish-reverse.exp
gdb.btrace/tailcall-only.exp
The issue is in gdb/infcmd.c, function finish_command. The value of the
two new variables ALT_ENTRY_POINT and ENTRY_POINT are being initializezed
to SAL.PC. However, SAL has just been declared. The value of SAL.PC is
zero at this point. The intialization of ALT_ENTRY_POINT and ENTRY_POINT
needs to be after the initialization of SAL.
This patch moves the initialization of ALT_ENTRY_POINT and ENTRY_POINT
variables to fix the regression failures.
The patch has been tested on Power10 and on X86.
In a recent commit I forgot to add a double quote before chmod here:
...
remote_exec build $rsh_cmd chmod go-rx ."
...
Fix it by adding the missing double quote.
Looking at the implementation of ${board}_file in remote-stdio-gdbserver.exp,
I don't see a relevant difference with the implementation of standard_file
in dejagnu.
Simplify the board by removing ${board}_file.
Tested on x86_64-linux, by running gdb.testsuite/board-sanity.exp.
In commit ff581559f9d ("[gdb/testsuite] Add gdb.testsuite/board-sanity.exp") I
removed handling of HOST_DIR in local-remote-host-native.exp to fix FAILs
in test-case gdb.testsuite/board-sanity.exp.
Reintroduce handling of HOST_DIR using remotedir, now that using remotedir for
a host board no longer make compilation fail due to commit 80d6c79866f
("[gdb/testsuite] Handle remotedir in remote_upload").
This fixes an XFAIL in gdb.testsuite/board-sanity.exp, introduced in commit
3741934fdb0 ("[gdb/testsuite] Set remotedir by default in some boards").
Tested on x86_64-linux.
Since the tdesc_powerpc_vsx32, tdesc_powerpc_vsx64, tdesc_powerpc_altivec32 and tdesc_powerpc_altivec64
definitions are moved to ppc-tdep.h we no longer need to import these .c files.
I noticed a weird comment in one of the .y files, and then ended up
removing some unnecessary #includes from these files.
Tested by rebuilding.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The mi_version function is unused, and I think it's better overall if
it is never used. This patch removes it. Tested by rebuilding.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The type allocation changes introduced a failure in python-helper.exp
that I did not notice. The bug is that, with these patches,
arch-allocated integer types have a TYPE_SPECIFIC_INT object attached.
This patch updates the test to allow this.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30253
Dejagnu's remotedir implementation has support in remote_exec and
remote_download, but not remote_upload.
Consider the following scenario:
- downloading an executable to target,
- running it,
- uploading a file produced by the executable
while assuming remote target user remote-target with homedir
/home/remote-target and remotedir set to /home/remote-target/tmp.
Concretely, it looks like this:
...
# binfile == "$outputs/gdb.abc/a.out"
set target_binfile [remote_download target $binfile]
# target_binfile == "/home/remote-target/tmp/a.out"
remote_exec target $target_binfile
# Running $target_binfile produced /home/remote-target/tmp/result.txt.
set result [remote_upload target /home/remote-target/tmp/result.txt \
$outputs/gdb.abc/result.txt]
# result == $outputs/gdb.abc/result.txt.
...
Add a remote_upload implementation that also handles remotedir in lib/gdb.exp,
overriding dejagnu's remote_upload, such that we can simplify the
remote_upload call to:
...
set result [remote_upload target result.txt $outputs/gdb.abc/result.txt]
...
Tested on x86_64-linux.
PR testsuite/30250
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30250
