[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMbhsRS2gNegBYJWXg-mhtpfpsi53e2B_oLtj49iZmyM31a5-g@mail.gmail.com>
Date: Mon, 26 Sep 2022 15:38:33 -0700
From: Colin Cross <ccross@...roid.com>
To: Colin Cross <ccross@...roid.com>, musl@...ts.openwall.com,
Ryan Prichard <rprichard@...gle.com>
Subject: Re: Running musl executables without a preinstalled dynamic linker
On Tue, Aug 23, 2022 at 1:18 AM Szabolcs Nagy <nsz@...t70.net> wrote:
>
> * Colin Cross <ccross@...roid.com> [2022-08-22 17:22:06 -0700]:
> > On Sat, Aug 20, 2022 at 2:43 AM Szabolcs Nagy <nsz@...t70.net> wrote:
> > > i would not use Scrt1.o though, the same toolchain should be
> > > usable for normal linking and relinterp linking, just use a
> > > different name like Xcrt1.o.
> >
> > Is there some way to get gcc/clang to use Xcrt1.o without using
> > -nostdlib and passing all the crtbegin/end objects manually?
>
> this requires compiler changes (new cmdline flag) but then i think
> the code is upstreamable.
I've used relinterp.o for now, and selected instead of Scrt1.o in
musl-gcc.specs and ld.musl-clang.
>
> > > i would make Xcrt1.o self-contained and size optimized: it only
> > > runs at start up, this is a different requirement from the -O3
> > > build of normal string functions. and then there is no dependency
> > > on libc internals (which may have various instrumentations that
> > > does not work in Xcrt1.o).
> >
> > Doesn't this same logic apply to most of the code in dynlink.c? My
> > main worry with a self contained implementation is that it requires
> > reimplementations of various string functions that are easy to get
> > wrong. The current prototype reuses the C versions of musl's string
> > functions, but implements its own syscall wrappers to avoid
> > interactions with musl internals like errno.
>
> dynlink is in libc.so so it can use code from there.
>
> but moving libc code into the executable has different constraints.
> so you will have to make random decisions that string functions are
> in but errno is out, wrt which libc internal makes sense in the exe.
>
> i would just keep a separate implementation (or at least compile
> the code separately). string functions are easy to implement if
> you dont try to optimize them imo. then you have full control over
> what is going on in the exe entry code.
I left the reimplementations of string functions and syscalls as
suggested. Patch attached.
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.
