English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Dynamically loaded BSS not initialised to 0.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-01-08 (20:12)
From: Guillaume Yziquel <guillaume.yziquel@c...>
Subject: Re: [Caml-list] Dynamically loaded BSS not initialised to 0.
Richard Jones a écrit :
>> Problem solved: This is in fact a symbol collision problem on the symbol 
>> 'box'. There's one in libncurses, which is loaded by ocamlrun.
> Good ol' ELF loading model ...  Uli wrote a really good introduction
> to writing DSOs which everyone should read:
> http://people.redhat.com/drepper/dsohowto.pdf

Indeed, it's very very good. Thanks a lot for this pointer.

> The issue of symbol scope is covered there too, although I don't think
> it can help in this case.  One or other of the libraries is just going
> to have to change the visibility of that symbol.

Yes. This has been done on the MonetDB side. They're going to make 'box' 
locally static, and to rename it...

> In ncurses it's a
> public symbol, but if I understand the code correctly, in MonetDB it's
> just an accidentally leaked global variable (not part of the API).  So
> MonetDB could control the visibility of that symbol using a linker
> script.

Yes, they probably could, but it seems to me that they have other 
priorities for now.

> We use linker scripts extensively in libvirt to control which
> clients can see which sets of symbols, eg:
> http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/libvirt_public.syms;hb=HEAD
> http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/libvirt_private.syms;hb=HEAD
> In answer to your original question, initialization of the BSS is the
> job of the loader (ld-linux.so(8)).  OCaml just calls dlopen(3), which
> calls into some extremely well-tested code, so it was always going to
> be unlikely that BSS initialization was the problem.
> Rich.

Thanks. I was quite sure that the loader was doing a proper job. I 
wasn't sure however that OCaml was calling dlopen, and I was wondering 
at the time if the linking scheme used by OCaml depended or not on 
whether we're dealing with OCaml bytecode or OCaml native code. In this 
context I was wondering if the BSS was initialised to 0, since on some 
hardware, it's not necessarily the case (it seems... I would not bet my 
hand on this).

I now know better.

Anyway, it was an interesting bug: I'm growing fond of assembly.

All the best,

      Guillaume Yziquel