Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
Dmitry Baryshkov
nettle
Commits
29d6dacf
Commit
29d6dacf
authored
Jan 13, 2015
by
Niels Möller
Browse files
Make constructor hack less gcc-specific.
parent
aa7ad293
Changes
2
Hide whitespace changes
Inline
Side-by-side
ChangeLog
View file @
29d6dacf
2015-01-13 Niels Möller <nisse@lysator.liu.se>
* x86_64/fat/fat.c: For constructor hack, check
HAVE_GCC_ATTRIBUTE, not __GNUC__. Also support sun compilers, as
suggested by Nikos Mavrogiannopoulos, and attch the constructor
attribute directly to fat_init.
(fat_constructor): Deleted wrapper function.
* x86_64/fat/fat.c: New file, initialization for x86_64 fat
library.
...
...
x86_64/fat/fat.c
View file @
29d6dacf
...
...
@@ -53,22 +53,21 @@
To get everything hooked in, we use a belt-and-suspenders approach.
When compiling with gcc, we try to register a constructor function
which calls fat_init as soon as the library is loaded. If this is
unavailable or non-working, we instead arrange fat_init to be
called on demand.
We try to register fat_init as a constructor function to be called
at load time. If this is unavailable or non-working, we instead
arrange fat_init to be called lazily.
For the actual indirection, there are two cases.
If ifunc support is available, function pointers are statically
initialized to NULL, and we register resolver functions, e.g.,
_aes_encrypt_resolve, which call
s
fat_init, and then return
s
the
_aes_encrypt_resolve, which call fat_init, and then return the
function pointer, e.g., the value of _aes_encrypt_vec.
If ifunc is not available, we have to define a wrapper function to
jump via the function pointer. (FIXME: For internal calls, we could
do this as a macro
instead
). We statically initialize each function
pointer
to point to a special initialization function, e.g.,
do this as a macro). We statically initialize each function
pointer
to point to a special initialization function, e.g.,
_aes_encrypt_init, which calls fat_init, and then invokes the right
function. This way, all pointers are setup correctly at the first
call to any fat function.
...
...
@@ -80,6 +79,13 @@
# define IFUNC(resolve)
#endif
#if HAVE_GCC_ATTRIBUTE
# define CONSTRUCTOR __attribute__ ((constructor))
#elif defined (__sun)
# pragma init(fat_init)
# define CONSTRUCTOR
#endif
void
_nettle_cpuid
(
uint32_t
input
,
uint32_t
regs
[
4
]);
typedef
void
void_func
(
void
);
...
...
@@ -111,7 +117,7 @@ static aes_crypt_internal_func *_aes_decrypt_vec = _aes_decrypt_init;
it is idempotent, and on x86, pointer updates are atomic, so
there's no danger if it is called simultaneously from multiple
threads. */
static
void
static
void
CONSTRUCTOR
fat_init
(
void
)
{
static
volatile
int
initialized
=
0
;
...
...
@@ -151,14 +157,6 @@ fat_init (void)
initialized
=
1
;
}
#if __GNUC__
static
void
__attribute__
((
constructor
))
fat_constructor
(
void
)
{
fat_init
();
}
#endif
#if HAVE_LINK_IFUNC
static
void_func
*
...
...
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment