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) >