Mathieu Othacehe writes:
Hello Mathieu,
>> So stat, lstat, and all other related function will return -EOVERFLOW
>> unless their 64 bits stat64, lstat64 counterpart is used.
>>
>> So I think this means that one cannot build the Guix bootstrap toolchain on
>> an
>> NVME disk.
>
> After further investigations I think that it is needed to patch GNU Mes
> to fix this bug.
Hmm, we need to patch Mes after all. That's unfortunate.
> We would need to add three new syscalls for x86:
>
> #define SYS_stat64 0xc3
> #define SYS_lstat64 0xc4
> #define SYS_fstat64 0xc5
>
>
> lib/linux/stat.c should be modified this way:
>
> #if __i386__
> #define STAT_SYSCALL SYS_stat64
> #else
> #define STAT_SYSCALL SYS_stat
> #endif
Ah...the stat64 syscall is meant for i386; now it at starts making at
least some sense to me.
> int
> stat (char const *file_name, struct stat *statbuf)
> {
> struct stat64 statbuf64;
> int ret;
>
> ret = _sys_call2 (STAT_SYSCALL, (long) file_name, (long) &statbuf64);
>
> #if __i386__
> stat64_to_32(&statbuf64, statbuf);
> #else
> *statbuf = statbuf64;
> #endif
>
> return ret;
> }
That looks OK...
> Then we would need to create stat64_to_32 which could be inspired from
> __xstat64_conv from the glibc. Then, lstat and fstat64 would need to be
> patched the same way.
>
> This way, we would replicate the glibc behavior.
Beautiful, thanks for getting to the bottom of this. Now that you
already have gone this far, would you like to whip-up a full patch for
GNU Mes?
To test it we may have to provide a tarball as we don't want to use XZ
and we don't have patch yet. Or possibly we can download some
individual files ande overwrite them.
Greetings,
Janneke
--
Jan Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
