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: | 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 http://yziquel.homelinux.org/