Re: [PATCH 05/15] tests: Fix mocking of open()
On 7/2/25 12:23, Ján Tomko wrote:
On a Thursday in 2025, Michal Privoznik via Devel wrote:
> From: Michal Privoznik <mprivozn(a)redhat.com>
>
> In some cases (well, majority), open() is either rewritten to
> open64(), either by plain '#define open open64') or at assembly
> level (using __REDIRECT macro). See <fcntl.h> for more info.
>
> This didn't really matter to us, because we do not chain load two
> mocks that would need to reimplement open() at the same time. But
> this is soon going to change.
>
> The problem is, that VIR_MOCK_REAL_INIT(open) glances over
> aforementioned rewrite and initializes real_open pointer to
> open() from the standard C library. But it needs to point to
> open() (well, open64()) from the next mock on the list.
>
> Therefore, init real_open to open64().
I cannot find it in the git history. Did we use to mock open64
separately? Or was that one of the other open's glibc might expand it
to?
I don't remember us ever caring about this. As far as I remember we
initially mocked just open(). Then as of
commit b7e6513a018a897f6ac3f800eae14ff5be6f43f2
tests: mock __open_2()
we mock __open_2() too, because under some circumstances open() might be
aliased to __open_2(). But that's slightly tangent to the problem I'm
fixing here.
Our VIR_MOCK_REAL_INIT() macro basically does (when expanded):
real_open = dlsym(RTLD_NEXT, "open");
but combined with fcntl.h header, which has:
#define open open64
our open() in mocks becomes:
int
open64(...)
{
...
return reeal_open(...);
}
dlsym() succeeds because libc has the "open" symbol, but if we want to
chain mocks then we need to look up "open64" symbol.
Michal