[WRAPPER] Fix FTSENT layout mismatch - #4329
Conversation
4d60f97 to
0f37c91
Compare
ksco
left a comment
ksco
left a comment
There was a problem hiding this comment.
PR title says RISC-V but the changes are not restricted to RISC-V. How about Arm64, LoongArch and PPC64LE?
| unsigned long long int u_debugreg [8]; | ||
| } my_x64_user_t; | ||
|
|
||
| struct x64_ftsent { /* x86_64 riscv64 */ |
There was a problem hiding this comment.
Paste related kernel/libc source links to prove this.
There was a problem hiding this comment.
Yes, it should not restricted to RISC-V.
#ifdef __x86_64__
# define __NLINK_T_TYPE __SYSCALL_ULONG_TYPE
# define __FSWORD_T_TYPE __SYSCALL_SLONG_TYPE
#else
# define __NLINK_T_TYPE __UWORD_TYPE
# define __FSWORD_T_TYPE __SWORD_TYPE
#endif
FTSENT define: https://github.com/gnutools/glibc/blob/c3a3a9808ad3ab4a3336836833f83288b672ccbf/io/fts.h
__NLINK_T_TYPE define: https://github.com/gnutools/glibc/blob/c3a3a9808ad3ab4a3336836833f83288b672ccbf/sysdeps/unix/sysv/linux/x86/bits/typesizes.h
There was a problem hiding this comment.
I meant that you should add related links into the code as comments.
0f37c91 to
2f06a9c
Compare
lz-bro
changed the title
ce41794 to
91d1170
Compare
| uint16_t fts_flags; /* 100 */ /* 96 */ | ||
| uint16_t fts_instr; /* 102 */ /* 98 */ | ||
| uint32_t _pad1; /* 104 */ /* --- */ | ||
| struct x64_stat64 *fts_statp; /* 112 */ /* 104 */ |
There was a problem hiding this comment.
_pad1 is 104, but suddenly fts_statp becomes 112?
Bad math, sorry.
There was a problem hiding this comment.
Also, where does the _pad1 come from? I looked into the link you pasted in the comments, but I didn't find _pad1.
| GOM(fts_open, pFEpip) | ||
| GO(fts_read, pFp) | ||
| GOM(fts_read, pFEp) | ||
| GO(fts_set, iFppi) |
There was a problem hiding this comment.
Are you sure that we don't need to wrap other fts functions?
| } | ||
| if (!node) { | ||
| node = malloc(sizeof(struct fts_node)); | ||
| if (!node) return ENOMEM; |
| fts_list = node; | ||
| } | ||
| struct ftsent_node* n = malloc(sizeof(struct ftsent_node)); | ||
| if (!n) return ENOMEM; |
| pthread_mutex_unlock(&fts_mutex); | ||
| } | ||
|
|
||
| void AlignFTSENT(void* dest, void* source) |
91d1170 to
e045cc4
Compare
|
Question: instead of using a hash-table with a lock, wich works but add a lot of complexity, why not using an in-place "align / unalign" scheme, like with box32 inplace shrink/unshrink, as the structure seems to have the same memory footprint on x64 & native architecture, that should be possible, and would be more efficient and simpler? |
Translate native FTSENT structures to x86-64 layout in fts_read wrapper. Handle nlink_t size difference (4 vs 8 bytes), stat structure translation, and linked-list pointer resolution via per-FTS mapping table.
e045cc4 to
3ce6cc0
Compare
|
But this will disrupt the internal state of the structure? I see that functions like |
3 participants
Translate native FTSENT structures to x86-64 layout in fts_read wrapper. Handle nlink_t size difference (4 vs 8 bytes), stat structure translation, and linked-list pointer resolution via per-FTS mapping table.