Am Mittwoch, November 28, 2018 13:42 CET, David Chisnall <gnus...@theravensnest.org> schrieb:
> On 28/11/2018 11:35, Sebastian Reitenbach wrote: > > (gdb) info break > > Num Type Disp Enb Address What > > 1 breakpoint keep y 0x0000093f1dcad9a2 in > > initialize_gnustep_backend at NSApplication.m:309 > > breakpoint already hit 1 time > > 2 breakpoint keep y 0x0000093ec291a170 in -[NSBundle load] at > > NSBundle.m:1989 > > 3 breakpoint keep y 0x0000093ec2b2a750 in __objc_dynamic_link > > at ././dynamic-load.h:63 > > 5 breakpoint keep y 0x0000093e64843ae0 in __objc_exec_class at > > /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/libobjc2-1.9.0/loader.c:46 > > (gdb) c > > Continuing. > > > > Breakpoint 2, -[NSBundle load] (self=0x93e9baac588, _cmd=0x93e69deea88) at > > NSBundle.m:1989 > > 1989 - (BOOL) load > > (gdb) > > Continuing. > > > > Breakpoint 3, __objc_dynamic_link (module=0x93f0c45f248 "8\212\273\302>\t", > > mode=2366, debug_file=0x93f3d9fa8e0 <__sF+304> "") at ././dynamic-load.h:64 > > warning: Source file is more recent than executable. > > 64 { > > (gdb) > > Continuing. > > > > Program received signal SIGFPE, Arithmetic exception. > > 0x0000093e70b4124c in _dl_find_symbol_obj (obj=0x93ecb3bbc00, > > sl=0x7f7ffffd33f8) at /usr/src/libexec/ld.so/resolve.c:584 > > 584 for (si = obj->buckets[sl->sl_elf_hash % obj->nbuckets]; > > > > So I stopped at NSApplication.m:309, and then added the breakpoints in > > dynamic-load.h and in libobjc loader.c where the __objc_exec_class resides, > > and then continued to execute, but it doesn't hit the breakpoint 5 before > > throwing the FPE. > > > Okay, it looks as if libraries that are linked with lld are not getting > their global constructors called on OpenBSD. Can you try this test? > > =$ cat lib.c > #include <stdio.h> > > __attribute__((constructor)) > void load(void) > { > puts("Library loaded"); > } > [theraven@FBSDVM /tmp]$ cat loadlib.c > #include <dlfcn.h> > #include <stdio.h> > > int main(void) > { > puts("Program started"); > dlopen("./lib.so", RTLD_LAZY | RTLD_GLOBAL); > return 0; > } > $ clang60 lib.c -shared -o lib.so -fPIC -fuse-ld=lld > $ clang loadlib.c > $ ./a.out > Program started > Library loaded > > > If it prints both of the lines above, the library was correctly loaded > and the global constructors were run. If it works with -fuse-ld=lld but > not -fuse-ld=bfd, then that tells us that this really is the problem. > Objdump of the bfd and lld versions of lib.so should help us identify > the differences. > > David sebastia@communicator:~> vi lib.c sebastia@communicator:~> vi loadlib.c sebastia@communicator:~> clang lib.c -shared -o lib.so -fPIC -fuse-ld=lld sebastia@communicator:~> clang loadlib.c sebastia@communicator:~> ./a.out Program started Library loaded sebastia@communicator:~> rm lib.so a.out sebastia@communicator:~> clang lib.c -shared -o lib.so -fPIC -fuse-ld=bfd sebastia@communicator:~> clang loadlib.c sebastia@communicator:~> ./a.out Program started Library loaded sebastia@communicator:~> since both work, don't know how helpful the objdump will be. I ran objdump -x on both, find it attached. Sebastian
objdump_bfd
Description: Binary data
objdump_lld
Description: Binary data
_______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep