Skip to content

Conversation

qianxichen233
Copy link
Contributor

@qianxichen233 qianxichen233 commented Aug 20, 2025

This PR is splited from PR #164

This PR focuses on spliting out the fix for writev syscall and iovec struct

Since iovec has addresses inside its struct, it becomes a little tricky to handle it correctly in lind. One padding fields is added below to each address field to resolve the issue of 32-bit address and 64-bit address. Therefore, the padding fields also needs to be cleaned up before sending to the rawposix

@rennergade rennergade changed the title fix migration - glibc/rawposix - writev/iovec fix glibc/rawposix - writev/iovec fix Aug 20, 2025
Copy link
Contributor

@rennergade rennergade left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

explain in the description and in a comment somewhere why this is needed

@rennergade
Copy link
Contributor

Also needs to pass linter

@@ -24,6 +24,13 @@
ssize_t
__writev (int fd, const struct iovec *iov, int iovcnt)
{
// clean up padding field of each iovec
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why?

translate_vmmap_addr(&cage, arg2).unwrap() as *const IovecStruct;
// iterate through each iovec pointer and manually do the address conversion
for i in 0..iovcnt {
let cur_iov_base = unsafe { iov_base.add(i as usize) } as *mut libc::iovec;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we don't use current type casting function?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants