[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMbhsRTF4GoWf8MjRuabC5VH6Bar3tkX7wKM=mSOcqTtGT29GQ@mail.gmail.com>
Date: Mon, 26 Sep 2022 15:42:01 -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 Mon, Sep 26, 2022 at 3:38 PM Colin Cross <ccross@...roid.com> wrote:
>
> 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.
View attachment "0001-Add-entry-point-to-find-dynamic-loader-relative-to-t.patch" of type "text/x-patch" (36213 bytes)
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.
