From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 8570 invoked from network); 26 Sep 2022 22:39:00 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 26 Sep 2022 22:39:00 -0000 Received: (qmail 32608 invoked by uid 550); 26 Sep 2022 22:38:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32569 invoked from network); 26 Sep 2022 22:38:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=android.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date; bh=r64bCDzh+L/gWSOANu7ypNF4UNR/G8rubvw4qYdeu8w=; b=O1/N3t+OjxvATJhDfIx9QjwDCMNuCDCZjd623AljKEAKHSF/BaddDXKSEsnOAd63T4 Y5kudIYTVIoFD8o3N6UQEUXz+/q8Xqxau3TGCSpEqdsIe5zo1sNEVKSclxY7+0x7Toaj lfzAWCJtBqguJ5XbgqlKLTki1vc7IRObJaKAsfHm4rkWE9zC31UvRYoe9/oCb83aKYCQ /fug0oM2SqpxMFk/cpnDXso+wQvVcUY8CNihv9GdKgKouhEXSSCxxJHMZPWLG2S52V1i PnFSKX+KwW52cW1pYPNsZbaT4hXGqY54LlxCd24MydFOL6s62urV3OsLZePwKXECrzar XRlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=r64bCDzh+L/gWSOANu7ypNF4UNR/G8rubvw4qYdeu8w=; b=U11gA7vbUgthN5y4vEjn3TPM9NTsowhMqV2u51VHkp4lmaZSV0BG7rANLXIk1OM0z/ y5dGUcUCtXieBUuCYRZt1HN3YG1Cu5nDV2rcRbU2EOh751OVfcJQTsrhWtg8FSp0zodG ddCZzrXN1pgoGUkiEHLQvqRtU9lY3qohcc8VpbADVBif/822J8PvQGXtdzWYW/m9lpHm EQx5Q/JfF41Kr07ZWlxt7ITFN19ejz3gzWAsuZRVHyzrp8p/0r+DD2qkJAKZZ8CBkZ+Q JeU3MWAn35Ki/H+Yk2nol9HeBAHDk0pNGyaWJPGPt+Rz4Elr6JF6kFhGSzmG4KnyoIpL cwkQ== X-Gm-Message-State: ACrzQf0500E8MWiSqDLzo7xG30ijrpala0dBWjpKv0BXn4nAjdqIho05 Vyt5E9NRsBRodymfMSClXV6zVNkpelSm2IP/PStACw== X-Google-Smtp-Source: AMsMyM4cjoxiWUXkzn8Xqdp9tNMKKNJrBw5m0vY4li1cgHtl8lT0/SatHBKVAQ9uv4dRDG+x9AQq3abYjydQjMNgizo= X-Received: by 2002:a02:cca1:0:b0:358:3b30:6d23 with SMTP id t1-20020a02cca1000000b003583b306d23mr12742906jap.20.1664231925023; Mon, 26 Sep 2022 15:38:45 -0700 (PDT) MIME-Version: 1.0 References: <20220820094308.GK1320090@port70.net> <20220823081802.GM1320090@port70.net> In-Reply-To: <20220823081802.GM1320090@port70.net> From: Colin Cross Date: Mon, 26 Sep 2022 15:38:33 -0700 Message-ID: To: Colin Cross , musl@lists.openwall.com, Ryan Prichard Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] Running musl executables without a preinstalled dynamic linker On Tue, Aug 23, 2022 at 1:18 AM Szabolcs Nagy wrote: > > * Colin Cross [2022-08-22 17:22:06 -0700]: > > On Sat, Aug 20, 2022 at 2:43 AM Szabolcs Nagy 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.