efl/src/lib/evil/evil_mman.h

167 lines
3.8 KiB
C
Raw Normal View History

2008-03-01 23:03:37 -08:00
#ifndef __EVIL_SYS_MMAN_H__
#define __EVIL_SYS_MMAN_H__
#include <sys/types.h>
/**
* @def PROT_NONE
* Data can not be accessed.
*/
/**
* @def PROT_READ
* Data can be read.
*/
/**
* @def PROT_WRITE
* Data can be written.
*/
/**
* @def PROT_EXEC
* Data can be executed.
*/
#define PROT_NONE 0x00
#define PROT_READ 0x01
#define PROT_WRITE 0x02
#define PROT_EXEC 0x04
/**
* @def MAP_SHARED
* Changes are shared.
*/
/**
* @def MAP_PRIVATE
* Changes are private.
*/
/**
* @def MAP_FIXED
* Interpret the address (addr) exactly.
*/
/**
* @def MAP_FAILED
* Error return from mmap().
*/
#define MAP_SHARED 0x0001
#define MAP_PRIVATE 0x0002
#define MAP_FIXED 0x0010
#define MAP_ANON 0x0020
#define MAP_ANONYMOUS MAP_ANON
#define MAP_FAILED ((void *)-1)
/**
2020-03-05 00:35:05 -08:00
* @file evil_mman.h
* @brief The file that provides the memory map functions
* @defgroup Evil_Mman Functions that manage memory mappping.
* @ingroup Evil
*
* This header provides the meomry map functions mmap and munmap.
*
*/
/**
* Creates or opens a named or unnamed file mapping object for a
* specified file and maps a view of a file mapping into the
* address space of a calling process.
*
* @param addr Unused
* @param len Number of bytes to be mapped.
* @param prot Protections.
* @param flags Type of the mapped object.
* @param fd File descriptor that describes the object to map.
* @param offset Number of bytes from which to start the mapping.
* @return The starting address of the mapped view on success, -1 otherwise.
*
* Create or open an unnamed file mapping object for a specified
* file described by the file descriptor @p fd. The number of
* bytes that are mapped is given by @p len and start after
* @p offset bytes. The parameter @p addr is unused.
*
* The only type of the mapped object that is supported is
* @c MAP_SHARED. If another value if given, -1 is returned.
*
* @p prot specifies the protection of the mapped region. If
* PROT_EXEC is used, it set the execute access. If PROT_READ
* is used, it sets the read access. If PROT_WRITE is used, it
* sets the write access.
*
* If the map view of file can not be created, -1 is returned.
* If the mappping can not be done, -1 is returned.
*
* If no error occurred, the starting address of the mapped view
* is returned.
*
* Conformity: None.
*
* Supported OS: Windows Vista, Windows XP or Windows 2000
* Professional.
*
* @ingroup Evil_Mman
*/
evil: Rename EAPI macro to EVIL_API in Evil library Summary: Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). ``` Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))``` However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: raster, vtorri, jptiz, lucas, woohyun Reviewed By: vtorri, jptiz Subscribers: ProhtMeyhet, cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12182
2020-11-12 08:47:38 -08:00
EVIL_API void *mmap(void *addr,
size_t len,
int prot,
int flags,
int fd,
off_t offset);
#ifndef HAVE_MMAP
# define HAVE_MMAP 1
#endif
/**
* Unmaps a mapped view of a file from the calling process's
* address space.
*
* @param addr Pointer to the base address.
* @param len Unused.
* @return 0 on success, -1 otherwise.
*
* Unmaps a mapped view of a file from the calling process's
* address space. @p addr is the pointer to the base address.
* This value must be identical to the value returned by a
* previous call to mmap(). The parameter @p len is unused.
*
* Conformity: None.
*
* Supported OS: Windows Vista, Windows XP or Windows 2000
* Professional.
*
* @ingroup Evil_Mman
*/
evil: Rename EAPI macro to EVIL_API in Evil library Summary: Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). ``` Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))``` However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: raster, vtorri, jptiz, lucas, woohyun Reviewed By: vtorri, jptiz Subscribers: ProhtMeyhet, cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12182
2020-11-12 08:47:38 -08:00
EVIL_API int munmap(void *addr,
size_t len);
/**
* Changes protection for the calling process' address.
*
* @param addr Pointer to the base address.
* @param len Length of the memory.
* @param prot New protection.
* @return 0 on success, -1 otherwise.
*
* Changes protection for the calling process' memory page.
* @p addr must be a valid adress in the user space. @p prot
* must be compatible with the old protection.
*
* Conformity: None.
*
* Supported OS: Windows Vista
*
* @ingroup Evil_Mman
*/
evil: Rename EAPI macro to EVIL_API in Evil library Summary: Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). ``` Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))``` However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: raster, vtorri, jptiz, lucas, woohyun Reviewed By: vtorri, jptiz Subscribers: ProhtMeyhet, cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12182
2020-11-12 08:47:38 -08:00
EVIL_API int mprotect(void *addr, size_t len, int prot);
2008-03-01 23:03:37 -08:00
#endif /* __EVIL_SYS_MMAN_H__ */