Magnus Holmgren <holmg...@debian.org> writes:
> The problem rather seems to be the missing #include "lsh_string.h". Implicit
> declarations probably are extra bad with -fPIE.
I just tried compiling after ./configure --with-tcpwrappers. Which
results in an warning on lsh_get_cstring being undeclared. It compiles
without warnings after adding that missing include. (Apparently no
warnings about the incorrect UNUSED...).
Let me see if I can understand the way it fails (the fix, adding the
missing include, is the same either way, of course).
lsh_get_cstring returns a pointer, while an implicitly declared function
will be assumed to return int. And on x86_64, int is of a smaller size
than a pointer, so it's a very real difference. And the compiler is free
to ignore the high part, so it compiles it to something like
mov %eax, %edx ;; pass 32-bit return value as argument for next call
... setup other args for the call ...
while with a correct declaration, it must generate
mov %rax, %rdx ;; copy all 64 bits
The 32-bit mov above doesn't leave the high half of %rdx unchanged,
instead, it is always cleared. Which means that the above code will work
nonetheless in case all pointers occuring at runtime happen to have the
high 32-bits all zeros. In this case, memory for strings are always
allocated using malloc.
So my guess is that traditionally, malloc returns small addresses if
possible, while -fPIE implies that memory returned by malloc is mapped
at randomized locations where the high 32 bits are almost never zero?
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.