Bug 256199
| Summary: | truss: lseek() decoded incorrectly on armv7 | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Robert Clausecker <fuz> |
| Component: | bin | Assignee: | Olivier Houchard <cognet> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | --- | ||
| Version: | 13.0-STABLE | ||
| Hardware: | arm | ||
| OS: | Any | ||
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(-) |
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.