Magnus Holmgren <> 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

  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?


Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

Reply via email to