From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-17.7 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by gnuweeb.org (Postfix) with ESMTPS id C52F67E309 for ; Tue, 22 Mar 2022 18:38:26 +0000 (UTC) Authentication-Results: gnuweeb.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=BGj/qAj/; dkim-atps=neutral Received: by mail-lf1-f41.google.com with SMTP id w27so31291328lfa.5 for ; Tue, 22 Mar 2022 11:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D80ySFmBsx3NNLCSuiS2ulSu3CzLkzhJu1O5d7Yeia0=; b=BGj/qAj/CIZjHIYtdJd6+Vuiq1RG+X1DBLvxqqmbqp+eZgRVkx64QSB7iE2AqLihc/ mIgD+h83xKB1b+5Duw/CRkt07LklXvjiddGvPZsj/XVa/HzsUMtEDYlGVfRtYoWthzza 8sAmKfutzHNbnBxEmWXCPdyazYKMBzku/d4/iT2QYGQ9vRCuGE3/OtB7RiHRCC9JLdP+ ptxdeoKMQHbqBxGEHVz9eEW6M8W/3LRSN40liJ7dYZJB6jlNvdQOvj3My9Zz4c8AP8qh 6p25cq+oxZGzjke9g2A+n7agtk79KVWcpwtSjurvcgnQS2/GNvNtk94A+NxlxUkNRxDH AfDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D80ySFmBsx3NNLCSuiS2ulSu3CzLkzhJu1O5d7Yeia0=; b=O+d7kRA8XvQz3dI/CZJMOecNZ1rD2thOhl9cxOgH6KjK9ateei9xEZODtMlrCDODzi orhNiubLNSQpVVVmNAULKmRk2zvj8l1QF0PhdsxX8baHyeAXW3MjMn2YtYAImID4nPjp a5Ubx1AN6Wcq08CKBhvAzg8b5daIMkN6OaqL8qKnY6TqhrO5wI1bOZBV6dDAarU9cIL2 hYwtHedcajZhC4weTuI0YPxieDPGXnNx3mnGLaUralHI5BINIdUMRMmQwispFEyepsu7 fVPNJgqJ5HHIedKdKdxdAFmmq1/O8opjLmj9jbyG+v250d+wcmyr3Ip8jg99z2LsDo2/ VnNg== X-Gm-Message-State: AOAM533p0Ao7uBKoS8rkujr6X1fLrXvfyDDfjOhJz1k1x2HjzuoNl0wg 0nhTYmCS7y6cWHuCgh5PUcgITzVXePhfkgSdfEMI2w== X-Google-Smtp-Source: ABdhPJy672VvhyeIyIjAVRfF4mLRJODEUnGZ3/5feXX2ykQinqIawhClI7hj0L6LFSzncZK/EEQCc3xzA55//DF7J84= X-Received: by 2002:a05:6512:b9e:b0:44a:10eb:9607 with SMTP id b30-20020a0565120b9e00b0044a10eb9607mr13883136lfv.626.1647974304749; Tue, 22 Mar 2022 11:38:24 -0700 (PDT) MIME-Version: 1.0 References: <20220322102115.186179-1-ammarfaizi2@gnuweeb.org> <20220322102115.186179-3-ammarfaizi2@gnuweeb.org> <20220322172550.GL10306@1wt.eu> <20220322175816.GN10306@1wt.eu> <20220322182448.GQ10306@1wt.eu> In-Reply-To: <20220322182448.GQ10306@1wt.eu> From: Nick Desaulniers Date: Tue, 22 Mar 2022 11:38:13 -0700 Message-ID: Subject: Re: [RFC PATCH v2 2/8] tools/nolibc: Remove .global _start from the entry point code To: Willy Tarreau Cc: Linux Kernel Mailing List , "GNU/Weeb Mailing List" , llvm@lists.linux.dev Content-Type: text/plain; charset="UTF-8" List-Id: On Tue, Mar 22, 2022 at 11:24 AM Willy Tarreau wrote: > > What I particularly like is that I don't need a full toolchain, so if > I can build a kernel with the bare-metal compilers from kernel.org then > I know I can also build my initramfs that's packaged in it using the > exact same compiler. This significantly simplifies the build process. Neat; yeah that coincides a bit with my interest in having builds of llvm on kernel.org; having/needing a libc is a PITA and building a full cross toolchain is also more difficult than I think it needs to be. The libc will depend on kernel headers, for each target. LLVM currently has a WIP libc in its tree; I'm looking for something I can statically link into the toolchain images (even LTO them into the image). Will probably pursue musl (if I ever get time for this, though maybe a project for my summer intern...). One thing I've been looking at is a utility called llvm-ifs [1]; it can generate .so stubs from a textual description that can be more easily read, diff'ed, and committed. These are much faster to build and reduce the chain of build dependencies (when dynamically linking). Last I checked it had issues with versioned symbols, and I'm not sure if/what it does for headers, which are still needed. Within Android, libabigail is being used to dump+diff xml descriptions of parts of an ABI, it looks like llvm-ifs might be useful for that as well. Not sure if it's interesting but thought I'd share. [1] https://www.youtube.com/watch?v=_pIorUFavc8 -- Thanks, ~Nick Desaulniers