Re: loading bundles stopped working

[Sebastian Reitenbach]

Am Mittwoch, November 28, 2018 13:42 CET, David Chisnall 
<gnustep@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