From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12603 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Program with constructor function segfaults frequently with musl Date: Thu, 15 Mar 2018 13:12:29 +0100 Message-ID: <20180315121228.GW4418@port70.net> References: <20180315110143.GU4418@port70.net> <20180315111705.GV4418@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1521115842 31063 195.159.176.226 (15 Mar 2018 12:10:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Mar 2018 12:10:42 +0000 (UTC) User-Agent: Mutt/1.9.1 (2017-09-22) Cc: Bracken Dawson To: musl@lists.openwall.com Original-X-From: musl-return-12617-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 15 13:10:38 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ewRiQ-00080E-KF for gllmg-musl@m.gmane.org; Thu, 15 Mar 2018 13:10:38 +0100 Original-Received: (qmail 9619 invoked by uid 550); 15 Mar 2018 12:12:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9598 invoked from network); 15 Mar 2018 12:12:40 -0000 Mail-Followup-To: musl@lists.openwall.com, Bracken Dawson Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:12603 Archived-At: * Bracken Dawson [2018-03-15 11:28:56 +0000]: > Sadly my use case is to set a given mnt namespace before go becomes > multi-threaded, which happens before the go main() function, so I do depend > on reading argv in the constructor, I mean I could use a file or something > else, but would rather not. > > I guess this is just something I can get away with today in glibc that musl > will never support. > i don't think it is guaranteed that the process is single threaded by the time your ctor is called (another ctor that runs earlier can easily create other threads) so either you have full control over the runtime, in which case you should be able to do whatever you want before things become multithread without any hacks, or you have no control over the runtime, which happens when you use a high level language like go, but then you should not make any assumptions what happens under the hood since (c)go runtime may change and break your assumptions in the future. i think a better solution is e.g. having a simple executable written in c that does whatever you want and execs the real go binary after setting things up the right way. > Thanks for looking though. > > :wq > > On 15 March 2018 at 11:17, Szabolcs Nagy wrote: > > > * Szabolcs Nagy [2018-03-15 12:01:44 +0100]: > > > * Bracken Dawson [2018-03-15 10:38:31 +0000]: > > > > I have been having trouble getting a cgo program to run with musl, it > > has > > > > been segfaulting frequently and with 'No stack' when run under gdb. > > > > > > > > I have managed to reproduce such a failure in pure c with a very small > > > > example: > > > > > > > > ``` > > > > #include > > > > #include > > > > #include > > > > > > > > __attribute__((constructor)) void enter_namespace(int argc, char > > *argv[]) { > > > > > > the arguments passed to ctors are not part of the elf abi > > > http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#init_fini > > > > ah this does not explain the type signature, the right link is > > http://www.sco.com/developers/gabi/latest/ch4.sheader.html#init_array > > > > > (and it cannot really work for dynamically loaded libraries anyway: > > > the application can arbitrarily clobber argv by that time) > > > > > > glibc passes these arguments as an extension (the semantics > > > for dlopened libraries is unclear), which happens to work > > > since the calling convention of functions with no arguments > > > allows this on all supported targets. > > > > > > (note that there are security hardenning solutions that check > > > the call site function signature against the callee and abort on > > > mismatch and such extension would not work with that) > > > > > > is this cgo that tries to capture argv in a ctor or some other > > > c library? (in either case you should first try to solve it > > > portably without depending on the glibc extension) > >