[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130425064058.GE12689@port70.net>
Date: Thu, 25 Apr 2013 08:40:58 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Best place to discuss other lightweight libraries?
* Rich Felker <dalias@...ifal.cx> [2013-04-24 15:17:35 -0400]:
> On Wed, Apr 24, 2013 at 05:47:26PM +0200, Szabolcs Nagy wrote:
> > (there are some caveats in go as well: it does not call
> > __libc_start_main on startup nor exit on exit so eg atexit
> > handlers wont get called)
>
> The idea of calling functions in libc without __libc_start_main ever
> having been called sounds highly misguided and potentially dangerous.
> In musl it might mostly work, but with glibc I don't see how it could
> possibly work.
it works because _init is called by the loader before the entry point
and that does enough setup
(when cgo is used then the interpreter is set to /lib/ld-linux.so.2
in the elf header and it calls _init when it loads libc which is
listed in the dynamic section
the entry point is the go runtime which checks if it is in cgo mode
and sets up a separate pthread with libc managed stack and runs c
code there
the elf binary is prepared by the go toolchain, the go world is
statically linked including the wrapper, but there is an object
in the wrapper that is compiled with gcc and references the
extern symbols and uses the c abi, with a trick the go toolchain
knows about all the extern symbols and needed libraries which get
into the dynamic section so the c world is dynamically linked
there are some other runtime details to allow calling from go
into c and then calling back to go from c, bridging the difference
in abi and calling convenion, but basically this is how cgo works)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
