Running a binary that does these two calls: lseek(fd, 5, SEEK_SET); pos = lseek(fd, 0, SEEK_HOLE); truss reports: lseek(3,0x500000003,SEEK_SET) = 5 (0x5) lseek(3,0x0,SEEK_SET) = 10 (0xa) which is clearly wrong. Isn't lseek one of these calls that have a shuffled argument order due to 64 bit arguments? Perhaps the decoding tables in truss need to be fixed to account for this.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ebbc3140ca0d7eee154f7a67ccdae7d3d88d13fd commit ebbc3140ca0d7eee154f7a67ccdae7d3d88d13fd Author: Olivier Houchard <cognet@FreeBSD.org> AuthorDate: 2021-09-22 22:45:42 +0000 Commit: Olivier Houchard <cognet@FreeBSD.org> CommitDate: 2021-09-22 23:04:16 +0000 truss: Decode correctly 64bits arguments on 32bits arm. When decoding 32bits arm syscall, make sure we account for the padding when decoding 64bits args. Do it too when using a 64bits truss on a 32bits binary. MFC After: 1 week PR: 256199 usr.bin/truss/syscalls.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-)