forked from Imagelibrary/binutils-gdb
c29a37f741
This commit continues the work of the previous two commits. In the following commits I added the target_fileio_stat function, and the target_ops::fileio_stat member function: *08a115cc1cgdb: add target_fileio_stat, but no implementations yet *3055e3d2f1gdb: add GDB side target_ops::fileio_stat implementation *6d45af96eagdbserver: add gdbserver support for vFile::stat packet *22836ca885gdb: check for multiple matching build-id files Unfortunately I messed up, despite being called 'stat' these function actually performed an 'lstat'. The 'lstat' is the correct (required) implementation, it's the naming that is wrong. Additionally, to support remote targets, these commit added the vFile::stat packet, which again, performed an 'lstat'. In the previous two commits I changed the GDB code to replace 'stat' with 'lstat' in the fileio function names. I then added a new vFile:lstat packet which GDB now uses instead of vFile:stat. And that just leaves the vFile:stat packet which is, right now, performing an 'lstat'. Now, clearly when I wrote this code I fully intended for this packet to perform an lstat, it's the lstat that I needed. But now, I think, we should "fix" vFile:stat to actually perform a 'stat'. This is risky. This is a change in remote protocol behaviour. Reasons why this might be OK: - vFile:stat was only added in GDB 16, so it's not been "in the wild" for too long yet. If we're quick, we might be able to "fix" this before anyone realises I messed up. - The documentation for vFile:stat is pretty vague. It certainly doesn't explicitly say "this does an lstat". Most implementers would (I think), given the name, start by assuming this should be a 'stat' (given the name). Only if they ran the full GDB testsuite, or examined GDB's implementation, would they know to use lstat. Reasons why this might not be OK: - Some other debug client could be connecting to gdbserver, sending vFile:stat and expecting to get lstat behaviour. This would break after this patch. - Some other remote server might have implemented vFile:stat support, and either figured out, or copied, the lstat behaviour from gdbserver. This remote server would technically be wrong after this commit, but as GDB no longer uses vFile:stat, then this will only become a problem if/when GDB or some other client starts to use vFile:stat in the future. Given the vague documentation for vFile:stat, and that it was only added in GDB 16, I think we should fix it now to perform a 'stat', and that is what this commit does. The change in behaviour is documented in the NEWS file. I've improved the vFile:stat documentation in the manual to better explain what is expected from this packet, and I've extended the existing test to cover vFile:stat. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
67 lines
2.4 KiB
Plaintext
67 lines
2.4 KiB
Plaintext
# Copyright 2025 Free Software Foundation, Inc.
|
|
#
|
|
# This program is free software; you can redistribute it and/or modify
|
|
# it under the terms of the GNU General Public License as published by
|
|
# the Free Software Foundation; either version 3 of the License, or
|
|
# (at your option) any later version.
|
|
#
|
|
# This program is distributed in the hope that it will be useful,
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
# GNU General Public License for more details.
|
|
#
|
|
# You should have received a copy of the GNU General Public License
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
# Test some remote file I/O. The associated Python script uses the
|
|
# Python API to create and send vFile:* packets to gdbserver to
|
|
# perform actions like 'stat'. The same action is then performed
|
|
# directly from Python (e.g. a 'stat' is performed), and the results,
|
|
# from gdbserver, and from the local syscall, are compared.
|
|
|
|
load_lib gdb-python.exp
|
|
load_lib gdbserver-support.exp
|
|
|
|
require allow_python_tests
|
|
require allow_gdbserver_tests
|
|
require {!is_remote host}
|
|
require {!is_remote target}
|
|
|
|
standard_testfile
|
|
|
|
clean_restart
|
|
|
|
# Make sure we're disconnected, in case we're testing with an
|
|
# extended-remote board, therefore already connected.
|
|
gdb_test "disconnect" ".*"
|
|
|
|
set pyfile [gdb_remote_download host ${srcdir}/${subdir}/${testfile}.py]
|
|
gdb_test_no_output "source $pyfile" "source the script"
|
|
|
|
# Start gdbserver, but always in extended-remote mode, and then
|
|
# connect to it from GDB.
|
|
set res [gdbserver_start "--multi --once" ""]
|
|
set gdbserver_protocol "extended-remote"
|
|
set gdbserver_gdbport [lindex $res 1]
|
|
gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport
|
|
|
|
gdb_test_no_output "set python print-stack full"
|
|
|
|
set test_file_1 [standard_output_file "test_file_1"]
|
|
remote_exec host "touch $test_file_1"
|
|
|
|
set test_file_2 [standard_output_file "test_file_2"]
|
|
remote_exec host "ln -s $test_file_1 $test_file_2"
|
|
|
|
gdb_test "python check_lstat(\"$test_file_1\")" "PASS" \
|
|
"check remote lstat works on a normal file"
|
|
|
|
gdb_test "python check_lstat(\"$test_file_2\")" "PASS" \
|
|
"check remote lstat works on a symbolic link"
|
|
|
|
gdb_test "python check_stat(\"$test_file_1\")" "PASS" \
|
|
"check remote stat works on a normal file"
|
|
|
|
gdb_test "python check_stat(\"$test_file_2\")" "PASS" \
|
|
"check remote stat works on a symbolic link"
|