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