From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 9EED2BBAF for ; Fri, 8 Jan 2010 21:12:23 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4CAKAgR0tV2gB5h2dsb2JhbACDXpd3AQEBCgsIBxWsNI0KgSuCLlYEiSY X-IronPort-AV: E=Sophos;i="4.49,243,1262559600"; d="scan'208";a="53527249" Received: from emailfrontal2.citycable.ch ([85.218.0.121]) by mail4-smtp-sop.national.inria.fr with SMTP; 08 Jan 2010 21:12:23 +0100 Received: from [192.168.0.12] (unknown [85.218.92.99]) (Authenticated sender: guillaume.yziquel@citycable.ch) by emailfrontal2.citycable.ch (Postfix) with ESMTPA id 823CE834319; Fri, 8 Jan 2010 21:12:18 +0100 (CET) Message-ID: <4B479196.9020005@citycable.ch> Date: Fri, 08 Jan 2010 21:12:06 +0100 From: Guillaume Yziquel Reply-To: guillaume.yziquel@citycable.ch User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707) MIME-Version: 1.0 To: Richard Jones Cc: OCaml List Subject: Re: [Caml-list] Dynamically loaded BSS not initialised to 0. References: <4B40815E.3050707@citycable.ch> <4B412680.7090405@citycable.ch> <20100104141028.GA3841@annexia.org> In-Reply-To: <20100104141028.GA3841@annexia.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; guillaume:01 guillaume:01 bss:01 ocamlrun:01 model:01 drepper:01 pointer:01 ncurses:01 extensively:01 bss:01 ocaml:01 dlopen:01 ocaml:01 dlopen:01 bytecode:01 Richard Jones a =C3=A9crit : > >> Problem solved: This is in fact a symbol collision problem on the symb= ol=20 >> 'box'. There's one in libncurses, which is loaded by ocamlrun. >=20 > Good ol' ELF loading model ... Uli wrote a really good introduction > to writing DSOs which everyone should read: >=20 > 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'=20 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=20 priorities for now. > We use linker scripts extensively in libvirt to control which > clients can see which sets of symbols, eg: >=20 > http://libvirt.org/git/?p=3Dlibvirt.git;a=3Dblob;f=3Dsrc/libvirt_public= .syms;hb=3DHEAD > http://libvirt.org/git/?p=3Dlibvirt.git;a=3Dblob;f=3Dsrc/libvirt_privat= e.syms;hb=3DHEAD >=20 > 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. >=20 > Rich. Thanks. I was quite sure that the loader was doing a proper job. I=20 wasn't sure however that OCaml was calling dlopen, and I was wondering=20 at the time if the linking scheme used by OCaml depended or not on=20 whether we're dealing with OCaml bytecode or OCaml native code. In this=20 context I was wondering if the BSS was initialised to 0, since on some=20 hardware, it's not necessarily the case (it seems... I would not bet my=20 hand on this). I now know better. Anyway, it was an interesting bug: I'm growing fond of assembly. All the best, --=20 Guillaume Yziquel http://yziquel.homelinux.org/