Loading shared objects in an l4env_freebsd application
Hi again, I need to load shared objects in my application. I've got .so loading working in a loader-mode app, but my app uses the l4env_freebsd mode so I cannot link against libloader.s.so. I've tried to link against libloaderif.a, but the l4loader_attach_relocateable() function is only available in libloader.s.so. Any help would be appreciated, Derick
On Thursday 09 June 2005 14:06, Derick Swanepoel wrote:
I need to load shared objects in my application. I've got .so loading working in a loader-mode app, but my app uses the l4env_freebsd mode so I cannot link against libloader.s.so. I've tried to link against libloaderif.a, but the l4loader_attach_relocateable() function is only available in libloader.s.so.
I do not fully understand your problem. Why do you cannot link against the libloaders.s.so when you are using l4env_freebsd_mode? And what do you mean by "need to load shared objects". Do you need dlopen() functionality or do you want to link against other shared libraries? Frank -- ## Dept. of Computer Science, Dresden University of Technology, Germany ## ## http://os.inf.tu-dresden.de/~fm3 ##
On 6/9/05, Frank Mehnert <fm3@os.inf.tu-dresden.de> wrote:
On Thursday 09 June 2005 14:06, Derick Swanepoel wrote:
I need to load shared objects in my application. I've got .so loading working in a loader-mode app, but my app uses the l4env_freebsd mode so I cannot link against libloader.s.so. I've tried to link against libloaderif.a, but the l4loader_attach_relocateable() function is only available in libloader.s.so.
I do not fully understand your problem. Why do you cannot link against the libloaders.s.so when you are using l4env_freebsd_mode?
The example loader applications use the loader mode, which links the application dynamically, and it links against libloader.s.so (it uses -lloader.s as a linker argument). When using the l4env_freebsd mode the application is linked statically so it wants to link against libloader.s.a (which doesn't exist) when using -lloader.s. I see that there is a static loader library (libloaderif.a), but it doesn't contain the l4loader_attach_relocateable() function which I need.
And what do you mean by "need to load shared objects". Do you need dlopen() functionality or do you want to link against other shared libraries?
I need dlopen() functionality. I already have a dlopen() implementation that makes use of the L4 loader API. Derick
On Thursday 09 June 2005 14:45, Derick Swanepoel wrote:
On 6/9/05, Frank Mehnert <fm3@os.inf.tu-dresden.de> wrote:
On Thursday 09 June 2005 14:06, Derick Swanepoel wrote:
I need to load shared objects in my application. I've got .so loading working in a loader-mode app, but my app uses the l4env_freebsd mode so I cannot link against libloader.s.so. I've tried to link against libloaderif.a, but the l4loader_attach_relocateable() function is only available in libloader.s.so.
I do not fully understand your problem. Why do you cannot link against the libloaders.s.so when you are using l4env_freebsd_mode?
The example loader applications use the loader mode, which links the application dynamically, and it links against libloader.s.so (it uses -lloader.s as a linker argument). When using the l4env_freebsd mode the application is linked statically so it wants to link against libloader.s.a (which doesn't exist) when using -lloader.s. I see that there is a static loader library (libloaderif.a), but it doesn't contain the l4loader_attach_relocateable() function which I need.
If you need the libraries of the l4env_freebsd_mode, it should be possible to add these libraries using the LIBS= parameter. If you look at the appropriate Makefile you will see, that libloaderif.a contains only the client stub of the loader IDL and therefore has nothing to do with the shared library stuff. The point is that you should start from the loader mode and enhance this mode for your needs since the loader mode uses a different startup strategy than the sigma0 mode. Frank -- ## Dept. of Computer Science, Dresden University of Technology, Germany ## ## http://os.inf.tu-dresden.de/~fm3 ##
On 6/9/05, Frank Mehnert <fm3@os.inf.tu-dresden.de> wrote:
On Thursday 09 June 2005 14:45, Derick Swanepoel wrote:
On 6/9/05, Frank Mehnert <fm3@os.inf.tu-dresden.de> wrote:
On Thursday 09 June 2005 14:06, Derick Swanepoel wrote:
I need to load shared objects in my application. I've got .so loading working in a loader-mode app, but my app uses the l4env_freebsd mode so I cannot link against libloader.s.so. I've tried to link against libloaderif.a, but the l4loader_attach_relocateable() function is only available in libloader.s.so.
I do not fully understand your problem. Why do you cannot link against the libloaders.s.so when you are using l4env_freebsd_mode?
The example loader applications use the loader mode, which links the application dynamically, and it links against libloader.s.so (it uses -lloader.s as a linker argument). When using the l4env_freebsd mode the application is linked statically so it wants to link against libloader.s.a (which doesn't exist) when using -lloader.s. I see that there is a static loader library (libloaderif.a), but it doesn't contain the l4loader_attach_relocateable() function which I need.
If you need the libraries of the l4env_freebsd_mode, it should be possible to add these libraries using the LIBS= parameter. If you look at the appropriate Makefile you will see, that libloaderif.a contains only the client stub of the loader IDL and therefore has nothing to do with the shared library stuff.
The point is that you should start from the loader mode and enhance this mode for your needs since the loader mode uses a different startup strategy than the sigma0 mode.
Thanks for the advice. I have created a new mode to combine the loader mode with what I need from l4env_freebsd, and I can successfully compile and link my application. Unfortunately it causes a double pagefault when loaded...: loader | "(nd)/fiasco/ds/test" is a valid binary image loader | Setting libpath to (nd)/fiasco/ds/ exec | test: Loading exec | test: Saved 457726 bytes of symbols exec | libloader.s.so: Relocating to 0000e000 exec | libloader.s.so: Linking exec | libloader.s.so: Relocating entry 000058d0 => 000138d0 exec | libloader.s.so: Setting section flag 0800 exec | test: Setting section flag 0800 loader | test: Starting l4env-style application loader | test,#11: Starting at l4loader_init (00014080) loader | test,#11: Double PF (r) at 00000000 eip 00000000 (11.00) A backtrace of the thread shows the following: backtrace (thread 11.00, fp=00009af4, pc=00000000): #2 016f4c37 #3 016f4c85 #4 016f4cd3 #5 016f426c #6 016ea0b3 #7 016edf23 #8 016ea3be #9 016ea1e9 #10 00014057 My application is compiled with debug info so I assume this happened in some other library. Sorry, I don't know enough about debugging to provide more detailed information. Thanks again, Derick
On Friday 10 June 2005 10:43, Derick Swanepoel wrote:
On 6/9/05, Frank Mehnert <fm3@os.inf.tu-dresden.de> wrote:
If you need the libraries of the l4env_freebsd_mode, it should be possible to add these libraries using the LIBS= parameter. If you look at the appropriate Makefile you will see, that libloaderif.a contains only the client stub of the loader IDL and therefore has nothing to do with the shared library stuff.
The point is that you should start from the loader mode and enhance this mode for your needs since the loader mode uses a different startup strategy than the sigma0 mode.
Thanks for the advice. I have created a new mode to combine the loader mode with what I need from l4env_freebsd, and I can successfully compile and link my application. Unfortunately it causes a double pagefault when loaded...:
loader | "(nd)/fiasco/ds/test" is a valid binary image loader | Setting libpath to (nd)/fiasco/ds/ exec | test: Loading exec | test: Saved 457726 bytes of symbols exec | libloader.s.so: Relocating to 0000e000 exec | libloader.s.so: Linking exec | libloader.s.so: Relocating entry 000058d0 => 000138d0 exec | libloader.s.so: Setting section flag 0800 exec | test: Setting section flag 0800 loader | test: Starting l4env-style application loader | test,#11: Starting at l4loader_init (00014080) loader | test,#11: Double PF (r) at 00000000 eip 00000000 (11.00)
Ok, this is a pagefault in the loader library. Please look at the file l4/pkg/loader/server/src/app.c and search for APP_ADDR_LIBLOADER. Take that address as the base for libloader.s.so. Subtract that address from the pagefault address. The result is the offset into the loader lib. Do objdump -ld libloader.s.so | less and search for the offset. Then scroll a little bit around and look for lines of source code contained in the listing. Or simply post the listing here. Frank -- ## Dept. of Computer Science, Dresden University of Technology, Germany ## ## http://os.inf.tu-dresden.de/~fm3 ##
On 6/10/05, Frank Mehnert <fm3@os.inf.tu-dresden.de> wrote:
On Friday 10 June 2005 10:43, Derick Swanepoel wrote:
Thanks for the advice. I have created a new mode to combine the loader mode with what I need from l4env_freebsd, and I can successfully compile and link my application. Unfortunately it causes a double pagefault when loaded...:
loader | "(nd)/fiasco/ds/test" is a valid binary image loader | Setting libpath to (nd)/fiasco/ds/ exec | test: Loading exec | test: Saved 457726 bytes of symbols exec | libloader.s.so: Relocating to 0000e000 exec | libloader.s.so: Linking exec | libloader.s.so: Relocating entry 000058d0 => 000138d0 exec | libloader.s.so: Setting section flag 0800 exec | test: Setting section flag 0800 loader | test: Starting l4env-style application loader | test,#11: Starting at l4loader_init (00014080) loader | test,#11: Double PF (r) at 00000000 eip 00000000 (11.00)
Ok, this is a pagefault in the loader library. Please look at the file l4/pkg/loader/server/src/app.c and search for APP_ADDR_LIBLOADER. Take that address as the base for libloader.s.so. Subtract that address from the pagefault address. The result is the offset into the loader lib. Do
objdump -ld libloader.s.so | less
and search for the offset. Then scroll a little bit around and look for lines of source code contained in the listing. Or simply post the listing here.
The value of APP_LIBLOADER in my libloader.s.so is 0x0000E000. The pagefault address is 0x00014057, which makes the offset 0x6057. Here is the function containing that offset (and l4loader_init(), which calls it): 00006020 <__do_l4loader_init>: __do_l4loader_init(): /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:405 6020: 55 push %ebp 6021: 89 e5 mov %esp,%ebp 6023: 56 push %esi 6024: 53 push %ebx 6025: e8 00 00 00 00 call 602a <__do_l4loader_init+0xa> 602a: 5b pop %ebx 602b: 81 c3 8a b7 01 00 add $0x1b78a,%ebx /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:408 6031: 8b b3 80 03 00 00 mov 0x380(%ebx),%esi 6037: 8b 45 08 mov 0x8(%ebp),%eax 603a: 89 06 mov %eax,(%esi) /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:410 603c: e8 6f f9 ff ff call 59b0 <__setup_fixed> /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:413 6041: 8b 83 50 08 00 00 mov 0x850(%ebx),%eax 6047: 52 push %edx 6048: 50 push %eax 6049: 8d 83 6c 08 00 00 lea 0x86c(%ebx),%eax 604f: 50 push %eax 6050: 6a 01 push $0x1 6052: e8 69 f3 ff ff call 53c0 <l4env_get_infopage-0x510> /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:418 6057: e8 b4 fa ff ff call 5b10 <__attach_fixed> /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:419 605c: 58 pop %eax 605d: 8b 06 mov (%esi),%eax 605f: 50 push %eax 6060: e8 7b f7 ff ff call 57e0 <l4env_get_infopage-0xf0> /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:420 6065: e8 26 fe ff ff call 5e90 <__fixup_modules> /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:423 606a: e8 31 ff ff ff call 5fa0 <__complete_load> /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:427 606f: 50 push %eax 6070: c3 ret /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:435 6071: 8d 65 f8 lea 0xfffffff8(%ebp),%esp 6074: 5b pop %ebx 6075: 5e pop %esi 6076: 5d pop %ebp 6077: c3 ret 6078: 90 nop 6079: 8d b4 26 00 00 00 00 lea 0x0(%esi,1),%esi 00006080 <l4loader_init>: l4loader_init(): /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:440 6080: 55 push %ebp 6081: 89 e5 mov %esp,%ebp /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:441 6083: 5d pop %ebp 6084: eb 9a jmp 6020 <__do_l4loader_init> 6086: 8d 76 00 lea 0x0(%esi),%esi 6089: 8d bc 27 00 00 00 00 lea 0x0(%edi,1),%edi Thanks, Derick
On Friday 10 June 2005 12:11, Derick Swanepoel wrote:
On 6/10/05, Frank Mehnert <fm3@os.inf.tu-dresden.de> wrote:
On Friday 10 June 2005 10:43, Derick Swanepoel wrote:
Thanks for the advice. I have created a new mode to combine the loader mode with what I need from l4env_freebsd, and I can successfully compile and link my application. Unfortunately it causes a double pagefault when loaded...:
loader | "(nd)/fiasco/ds/test" is a valid binary image loader | Setting libpath to (nd)/fiasco/ds/ exec | test: Loading exec | test: Saved 457726 bytes of symbols exec | libloader.s.so: Relocating to 0000e000 exec | libloader.s.so: Linking exec | libloader.s.so: Relocating entry 000058d0 => 000138d0 exec | libloader.s.so: Setting section flag 0800 exec | test: Setting section flag 0800 loader | test: Starting l4env-style application loader | test,#11: Starting at l4loader_init (00014080) loader | test,#11: Double PF (r) at 00000000 eip 00000000 (11.00)
Ok, this is a pagefault in the loader library. Please look at the file l4/pkg/loader/server/src/app.c and search for APP_ADDR_LIBLOADER. Take that address as the base for libloader.s.so. Subtract that address from the pagefault address. The result is the offset into the loader lib. Do
objdump -ld libloader.s.so | less
and search for the offset. Then scroll a little bit around and look for lines of source code contained in the listing. Or simply post the listing here.
The value of APP_LIBLOADER in my libloader.s.so is 0x0000E000. The pagefault address is 0x00014057, which makes the offset 0x6057. Here is the function containing that offset (and l4loader_init(), which calls it):
00006020 <__do_l4loader_init>: __do_l4loader_init(): /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:405 6020: 55 push %ebp 6021: 89 e5 mov %esp,%ebp 6023: 56 push %esi 6024: 53 push %ebx 6025: e8 00 00 00 00 call 602a <__do_l4loader_init+0xa> 602a: 5b pop %ebx 602b: 81 c3 8a b7 01 00 add $0x1b78a,%ebx /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:408 6031: 8b b3 80 03 00 00 mov 0x380(%ebx),%esi 6037: 8b 45 08 mov 0x8(%ebp),%eax 603a: 89 06 mov %eax,(%esi) /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:410 603c: e8 6f f9 ff ff call 59b0 <__setup_fixed> /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:413 6041: 8b 83 50 08 00 00 mov 0x850(%ebx),%eax 6047: 52 push %edx 6048: 50 push %eax 6049: 8d 83 6c 08 00 00 lea 0x86c(%ebx),%eax 604f: 50 push %eax 6050: 6a 01 push $0x1 6052: e8 69 f3 ff ff call 53c0 <l4env_get_infopage-0x510> /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:418 6057: e8 b4 fa ff ff call 5b10 <__attach_fixed> /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:419 605c: 58 pop %eax 605d: 8b 06 mov (%esi),%eax 605f: 50 push %eax 6060: e8 7b f7 ff ff call 57e0 <l4env_get_infopage-0xf0> /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:420 6065: e8 26 fe ff ff call 5e90 <__fixup_modules> /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:423 606a: e8 31 ff ff ff call 5fa0 <__complete_load> /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:427 606f: 50 push %eax 6070: c3 ret /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:435 6071: 8d 65 f8 lea 0xfffffff8(%ebp),%esp 6074: 5b pop %ebx 6075: 5e pop %esi 6076: 5d pop %ebp 6077: c3 ret 6078: 90 nop 6079: 8d b4 26 00 00 00 00 lea 0x0(%esi,1),%esi
00006080 <l4loader_init>: l4loader_init(): /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:440 6080: 55 push %ebp 6081: 89 e5 mov %esp,%ebp /home/ljbrits/DROPS/l4/pkg/loader/lib/runtime/main.c:441 6083: 5d pop %ebp 6084: eb 9a jmp 6020 <__do_l4loader_init> 6086: 8d 76 00 lea 0x0(%esi),%esi 6089: 8d bc 27 00 00 00 00 lea 0x0(%edi,1),%edi
The function __attach_fixed() seems to raise the 0-pagefault. I would suggest you to add some printf-statements into the loader/lib/runtime/main.c file. Try first if you can add printf("HERE\n"); at the beginning of the main l4loader_init() function. If that works, instrument __attach_fixed() to find out at which line the 0-PF is generated. Frank -- ## Dept. of Computer Science, Dresden University of Technology, Germany ## ## http://os.inf.tu-dresden.de/~fm3 ##
participants (2)
-
Derick Swanepoel -
Frank Mehnert