Is there a way to build a non-PIC shared library with l4env?

Adam Lackorzynski adam at os.inf.tu-dresden.de
Thu Oct 13 00:03:54 CEST 2011


On Tue Oct 11, 2011 at 18:15:57 +1300, Valery V. Sedletski wrote:
> On Mon, 10 Oct 2011 11:19:17 +0200, Adam Lackorzynski wrote:
> >> 
> >> But l4rm must be a single instance in a single application, so I need to use an l4rm instance from my application, not in a shared lib...
> >> So, I need somehow to call my application region mapper from the shared lib... But I cannot use the ldso for linkage. So I need to make
> >> the linkage manually... I see only one solution: to pass the needed l4rm function pointers to the shared lib 'init' function. But maybe,
> >> the better solution exists? Any ideas?
> >
> >Sounds hacky but I cannot provide an alternative. I think you lost me a
> >bit wrt your current setup, so if your solution works for you I'm happy.
> >
> 
> Yes, it almost works now -- I made the pointers to l4rm functions and
> some other ones, passed to the 'init' function in the shared library.
> So, I fixed the unresolved symbols, now application loads
> successfully. But it seems that some variables remained uninitialized
> -- when I call a function from the shared lib, which allocates memory,
> and calls malloc() for that, I got a message from libc (the minicmd is
> my OS/2 application):
> 
> minicmd | mmap(): mmap, fd: 0, flags: 34
> 
> and then from 'loader' server:
> 
> loader  | os2app,#17: Not allowed to perform any I/O
> 
> Regarding the loader message, it seems that the app accessed a random region in an I/O memory because of uninitialized variables. But why mmap to
> fd: 0, I cannot say. fd=0 is stdin, but I know that malloc accesses the heap but why it uses a memory-mapped files I yet don't know. So, some
> troubles are still there, but I hope I'll work it out

The flags indicates that anonymous memory is wanted, to the fd does not
play any role.

> (Note: os2app is the same app as minicmd.exe, I just chagned the log tag, but 'loader' server uses an old one)
> Still cannot say any more details, will investigate with a debugger


Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/




More information about the l4-hackers mailing list