From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id 93AE8385841A for ; Thu, 25 Aug 2022 07:17:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 93AE8385841A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x632.google.com with SMTP id h22so27521847ejk.4 for ; Thu, 25 Aug 2022 00:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=+jVoqaNM36HWLZX0AUx79lAxKF1nw9yt07um83v8+2I=; b=BrSWvlCB+i7Cc7FL9BOuQp0l/Y0YTdmv8E1Pqt5s4FT44xCklE8LCwAv94PG/hPXGC yA/fxIkOdPaWGgkEeWjBWK+FXzdo41/m852xTMAf18qk6wRZtPUicFSbrsDedSm5cRne Usri+H09gnJcLeKt+F8OYngpoYDBKvKX6Rr2+VSPpZZ/SZkAEJnNJT4kEEd2m14+kTJd qXjpwnKD8+5Oo6xKZPZuGWmz3c8QD20+pc09ClFLlXdXECABMwQwoI0t44SxG2msRXYf I/S0pCd1tEjJbH8POxPVjZX7c07uq2yhyAajnI+m1BG2nXEzcUwkZ+mEnV0ZhJq3VkVj y+nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=+jVoqaNM36HWLZX0AUx79lAxKF1nw9yt07um83v8+2I=; b=GpswV0SpmqKroitTGzJLAOLU1KSV/PvGcdW76X2WmOrpN03a7iQ8bBR5lK+4hULaxr 8wyttkdj3Q6PD7vJArSbF46AWrrmdBxHWgbBlhNy3f9wZVOpZz8Mh8yk4CEi/QdTWFjs uh08VWC+5jS7Gp6sAspNDNUbgkxW7AYdFYA1KOcSscBtlnwqgHEa8iNwqIoKs+h1qQH2 DG5xH5w1GoFg2HlC85k0WV5Zff4vLuIU90pa6D8w5OjHN/TPfLDKjy81Q6aXOEp++1OK fe4D39/+c8wjyZjBrzY/IFQ0OwTI/fHICNTz1mCTUSnJHyL8Esvklh8O8vHMTku+22DE 7skA== X-Gm-Message-State: ACgBeo0qqRn6eaQxSoBimCS8yCNo8zPCsba3s6JF996dam1nIqxnzfsI xH1ynQIHdN6NaeKHMkZ9l5NiHMFKxyIc0FFvPwI= X-Google-Smtp-Source: AA6agR5OWR8I4KTFRSXf9vq5TLfToGwzw2zxt4E5wppzo6ctu/cF53Qr6Va1mv1xenuFDB0/zKq/LjQRvvWKk5l4ibI= X-Received: by 2002:a17:906:cc5d:b0:73d:c534:1aaa with SMTP id mm29-20020a170906cc5d00b0073dc5341aaamr1549999ejb.626.1661411830730; Thu, 25 Aug 2022 00:17:10 -0700 (PDT) MIME-Version: 1.0 References: <20220824180426.820576-1-keithp@keithp.com> <87a67ta14r.fsf@keithp.com> In-Reply-To: <87a67ta14r.fsf@keithp.com> From: Kito Cheng Date: Thu, 25 Aug 2022 15:16:58 +0800 Message-ID: Subject: Re: [PATCH 0/3] picolibc: Add picolibc linking help To: Keith Packard Cc: Andrew Pinski , GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: I am thinking that maybe we should add -mlibc=[newlib|newlib-nano|picolibc|unknown] option to bare-matel toolchain, one reason is having an unify interface to select libc implementation between clang/LLVM, spec file is a GCC specific stuff, that cause very bad compatibility between GCC and clang/LLVM, and having option to control that would be better since clang/LLVM don't have those configure time option. For linux toolchain, it uses -mbionic, -muclibc, -mglibc and -mmusl, maybe we could also use an unify -mlibc= option for that? On Thu, Aug 25, 2022 at 3:32 AM Keith Packard via Gcc-patches wrote: > > Andrew Pinski writes: > > (removing gcc@ as not appropriate for patch discussions) > > Thanks for reviewing my patches; I appreciate the time you have taken to > think about this. > > > Why do you need to change the specs to support picolibc? Why not have > > the library supply the specs file instead, like what is done for > > newlib and libgloss? > > Several architectures do include support for newlib's libgloss in their > gcc configuration today (i386, m32r, microblaze, nds32, pru, riscv and > sh), so I wondered if it made sense to add support for picolibc's > target-specific libraries as well. > > Picolibc does deliver a spec file fragment which implements this > functionality, but that requires the addition of --specs=picolibc.specs > to the gcc command line instead of being built-in to gcc itself. When > creating an integrated toolchain using picolibc, it seems a bit odd to > require an option for the toolchain to work. > > > What OS libraries are not included in libc? I trying to figure out why > > this needs to be special cased here. > > As a general-purpose embedded C library, picolibc doesn't include any > OS-specific code. Instead, it defines a limited subset of POSIX > interfaces which are to be supplied by the target platform. > > Picolibc itself supplies sample implementations of these ABIs that can > run on top of bare metal systems with semihosting support which are used > while testing picolibc itself. > > This is similar to newlib's libgloss: the C library is built atop > another library which needs to follow it in the linker command line for > symbol resolution to work correctly. Making this work requires a change > in the *lib spec file fragment. > > Adjusting the *lib fragment can either be done in an externally provided > specs file, or built-in to gcc. Both of these mechanisms are present in > the gcc ecosystem today, leading me to wonder whether the gcc community > would be interested in having an integrated option available. > > -- > -keith