Browse thread
Dynamically loaded BSS not initialised to 0.
-
Guillaume Yziquel
-
Guillaume Yziquel
-
Richard Jones
- Guillaume Yziquel
-
Richard Jones
-
Guillaume Yziquel
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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
http://yziquel.homelinux.org/