On 7/2/25 12:23, Ján Tomko wrote:
> On a Thursday in 2025, Michal Privoznik via Devel wrote:
>> From: Michal Privoznik <mpriv...@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
