Magnus Holmgren <[email protected]> writes: > The problem rather seems to be the missing #include "lsh_string.h". Implicit > declarations probably are extra bad with -fPIE.
Thanks! 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 call lsh_get_cstring mov %eax, %edx ;; pass 32-bit return value as argument for next call ... setup other args for the call ... call request_init 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? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.
