On Tue, 7 Apr 2020 at 11:37, Laurent Vivier <laur...@vivier.eu> wrote:
>
> Le 06/04/2020 à 17:18, Andreas Schwab a écrit :
> > The glibc getcwd function returns different errors than the getcwd
> > syscall, which triggers an assertion failure in the glibc getcwd function
> > when running under the emulation.
What exactly are the differences in errors ?
> > ---
> According to the commit introducing the function, it could break fakeroot:
>
> commit 3b3f24add09f8ab720860d4840f9755c102121b5
> Author: Aurelien Jarno <aurel...@aurel32.net>
> Date: Wed Apr 15 16:12:13 2009 +0000
>
> linux-user: prefer glibc over direct syscalls
>
> The openat/*at syscalls are incredibly common with modern coreutils,
> calling them directly via syscalls breaks for example fakeroot. Use
> glibc stubs whenever directly available and provide old syscall
> calling for people still using older libc.
I don't think (based on a quick grep of the fakeroot sources) that
fakeroot intercepts 'getcwd', so this patch is probably ok on this
front. It looks like the syscalls that fakeroot cares about that
that patch was trying to improve our handling for are the
ones like fstatat which return the kind of permission/ownership
info fakeroot wants to alter (not including 'openat', despite
that being the only function named in full in the commit message...)
More generally, we rely on making direct syscalls for at least
some syscalls for signal-handling related correctness, so if
that ever comes into conflict with QEMU continuing to work under
'fakeroot' then fakeroot-compatilibity is going to lose...
('fakeroot-ng' would still work, as it intercepts syscalls
via ptrace.)
thanks
-- PMM
