3 ms·

I just tried to make this work and couldn't. I might be missing something? gcc 7.5, Ubuntu 18.04, x86_64. The third-from-bottom line is two libraries showing th

I just tried to make this work and couldn't. I might be missing something? gcc 7.5, Ubuntu 18.04, x86_64. The third-from-bottom line is two libraries showing the same address. $ cat *.h *.c // common.h #include <stdio.h> typedef int (*printf_ptr)(const char * restrict format, ...); printf_ptr firstA(); printf_ptr firstB(); printf_ptr secondA(); printf_ptr secondB(); // first.c #include "common.h" printf_ptr firstA() { return &printf; } printf_ptr firstB() { return &printf; } // second.c #include "common.h" printf_ptr secondA() { return &printf; } printf_ptr secondB() { return &printf; } // third.c #include "common.h" int main() { printf("%p %p %p %p\n", firstA(), firstB(), secondA(), secondB()); firstA()("hello world %d\n", 1); secondA()("hello world %d\n", 2); return 0; } $ make gcc -fPIC -c *.c gcc -shared -o first.so first.o -lc gcc -shared -o second.so second.o -lc gcc -o atprintf third.o ./first.so ./second.so ./atprintf 0x7f6d24e08f70 0x7f6d24e08f70 0x7f6d24e08f70 0x7f6d24e08f70 hello world 1 hello world 2

