-
Notifications
You must be signed in to change notification settings - Fork 588
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for readlinkat syscall #1579
Conversation
I ran whole test suite with
Both of the highlighted tests fail also on vanilla
|
|
||
ret = untraced_syscall4(syscallno, dirfd, path, buf2, bufsiz); | ||
ptr = copy_output_buffer(ret, ptr, buf, buf2); | ||
return commit_raw_syscall(syscallno, ptr, ret); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need syscall buffering support unless some real workload does a lot of readlinkat
calls, e.g. more than a thousand.
Merged with those changes: e64e82e |
thank you |
The next issue you're hitting is a DRM-related ioctl. We don't support those in rr currently. rr tries to block access to [Another option would be to actually support the DRM ioctls in rr, but that's a significantly bigger project and depending on how the kernel/user interface works, may not even be possible. In particular if the kernel/driver writes to memory that's read from user space with no intervening synchronizing operations visible to rr (i.e. a syscall), it won't work.] |
I'm not sure why I used
Is there something I could do here? However, now that you mentioned there should be a fallback to llvmpipe, I tested |
Don't strace rr-running-your-application, just strace your application directly without rr. |
You can also use |
full strace is here: http://fpaste.org/287429/ Could it be that I created this problem myself now? Starting at line 1253:
From original report, it previously failed in this manner:
|
That's where we get the file descriptor that we subsequently do ioctls on, so no wonder it wasn't blocked. It's coming over the X socket so we don't really want to monkey with that. There are a few things we can try here:
|
I based most of the code on
readlink
syscall already there. The test is by no means exhaustive, but passes.Can you please comment if there's more testing needed?
This does not solve #1578 completely for me, but at least takes me a bit further and the error looks unrelated: