From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12602 Path: news.gmane.org!.POSTED!not-for-mail From: Bracken Dawson Newsgroups: gmane.linux.lib.musl.general Subject: Re: Program with constructor function segfaults frequently with musl Date: Thu, 15 Mar 2018 11:28:56 +0000 Message-ID: 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: multipart/alternative; boundary="94eb2c11713823101e056771cc2a" X-Trace: blaine.gmane.org 1521113230 16964 195.159.176.226 (15 Mar 2018 11:27:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Mar 2018 11:27:10 +0000 (UTC) To: Bracken Dawson , musl@lists.openwall.com Original-X-From: musl-return-12616-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 15 12:27:06 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 1ewR2I-0004KK-3h for gllmg-musl@m.gmane.org; Thu, 15 Mar 2018 12:27:06 +0100 Original-Received: (qmail 23689 invoked by uid 550); 15 Mar 2018 11:29:10 -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 23660 invoked from network); 15 Mar 2018 11:29:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3YM+hRf3qBMY6G8yI12EJQKNvWSZZvt4VUWtPsHE8VE=; b=qXZ2EfOcMWWrChmtl78Y9SlcZylWEZ35iW8ydGmYR3ZERRBOo2h5+oOHH5j5j4qJ3U J21i8SJ1U5SzXY4f4ri6v7pWMFcwEs+mCmSsQepffFfAROvnBjRyOyFLZOR8fxqX0a9t VwFJ3PAHOnQwDmD7XUNYeir7mtMFZupmXCGUD/hezbo5OjVyEilwlWwYXTS/NKjZ1C+3 EJMprroa6d0nzb52YW778IMbzwV4LjmCH0UQ07QdK/kUKmsCEkQIh9KgoCqgh5TMaILj WGBqMjBdNe3Xe6A6223/Q6klWGacYFQYsD1hX30gOBKG311RXdyqtTBPk6TrtB+PWFqt 0EIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3YM+hRf3qBMY6G8yI12EJQKNvWSZZvt4VUWtPsHE8VE=; b=clrOH5KnSuNfhpTnGSEmdnpm5FEDToWLdYGGZ/0+GHf96W3SQLOe0q/9YkVyYpk6HA x8qFnNMQAJJiVbJZFg3ZheuQw6QOCQ5mq2GilaPlKxGWf+GtdTRuEWDOBZXzh/O4UNW5 NpVLcrX8O5dIOfHzo8fT+QwNEXT7YpV7r7ojuBhol7JVX8XS/u2QxdBTQixLzhpQZrN/ XDrlyemHNfbaukTO+peBVmk6Aua7MiO3ok+XejokiszkN3EYxKutFD1FzOhgw/zEp++s fToDAvF0yy+jKoY0Q65pz2HHN5EmDoDdKfLRDG39+qBd2Iw72/YkZF340k1ywzRQ0w4v 2b4g== X-Gm-Message-State: AElRT7El3qTNqfUBKeV2Xoww5y4UmFWsoV87OoiyBNUHKV8d3vjX/2Ik Z156s4ug1l8sOT/9jfaZ52xGrRbrRUQrNNNTHBQ= X-Google-Smtp-Source: AG47ELuHuWJ4jDHp7Ubr1msVTOQV1A3UZXEKBD3I391f15nd4rgpkKfJAYcbLLUgTxc5a+cTkcclv1T7QqerkQrjE7M= X-Received: by 10.36.239.70 with SMTP id i67mr6020183ith.51.1521113337367; Thu, 15 Mar 2018 04:28:57 -0700 (PDT) In-Reply-To: <20180315111705.GV4418@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:12602 Archived-At: --94eb2c11713823101e056771cc2a Content-Type: text/plain; charset="UTF-8" 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. 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) > --94eb2c11713823101e056771cc2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sadly my use case is to set a given mnt namespace before g= o 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 j= ust something I can get away with today in glibc that musl will never suppo= rt.

Thanks for looking though.

:wq

On 15 March 2018 at 11:17, Szabolcs Nagy <nsz@= port70.net> wrote:
* Szabol= cs Nagy <nsz@port70.net> [2018-= 03-15 12:01:44 +0100]:
> * Bracken Dawson <abdawson@gmail.com> [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 <stdio.h>
> > #include <stdlib.h>
> > #include <getopt.h>
> >
> > __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/develope= rs/gabi/latest/ch5.dynamic.html#init_fini

ah this does not explain the type signature, the right link is
http://www.sco.com/developers/<= wbr>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)

--94eb2c11713823101e056771cc2a--