KMag 5y ago
Ahh... I was wrong! There's one detail I wasn't aware of: if you take the address of a dynamic function, it appears to disable ELF lazy dynamic symbol binding for that function, so that it's guaranteed the GOT entry has been resolved to the global function address before main() is entered. It then just unconditionally uses the GOT entry as the function address. If we print the address of main and never take the address of printf, we get lazy symbol resolution for printf like I expected: #include <stdio.h> int main() { printf("main is at %p\n", main); return 0; } objdump --section .plt -d a.out shows 2 PLT entries: 0000000000001020 <.plt>: 1020: ff 35 e2 2f 00 00 pushq 0x2fe2(%rip) # 4008 <_GLOBAL_OFFSET_TABLE_+0x8> 1026: ff 25 e4 2f 00 00 jmpq *0x2fe4(%rip) # 4010 <_GLOBAL_OFFSET_TABLE_+0x10> 102c: 0f 1f 40 00 nopl 0x0(%rax) 0000000000001030 <printf@plt>: 1030: ff 25 e2 2f 00 00 jmpq *0x2fe2(%rip) # 4018 <printf@GLIBC_2.2.5> 1036: 68 00 00 00 00 pushq $0x0 103b: e9 e0 ff ff ff jmpq 1020 <.plt> That jmpq *0x2fe2(%rip) in the second PLT entry is an indirect jump through the prnitf GOT entry. The printf GOT entry is actually initialized to point right back at the pushq $0x0 inside pritf@plt. That pushes 0 on the stack so the dynamic symbol resolution knows which GOT entry it's lazily resolving. The jmpq 1020 <.plt> jumps to the first PLT entry, which then uses the 0 at the top of the stack to know it's resolving the printf GOT entry. But, if we ever actually take the address of printf, then printf ceases to be a lazily bound ELF symbol: #include <stdio.h> int main() { printf("printf is at %p\n", printf); return 0; } Note that we lose the dynamic resolution PLT stub for printf (objdump --section .plt -d a.out): 0000000000001020 <.plt>: 1020: ff 35 e2 2f 00 00 pushq 0x2fe2(%rip) # 4008 <_GLOBAL_OFFSET_TABLE_+0x8> 1026: ff 25 e4 2f 00 00 jmpq *0x2fe4(%rip) # 4010 <_GLOBAL_OFFSET_TABLE_+0x10> 102c: 0f 1f 40 00 nopl 0x0(%rax) And gcc -O2 -S main.c shows it's just unconditionally loading the GOT entry (printf@GOTPCREL) to use as the function address. (Note the dissasembly shows printf@PLT, but objdump doesn't show this PLT entry. I guess the linker does some link-time optimization there to remove the actual PLT entry.) main: .LFB11: .cfi_startproc subq $8, %rsp .cfi_def_cfa_offset 16 movq printf@GOTPCREL(%rip), %rsi leaq .LC0(%rip), %rdi xorl %eax, %eax call printf@PLT https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSeries/x2251.html https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSe... (section named Function Addresses) mentions that things (at least for IBM zSeries) basically work as I originally expected, but further vaguely mentions some special steps are taken to make function addresses compare as expected. It doesn't specifically mention disabling ELF dynamic symbol resolution.*
- andrewf 5y ago
  Thanks for the detail! I did manage to see different values for &printf with DLLs on Windows. I was inspired by a long-ago port of a codebase to a newer Visual C++; the third-party binary DLLs kept importing the old C runtime and using its malloc/free, which complicated things. I put a __declspec(dllexport) on everything in my header file then (abridged): C:\Users\andrew\Desktop\winlink>cl /LD first.c Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27035 for x64 Copyright (C) Microsoft Corporation. All rights reserved. /out:first.dll /dll /implib:first.lib first.obj Creating library first.lib and object first.exp C:\Users\andrew\Desktop\winlink>cl /LD second.c C:\Users\andrew\Desktop\winlink>cl third.c first.lib second.lib C:\Users\andrew\Desktop\winlink>third.exe 00007FFE38411080 00007FFE38411080 00007FFE382F1080 00007FFE382F1080 hello world 1 hello world 2 If I statically link the three modules together on Windows, then I don't see the different pointers.

KMag 5y ago

Ahh... I was wrong! There's one detail I wasn't aware of: if you take the address of a dynamic function, it appears to disable ELF lazy dynamic symbol binding for that function, so that it's guaranteed the GOT entry has been resolved to the global function address before main() is entered. It then just unconditionally uses the GOT entry as the function address. If we print the address of main and never take the address of printf, we get lazy symbol resolution for printf like I expected: #include <stdio.h> int main() { printf("main is at %p\n", main); return 0; } objdump --section .plt -d a.out shows 2 PLT entries: 0000000000001020 <.plt>: 1020: ff 35 e2 2f 00 00 pushq 0x2fe2(%rip) # 4008 <_GLOBAL_OFFSET_TABLE_+0x8> 1026: ff 25 e4 2f 00 00 jmpq *0x2fe4(%rip) # 4010 <_GLOBAL_OFFSET_TABLE_+0x10> 102c: 0f 1f 40 00 nopl 0x0(%rax) 0000000000001030 <printf@plt>: 1030: ff 25 e2 2f 00 00 jmpq *0x2fe2(%rip) # 4018 <printf@GLIBC_2.2.5> 1036: 68 00 00 00 00 pushq $0x0 103b: e9 e0 ff ff ff jmpq 1020 <.plt> That jmpq *0x2fe2(%rip) in the second PLT entry is an indirect jump through the prnitf GOT entry. The printf GOT entry is actually initialized to point right back at the pushq $0x0 inside pritf@plt. That pushes 0 on the stack so the dynamic symbol resolution knows which GOT entry it's lazily resolving. The jmpq 1020 <.plt> jumps to the first PLT entry, which then uses the 0 at the top of the stack to know it's resolving the printf GOT entry. But, if we ever actually take the address of printf, then printf ceases to be a lazily bound ELF symbol: #include <stdio.h> int main() { printf("printf is at %p\n", printf); return 0; } Note that we lose the dynamic resolution PLT stub for printf (objdump --section .plt -d a.out): 0000000000001020 <.plt>: 1020: ff 35 e2 2f 00 00 pushq 0x2fe2(%rip) # 4008 <_GLOBAL_OFFSET_TABLE_+0x8> 1026: ff 25 e4 2f 00 00 jmpq *0x2fe4(%rip) # 4010 <_GLOBAL_OFFSET_TABLE_+0x10> 102c: 0f 1f 40 00 nopl 0x0(%rax) And gcc -O2 -S main.c shows it's just unconditionally loading the GOT entry (printf@GOTPCREL) to use as the function address. (Note the dissasembly shows printf@PLT, but objdump doesn't show this PLT entry. I guess the linker does some link-time optimization there to remove the actual PLT entry.) main: .LFB11: .cfi_startproc subq $8, %rsp .cfi_def_cfa_offset 16 movq printf@GOTPCREL(%rip), %rsi leaq .LC0(%rip), %rdi xorl %eax, %eax call printf@PLT https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSeries/x2251.html https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSe... (section named Function Addresses) mentions that things (at least for IBM zSeries) basically work as I originally expected, but further vaguely mentions some special steps are taken to make function addresses compare as expected. It doesn't specifically mention disabling ELF dynamic symbol resolution.*

andrewf 5y ago
Thanks for the detail! I did manage to see different values for &printf with DLLs on Windows. I was inspired by a long-ago port of a codebase to a newer Visual C++; the third-party binary DLLs kept importing the old C runtime and using its malloc/free, which complicated things. I put a __declspec(dllexport) on everything in my header file then (abridged): C:\Users\andrew\Desktop\winlink>cl /LD first.c Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27035 for x64 Copyright (C) Microsoft Corporation. All rights reserved. /out:first.dll /dll /implib:first.lib first.obj Creating library first.lib and object first.exp C:\Users\andrew\Desktop\winlink>cl /LD second.c C:\Users\andrew\Desktop\winlink>cl third.c first.lib second.lib C:\Users\andrew\Desktop\winlink>third.exe 00007FFE38411080 00007FFE38411080 00007FFE382F1080 00007FFE382F1080 hello world 1 hello world 2 If I statically link the three modules together on Windows, then I don't see the different pointers.