https://bugs.kde.org/show_bug.cgi?id=506928
--- Comment #2 from Mark Wielaard <[email protected]> --- Hi Martin, (In reply to mcermak from comment #1) > (In reply to Mark Wielaard from comment #0) > > Note that the struct ustat has two fields which differ on some > > architectures. > > f_tfree is a long on sparc and mips, but an int on all others. > > f_tinode is an unsigned int on alpha and s390, but unsigned long on all > > others. > > After cross-compiling vmlinux and querying it with pahole, I can see that > too \o/. That is real dedication! Please don't feel like you have to cross-compile the kernel. In most cases it can be found in the kernel sources. In this case include/linux/types.h has the kernel struct ustat. A git grep ARCH_32BIT_USTAT_F_TINODE then finds the arches which use unsigned int vs unsigned long. > Assuming sparc and alpha aren't actively supported by valgrind today, I've > only > handled this for mips and s390x. Yes, thanks. There is an out of tree sparc port, but it is incomplete. A different way to handle this is to define the struct vki_ustat in each separate include/vki/vki-<arch>-linux.h file instead of vki-linux.h so you don't need #ifdefs. > The first param of ustat is u32 in kernel. Which in practice should be > equivalent > to unsigned int. But to guarantee 32bits, I've included stdint.h and used > uint32_t. There is __vki_u32 for that. Which gives you the kernel's type (if defining kernel structs). For internal VEX/Valgrind types you can use Uint (Always 32 bits) as defined in VEX/pub/libvex_basictypes.h Better not use stdint.h types which might not precisely match on the Host or kernel types. > I'm not sure if *flags |= SfMayBlock; should be used here. It's a disk > operation so > maybe it should (?) It probably doesn't need it. It doesn't look it really blocks (indefinitely). It might want a FUSE_COMPATIBLE_MAY_BLOCK(); like statfs. FUSE_COMPATIBLE_MAY_BLOCK(); does a SfMayBlock only when running with --sim-hints=fuse-compatible which indicates the program might implement a fuse file system itself, so it might need a thread switch to handle the kernel calling back into the program itself. > > char f_fname[6] and char f_fpack[6] are the same everywhere, but unused > > (filled with zeros). > > How can this note be used in the valgrind source? You are already doing that already with POST_MEM_WRITE( ARG1, sizeof(struct vki_ustat) ); which includes those two fields. memcheck is interested in which bits are defined, it doesn't really care about the value. > Please, review the attached patch. OK, after lunch :) -- You are receiving this mail because: You are watching all bug changes.
