Le 25/11/2019 à 21:54, Aleksandar Markovic a écrit :
>>> 4. NEW PROPOSAL :
>>>
>>> early: read(3,0xff80038c,512)
>>> late: = 512
>>> [(3,"\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2bl\0\0\04"...,512)]
>>> early: getcwd(0x18180,4096)
>>> late: = 9 [("/usr/bin",4096)]
>>>
>>> In other words, we would print for (selected) system calls content of
>>> the parameters both before and after actual ioctl
>>> translation/execution.
>> I don't like this.
>> IMHO it just adds unnecessary noise and differs from what a native strace
>> shows.
>>
> QEMU strace doesn't have to be the same as native strace. Actually,
> they could be used even at the same time: QEMU provides info on target
> syscall, strace on host syscall. Do not forget that not all syscalls
> are implemeted as one-to-one-correspondence between target and host
> syscalls - combination of QEMU strace and native strace is precious at
> some moments.
>
> In any case, I think that requiring QEMU strace to look exactly like
> native strace is a self-imposed limitation, that does not have enough
> justification. Think of it, wouldn't it be nice to surpass strace,
> like in these cases above?
I'd like to have a QEMU_STRACE formatting similar to the host strace
formatting because it makes debugging easier: we can run the same
program in guest and host and compare the strace output to see where it
differs and thus where the problem appears.
Thanks,
Laurent
