External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-22 05:35:25 +00:00
Code Issues Packages Projects Releases Wiki Activity
master
libvirt/tests/virmockstathelpers.c

379 lines
10 KiB
C
Raw Permalink Normal View History

tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
/*
* Copyright (C) 2019 Red Hat, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see
* <http://www.gnu.org/licenses/>.
*
* Helpers for dealing with the many variants of stat(). This
* C file should be included from any file that wants to mock
* stat() correctly.
*/
#include "virmock.h"
#include <sys/stat.h>
#include <unistd.h>
/*
* The POSIX stat() function might resolve to any number of different
* symbols in the C library.
*
* The may be an additional stat64() function exposed by the headers
* too.
*
* On 64-bit hosts the stat & stat64 functions are identical, always
tests: fix misc spelling errors reported by codespell Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-10-02 14:07:27 +00:00
* referring to the 64-bit ABI.
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
*
* On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively.
*
meson: tests: virmockstathelpers: replace check for _FILE_OFFSET_BITS Meson always defines _FILE_OFFSET_BITS=64 which effectively makes mocking of non 64-bit stat functions dead code. On linux it was not an issue because we use the 64-bit versions but on FreeBSD there are not 64-bit versions, there is only stat & lstat. We cannot simply drop the check as that would resolve to compilation error on 64-bit linux: {standard input}: Assembler messages: {standard input}:11468: Error: symbol `__xstat64' is already defined {standard input}:11679: Error: symbol `__xstat64.cold' is already defined {standard input}:12034: Error: symbol `__lxstat64' is already defined {standard input}:12245: Error: symbol `__lxstat64.cold' is already defined So we have to replace the _FILE_OFFSET_BITS with a check if the corresponding 64-bit version of the stat function exists. Replicate the meson behavior by always defining _FILE_OFFSET_BITS instead of using AC_SYS_LARGEFILE otherwise this change would break our tests. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-24 12:02:39 +00:00
* With meson libvirt will have _FILE_OFFSET_BITS=64 always defined.
* On 32-bit hosts it causes the C library to transparently rewrite
* stat() calls to be stat64() calls. Libvirt will never see the 32-bit
* ABI from the traditional stat() call. We cannot assume this rewriting
* is done using a macro. It might be, but on GLibC it is done with a
* magic __asm__ statement to apply the rewrite at link time instead of
* at preprocessing.
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
*
* In GLibC there may be two additional functions exposed by the headers,
* __xstat() and __xstat64(). When these exist, stat() and stat64() are
* transparently rewritten to call __xstat() and __xstat64() respectively.
tests: fix misc spelling errors reported by codespell Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-10-02 14:07:27 +00:00
* The former symbols will not actually exist in the library at all, only
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
* the header. The leading "__" indicates the symbols are a private impl
* detail of the C library that applications should not care about.
* Unfortunately, because we are trying to mock replace the C library,
* we need to know about this internal impl detail.
*
virmockstathelpers: Load aliases for 64-bit time On 32-bit arches, it's possible not only to request -D_FILE_OFFSET_BITS=64 (which is always done with meson) but also -D_TIME_BITS=64. With glibc, both of these affect what variant of stat() or lstat() is called. With 64 bit time it's: __stat64_time64() or __lstat64_time64(), respectively. Fortunately, no other variant (__xstat(), __xstat64()) has _time64 alternative and thus does not need similar treatment. Similarly, musl is not affected by this. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/404 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-18 16:13:22 +00:00
* Furthermore, support for 64-bit time can be enabled, which on 32-bit
* systems with glibc overwrites stat64() to __stat64_time64() and lstat64()
* to __lstat64_time64().
*
tests: Re-introduce stat/lstat mocks on macOS Commit d6b17edd5163 ("tests: Lookup extended stat/lstat in mocks") adds support for mocking of stat() and lstat() on macOS. The change was broken because virmockstathelpers.c only follows glibc logic and MOCK_STAT and MOCK_LSTAT are not getting defined on macOS. Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-18 15:30:57 +00:00
* On macOS stat() and lstat() are resolved to _stat$INODE64 and
* _lstat$INODE64, respectively. stat(2) man page also declares that
tests: Improve macOS stat() mocking logic We should not mock stat64() when building on Apple Silicon, because the declaration is not present in the header file. Detect this situation and handle it gracefully. https://gitlab.com/libvirt/libvirt/-/issues/121 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-03 11:32:46 +00:00
* stat64(), lstat64() and fstat64() are deprecated, and when
* building on Apple Silicon (aarch64) those functions are missing
* from the header altogether and should not be mocked.
tests: Re-introduce stat/lstat mocks on macOS Commit d6b17edd5163 ("tests: Lookup extended stat/lstat in mocks") adds support for mocking of stat() and lstat() on macOS. The change was broken because virmockstathelpers.c only follows glibc logic and MOCK_STAT and MOCK_LSTAT are not getting defined on macOS. Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-18 15:30:57 +00:00
*
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
* With all this in mind the list of functions we have to mock will depend
* on several factors
*
meson: tests: virmockstathelpers: replace check for _FILE_OFFSET_BITS Meson always defines _FILE_OFFSET_BITS=64 which effectively makes mocking of non 64-bit stat functions dead code. On linux it was not an issue because we use the 64-bit versions but on FreeBSD there are not 64-bit versions, there is only stat & lstat. We cannot simply drop the check as that would resolve to compilation error on 64-bit linux: {standard input}: Assembler messages: {standard input}:11468: Error: symbol `__xstat64' is already defined {standard input}:11679: Error: symbol `__xstat64.cold' is already defined {standard input}:12034: Error: symbol `__lxstat64' is already defined {standard input}:12245: Error: symbol `__lxstat64.cold' is already defined So we have to replace the _FILE_OFFSET_BITS with a check if the corresponding 64-bit version of the stat function exists. Replicate the meson behavior by always defining _FILE_OFFSET_BITS instead of using AC_SYS_LARGEFILE otherwise this change would break our tests. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-24 12:02:39 +00:00
* - If the stat or __xstat but there is no 64-bit version.
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
*
* - If __xstat & __xstat64 exist, then stat & stat64 will not exist
* as symbols in the library, so the latter should not be mocked.
*
tests: fix stat mocking with Fedora rawhide GLibC has a really complicated way of dealing with the 'stat' function historically, which means our mocks in turn have to look at four different possible functions to replace, stat, stat64, __xstat, __xstat64. In Fedora 33 and earlier: - libvirt.so links to __xstat64 - libc.so library exports stat, stat64, __xstat, __xstat64 - sys/stat.h header exposes stat and __xstat In Fedora 34 rawhide: - libvirt.so links to stat64 - libc.so library exports stat, stat64, __xstat, __xstat64 - sys/stat.h header exposes stat Historically we only looked at the exported symbols from libc.so to decide which to mock. In F34 though we must not consider __xstat / __xstat64 though because they only existance for binary compatibility. Newly built binaries won't reference them. Thus we must introduce a header file check into our logic for deciding which symbol to mock. We must ignore the __xstat / __xstat64 symbols if they don't appear in the sys/stat.h header, even if they appear in libc.so Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-29 17:25:07 +00:00
* - If __xstat exists in the library, but not the header than it
* it is just there for binary back compat and should not be
* mocked
*
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
* The same all applies to lstat()
*/
tests: Split macOS stat() mocking logic On macOS, most of the symbols and declarations that we look at to determine which versions of stat() we need to mock are not present; on the other hand, there are some specific wrinkles that are introduced with Apple Silicon which we will need to take care of. To avoid making the logic even more of an opaque mess than it currently is, move the macOS part to a separate branch. This commit is better viewed with 'git show -w'. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-03 11:32:13 +00:00
#if !defined(__APPLE__)
# if !defined(WITH___XSTAT_DECL)
# if defined(WITH_STAT)
# if !defined(WITH___XSTAT) && !defined(WITH_STAT64)
# define MOCK_STAT
# endif
tests: fix stat mocking with Fedora rawhide GLibC has a really complicated way of dealing with the 'stat' function historically, which means our mocks in turn have to look at four different possible functions to replace, stat, stat64, __xstat, __xstat64. In Fedora 33 and earlier: - libvirt.so links to __xstat64 - libc.so library exports stat, stat64, __xstat, __xstat64 - sys/stat.h header exposes stat and __xstat In Fedora 34 rawhide: - libvirt.so links to stat64 - libc.so library exports stat, stat64, __xstat, __xstat64 - sys/stat.h header exposes stat Historically we only looked at the exported symbols from libc.so to decide which to mock. In F34 though we must not consider __xstat / __xstat64 though because they only existance for binary compatibility. Newly built binaries won't reference them. Thus we must introduce a header file check into our logic for deciding which symbol to mock. We must ignore the __xstat / __xstat64 symbols if they don't appear in the sys/stat.h header, even if they appear in libc.so Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-29 17:25:07 +00:00
# endif
tests: Split macOS stat() mocking logic On macOS, most of the symbols and declarations that we look at to determine which versions of stat() we need to mock are not present; on the other hand, there are some specific wrinkles that are introduced with Apple Silicon which we will need to take care of. To avoid making the logic even more of an opaque mess than it currently is, move the macOS part to a separate branch. This commit is better viewed with 'git show -w'. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-03 11:32:13 +00:00
# if defined(WITH_STAT64)
# define MOCK_STAT64
# endif
# else /* WITH___XSTAT_DECL */
# if defined(WITH___XSTAT) && !defined(WITH___XSTAT64)
# define MOCK___XSTAT
# endif
# if defined(WITH___XSTAT64)
# define MOCK___XSTAT64
# endif
# endif /* WITH___XSTAT_DECL */
# if !defined(WITH___LXSTAT_DECL)
# if defined(WITH_LSTAT)
# if !defined(WITH___LXSTAT) && !defined(WITH_LSTAT64)
# define MOCK_LSTAT
# endif
tests: fix stat mocking with Fedora rawhide GLibC has a really complicated way of dealing with the 'stat' function historically, which means our mocks in turn have to look at four different possible functions to replace, stat, stat64, __xstat, __xstat64. In Fedora 33 and earlier: - libvirt.so links to __xstat64 - libc.so library exports stat, stat64, __xstat, __xstat64 - sys/stat.h header exposes stat and __xstat In Fedora 34 rawhide: - libvirt.so links to stat64 - libc.so library exports stat, stat64, __xstat, __xstat64 - sys/stat.h header exposes stat Historically we only looked at the exported symbols from libc.so to decide which to mock. In F34 though we must not consider __xstat / __xstat64 though because they only existance for binary compatibility. Newly built binaries won't reference them. Thus we must introduce a header file check into our logic for deciding which symbol to mock. We must ignore the __xstat / __xstat64 symbols if they don't appear in the sys/stat.h header, even if they appear in libc.so Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-29 17:25:07 +00:00
# endif
tests: Split macOS stat() mocking logic On macOS, most of the symbols and declarations that we look at to determine which versions of stat() we need to mock are not present; on the other hand, there are some specific wrinkles that are introduced with Apple Silicon which we will need to take care of. To avoid making the logic even more of an opaque mess than it currently is, move the macOS part to a separate branch. This commit is better viewed with 'git show -w'. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-03 11:32:13 +00:00
# if defined(WITH_LSTAT64)
# define MOCK_LSTAT64
# endif
# else /* WITH___LXSTAT_DECL */
# if defined(WITH___LXSTAT) && !defined(WITH___LXSTAT64)
# define MOCK___LXSTAT
# endif
# if defined(WITH___LXSTAT64)
# define MOCK___LXSTAT64
# endif
# endif /* WITH___LXSTAT_DECL */
#else /* __APPLE__ */
# define MOCK_STAT
tests: Improve macOS stat() mocking logic We should not mock stat64() when building on Apple Silicon, because the declaration is not present in the header file. Detect this situation and handle it gracefully. https://gitlab.com/libvirt/libvirt/-/issues/121 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-03 11:32:46 +00:00
# if defined(WITH_STAT64_DECL)
# define MOCK_STAT64
# endif
tests: Split macOS stat() mocking logic On macOS, most of the symbols and declarations that we look at to determine which versions of stat() we need to mock are not present; on the other hand, there are some specific wrinkles that are introduced with Apple Silicon which we will need to take care of. To avoid making the logic even more of an opaque mess than it currently is, move the macOS part to a separate branch. This commit is better viewed with 'git show -w'. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-03 11:32:13 +00:00
# define MOCK_LSTAT
tests: Improve macOS stat() mocking logic We should not mock stat64() when building on Apple Silicon, because the declaration is not present in the header file. Detect this situation and handle it gracefully. https://gitlab.com/libvirt/libvirt/-/issues/121 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-03 11:32:46 +00:00
# if defined(WITH_LSTAT64_DECL)
# define MOCK_LSTAT64
# endif
tests: Split macOS stat() mocking logic On macOS, most of the symbols and declarations that we look at to determine which versions of stat() we need to mock are not present; on the other hand, there are some specific wrinkles that are introduced with Apple Silicon which we will need to take care of. To avoid making the logic even more of an opaque mess than it currently is, move the macOS part to a separate branch. This commit is better viewed with 'git show -w'. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-03 11:32:13 +00:00
#endif
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
virmockstathelpers: Adapt to musl-1.2.4 With musl-1.2.3: I get the following macros defined (from $builddir/meson-config.h): #define WITH_LSTAT 1 #define WITH_LSTAT64 1 #define WITH_LSTAT_DECL 1 #define WITH_STAT 1 #define WITH_STAT64 1 #define WITH_STAT_DECL 1 #define WITH___LXSTAT 1 #define WITH___LXSTAT64 1 #define WITH___XSTAT 1 #define WITH___XSTAT64 1 which in turn means the virmockstathelpers.c ends up defining: MOCK_STAT64 MOCK_LSTAT64 But with musl-1.2.4 everything changes and the set of defined macros gets simplified to: #define WITH_LSTAT 1 #define WITH_LSTAT_DECL 1 #define WITH_STAT 1 #define WITH_STAT_DECL 1 #define WITH___LXSTAT 1 #define WITH___XSTAT 1 which results in no MOCK_* macros defined in virmockstathelpers.c, i.e. no stat() mocking, nada. The reason for this simplification are these musl commits [1][2] which removed all 64 bit aliases. And that's not what our logic for deciding what flavor of stat() to mock counted with. Nevertheless, we do build with Alpine Linux in our CI, so how come we don't see this problem there? Well, simply because Alpine Linux maintainers decided to revert the commits [3][4]. But on distributions that use vanilla musl, this problem can be seen easily. 1: https://git.musl-libc.org/cgit/musl/commit/?id=246f1c811448f37a44b41cd8df8d0ef9736d95f4 2: https://git.musl-libc.org/cgit/musl/commit/?id=25e6fee27f4a293728dd15b659170e7b9c7db9bc 3: https://git.alpinelinux.org/aports/commit/main/musl?id=6a5563fbb45b3d9d60678d7bbf60dbb312a2d481 4: https://git.alpinelinux.org/aports/commit/main/musl?id=a089bd852f8983623fa85e0f5755a3e25bf53c72 Resolves: https://bugs.gentoo.org/906167 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2023-05-15 09:56:51 +00:00
#if !defined(MOCK_STAT) && !defined(MOCK_STAT64) && \
!defined(MOCK___XSTAT) && !defined(MOCK___XSTAT64)
# define MOCK_STAT
#endif
#if !defined(MOCK_LSTAT) && !defined(MOCK_LSTAT64) && \
!defined(MOCK___LXSTAT) && !defined(MOCK___LXSTAT64)
# define MOCK_LSTAT
#endif
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
#ifdef MOCK_STAT
static int (*real_stat)(const char *path, struct stat *sb);
#endif
#ifdef MOCK_STAT64
static int (*real_stat64)(const char *path, struct stat64 *sb);
#endif
#ifdef MOCK___XSTAT
static int (*real___xstat)(int ver, const char *path, struct stat *sb);
#endif
#ifdef MOCK___XSTAT64
static int (*real___xstat64)(int ver, const char *path, struct stat64 *sb);
#endif
#ifdef MOCK_LSTAT
static int (*real_lstat)(const char *path, struct stat *sb);
#endif
#ifdef MOCK_LSTAT64
static int (*real_lstat64)(const char *path, struct stat64 *sb);
#endif
#ifdef MOCK___LXSTAT
static int (*real___lxstat)(int ver, const char *path, struct stat *sb);
#endif
#ifdef MOCK___LXSTAT64
static int (*real___lxstat64)(int ver, const char *path, struct stat64 *sb);
#endif
static bool init;
static bool debug;
#define fdebug(msg, ...) do { if (debug) fprintf(stderr, msg, __VA_ARGS__); } while (0)
static void virMockStatInit(void)
{
if (init)
return;
init = true;
debug = getenv("VIR_MOCK_STAT_DEBUG");
#ifdef MOCK_STAT
tests: Only mock $INODE64 symbols on x86_64 macOS The version of macOS running on Apple Silicon doesn't need to concern itself with backwards compatibility with 32-bit applications, and so it could jettison all the symbol aliasing shenanigans involved. https://gitlab.com/libvirt/libvirt/-/issues/121 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com> Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
2021-02-04 14:48:18 +00:00
# if defined(__APPLE__) && defined(__x86_64__)
tests: Lookup extended stat/lstat in mocks macOS syscall interface (/usr/lib/system/libsystem_kernel.dylib) has three kinds of stat but only one of them can be used to fill "struct stat": stat$INODE64. virmockstathelpers looks up regular stat instead of stat$INODE64. That causes a failure in qemufirmwaretest because "struct stat" is laid out differently from the values returned by stat. Introduce VIR_MOCK_REAL_INIT_ALIASED that can be used to lookup stat$INODE64 and lstat$INODE64 and use it to setup real functions on macOS. Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
2019-08-21 16:13:20 +00:00
VIR_MOCK_REAL_INIT_ALIASED(stat, "stat$INODE64");
# else
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
VIR_MOCK_REAL_INIT(stat);
tests: Lookup extended stat/lstat in mocks macOS syscall interface (/usr/lib/system/libsystem_kernel.dylib) has three kinds of stat but only one of them can be used to fill "struct stat": stat$INODE64. virmockstathelpers looks up regular stat instead of stat$INODE64. That causes a failure in qemufirmwaretest because "struct stat" is laid out differently from the values returned by stat. Introduce VIR_MOCK_REAL_INIT_ALIASED that can be used to lookup stat$INODE64 and lstat$INODE64 and use it to setup real functions on macOS. Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
2019-08-21 16:13:20 +00:00
# endif
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
fdebug("real stat %p\n", real_stat);
#endif
#ifdef MOCK_STAT64
virmockstathelpers: Load aliases for 64-bit time On 32-bit arches, it's possible not only to request -D_FILE_OFFSET_BITS=64 (which is always done with meson) but also -D_TIME_BITS=64. With glibc, both of these affect what variant of stat() or lstat() is called. With 64 bit time it's: __stat64_time64() or __lstat64_time64(), respectively. Fortunately, no other variant (__xstat(), __xstat64()) has _time64 alternative and thus does not need similar treatment. Similarly, musl is not affected by this. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/404 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-18 16:13:22 +00:00
# if defined(__GLIBC__) && defined(_TIME_BITS) && _TIME_BITS == 64
VIR_MOCK_REAL_INIT_ALIASED(stat64, "__stat64_time64");
# else
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
VIR_MOCK_REAL_INIT(stat64);
virmockstathelpers: Load aliases for 64-bit time On 32-bit arches, it's possible not only to request -D_FILE_OFFSET_BITS=64 (which is always done with meson) but also -D_TIME_BITS=64. With glibc, both of these affect what variant of stat() or lstat() is called. With 64 bit time it's: __stat64_time64() or __lstat64_time64(), respectively. Fortunately, no other variant (__xstat(), __xstat64()) has _time64 alternative and thus does not need similar treatment. Similarly, musl is not affected by this. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/404 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-18 16:13:22 +00:00
# endif
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
fdebug("real stat64 %p\n", real_stat64);
#endif
#ifdef MOCK___XSTAT
VIR_MOCK_REAL_INIT(__xstat);
fdebug("real __xstat %p\n", real___xstat);
#endif
#ifdef MOCK___XSTAT64
VIR_MOCK_REAL_INIT(__xstat64);
fdebug("real __xstat64 %p\n", real___xstat64);
#endif
#ifdef MOCK_LSTAT
tests: Only mock $INODE64 symbols on x86_64 macOS The version of macOS running on Apple Silicon doesn't need to concern itself with backwards compatibility with 32-bit applications, and so it could jettison all the symbol aliasing shenanigans involved. https://gitlab.com/libvirt/libvirt/-/issues/121 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com> Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
2021-02-04 14:48:18 +00:00
# if defined(__APPLE__) && defined(__x86_64__)
tests: Fix lstat() mock initialization on macOS There is a typo that prevents initialization of real_lstat. Fixes: d6b17edd5163 ("tests: Lookup extended stat/lstat in mocks") Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-18 15:30:56 +00:00
VIR_MOCK_REAL_INIT_ALIASED(lstat, "lstat$INODE64");
tests: Lookup extended stat/lstat in mocks macOS syscall interface (/usr/lib/system/libsystem_kernel.dylib) has three kinds of stat but only one of them can be used to fill "struct stat": stat$INODE64. virmockstathelpers looks up regular stat instead of stat$INODE64. That causes a failure in qemufirmwaretest because "struct stat" is laid out differently from the values returned by stat. Introduce VIR_MOCK_REAL_INIT_ALIASED that can be used to lookup stat$INODE64 and lstat$INODE64 and use it to setup real functions on macOS. Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
2019-08-21 16:13:20 +00:00
# else
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
VIR_MOCK_REAL_INIT(lstat);
tests: Lookup extended stat/lstat in mocks macOS syscall interface (/usr/lib/system/libsystem_kernel.dylib) has three kinds of stat but only one of them can be used to fill "struct stat": stat$INODE64. virmockstathelpers looks up regular stat instead of stat$INODE64. That causes a failure in qemufirmwaretest because "struct stat" is laid out differently from the values returned by stat. Introduce VIR_MOCK_REAL_INIT_ALIASED that can be used to lookup stat$INODE64 and lstat$INODE64 and use it to setup real functions on macOS. Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
2019-08-21 16:13:20 +00:00
# endif
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
fdebug("real lstat %p\n", real_lstat);
#endif
#ifdef MOCK_LSTAT64
virmockstathelpers: Load aliases for 64-bit time On 32-bit arches, it's possible not only to request -D_FILE_OFFSET_BITS=64 (which is always done with meson) but also -D_TIME_BITS=64. With glibc, both of these affect what variant of stat() or lstat() is called. With 64 bit time it's: __stat64_time64() or __lstat64_time64(), respectively. Fortunately, no other variant (__xstat(), __xstat64()) has _time64 alternative and thus does not need similar treatment. Similarly, musl is not affected by this. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/404 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-18 16:13:22 +00:00
# if defined(__GLIBC__) && defined(_TIME_BITS) && _TIME_BITS == 64
VIR_MOCK_REAL_INIT_ALIASED(lstat64, "__lstat64_time64");
# else
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
VIR_MOCK_REAL_INIT(lstat64);
virmockstathelpers: Load aliases for 64-bit time On 32-bit arches, it's possible not only to request -D_FILE_OFFSET_BITS=64 (which is always done with meson) but also -D_TIME_BITS=64. With glibc, both of these affect what variant of stat() or lstat() is called. With 64 bit time it's: __stat64_time64() or __lstat64_time64(), respectively. Fortunately, no other variant (__xstat(), __xstat64()) has _time64 alternative and thus does not need similar treatment. Similarly, musl is not affected by this. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/404 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-18 16:13:22 +00:00
# endif
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
fdebug("real lstat64 %p\n", real_lstat64);
#endif
#ifdef MOCK___LXSTAT
VIR_MOCK_REAL_INIT(__lxstat);
fdebug("real __lxstat %p\n", real___lxstat);
#endif
#ifdef MOCK___LXSTAT64
VIR_MOCK_REAL_INIT(__lxstat64);
fdebug("real __lxstat64 %p\n", real___lxstat64);
#endif
}
/*
* @stat: the path being queried
* @newpath: fill with redirected path, or leave NULL to use orig path
*
* Return 0 on success, -1 on allocation error
*/
static int virMockStatRedirect(const char *path, char **newpath);
#ifndef VIR_MOCK_STAT_HOOK
# define VIR_MOCK_STAT_HOOK do { } while (0)
#endif
#ifdef MOCK_STAT
int stat(const char *path, struct stat *sb)
{
Use g_autofree instead of VIR_AUTOFREE Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros directly instead of our custom aliases. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 13:16:31 +00:00
g_autofree char *newpath = NULL;
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
virMockStatInit();
if (virMockStatRedirect(path, &newpath) < 0)
abort();
fdebug("stat redirect %s to %s sb=%p\n", path, newpath ? newpath : path, sb);
VIR_MOCK_STAT_HOOK;
return real_stat(newpath ? newpath : path, sb);
}
#endif
#ifdef MOCK_STAT64
int stat64(const char *path, struct stat64 *sb)
{
Use g_autofree instead of VIR_AUTOFREE Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros directly instead of our custom aliases. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 13:16:31 +00:00
g_autofree char *newpath = NULL;
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
virMockStatInit();
if (virMockStatRedirect(path, &newpath) < 0)
abort();
fdebug("stat64 redirect %s to %s sb=%p\n", path, newpath ? newpath : path, sb);
VIR_MOCK_STAT_HOOK;
return real_stat64(newpath ? newpath : path, sb);
}
#endif
#ifdef MOCK___XSTAT
int
__xstat(int ver, const char *path, struct stat *sb)
{
Use g_autofree instead of VIR_AUTOFREE Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros directly instead of our custom aliases. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 13:16:31 +00:00
g_autofree char *newpath = NULL;
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
virMockStatInit();
if (virMockStatRedirect(path, &newpath) < 0)
abort();
fdebug("__xstat redirect %s to %s sb=%p\n", path, newpath ? newpath : path, sb);
VIR_MOCK_STAT_HOOK;
return real___xstat(ver, newpath ? newpath : path, sb);
}
#endif
#ifdef MOCK___XSTAT64
int
__xstat64(int ver, const char *path, struct stat64 *sb)
{
Use g_autofree instead of VIR_AUTOFREE Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros directly instead of our custom aliases. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 13:16:31 +00:00
g_autofree char *newpath = NULL;
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
virMockStatInit();
if (virMockStatRedirect(path, &newpath) < 0)
abort();
fdebug("__xstat64 redirect %s to %s sb=%p\n", path, newpath ? newpath : path, sb);
VIR_MOCK_STAT_HOOK;
return real___xstat64(ver, newpath ? newpath : path, sb);
}
#endif
#ifdef MOCK_LSTAT
int
lstat(const char *path, struct stat *sb)
{
Use g_autofree instead of VIR_AUTOFREE Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros directly instead of our custom aliases. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 13:16:31 +00:00
g_autofree char *newpath = NULL;
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
virMockStatInit();
if (virMockStatRedirect(path, &newpath) < 0)
abort();
fdebug("lstat redirect %s to %s sb=%p\n", path, newpath ? newpath : path, sb);
VIR_MOCK_STAT_HOOK;
return real_lstat(newpath ? newpath : path, sb);
}
#endif
#ifdef MOCK_LSTAT64
int
lstat64(const char *path, struct stat64 *sb)
{
Use g_autofree instead of VIR_AUTOFREE Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros directly instead of our custom aliases. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 13:16:31 +00:00
g_autofree char *newpath = NULL;
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
virMockStatInit();
if (virMockStatRedirect(path, &newpath) < 0)
abort();
fdebug("lstat64 redirect %s to %s sb=%p\n", path, newpath ? newpath : path, sb);
VIR_MOCK_STAT_HOOK;
return real_lstat64(newpath ? newpath : path, sb);
}
#endif
#ifdef MOCK___LXSTAT
int
__lxstat(int ver, const char *path, struct stat *sb)
{
Use g_autofree instead of VIR_AUTOFREE Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros directly instead of our custom aliases. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 13:16:31 +00:00
g_autofree char *newpath = NULL;
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
virMockStatInit();
if (virMockStatRedirect(path, &newpath) < 0)
abort();
fdebug("__lxstat redirect %s to %s sb=%p\n", path, newpath ? newpath : path, sb);
VIR_MOCK_STAT_HOOK;
return real___lxstat(ver, newpath ? newpath : path, sb);
}
#endif
#ifdef MOCK___LXSTAT64
int
__lxstat64(int ver, const char *path, struct stat64 *sb)
{
Use g_autofree instead of VIR_AUTOFREE Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros directly instead of our custom aliases. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 13:16:31 +00:00
g_autofree char *newpath = NULL;
tests: fix mocking of stat() / lstat() functions Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-01 16:47:25 +00:00
virMockStatInit();
if (virMockStatRedirect(path, &newpath) < 0)
abort();
fdebug("__lxstat64 redirect %s to %s sb=%p\n", path, newpath ? newpath : path, sb);
VIR_MOCK_STAT_HOOK;
return real___lxstat64(ver, newpath ? newpath : path, sb);
}
#endif
Reference in New Issue Copy Permalink