From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) by sourceware.org (Postfix) with ESMTPS id 22613385E83D for ; Mon, 14 Mar 2022 14:20:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 22613385E83D Received: by mail-ot1-x32f.google.com with SMTP id w17-20020a056830111100b005b22c584b93so11845476otq.11 for ; Mon, 14 Mar 2022 07:20:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=48z3kz3vgvJc2Kk7uJ4fhy3cJT+nx77YepSAmqIP2D0=; b=Q5xySQzJw/QM7z7j78niEj71D8/CPPgpZf4TseDI4F38e8g5pzzIgqk3jLJxOGPtu8 4TO1PqfNXLNnsUxnL+BkkUP+kKA9qMCQ1fc27xrREFIAZbXvsxy5r5eZJ2RSyjyA9ZIp l5t5MHzcicA4bA9XU6sj0VR308tmlOIv98fbDqYuvHqnbis31jTquSvAqw+KNlPAJTn+ XMZ4Hr1uDAjMbx9kzKcHndaCHJTN8jNgFYG2amz+S8MY50dm8KPx6lPB92thtysXxMQf tm2fKujJ4AKuoM1dTXeW7SFuylfOpoqz32F9livMmQEhuT0NEZns0xDZJBff6eXYN7I4 fwjQ== X-Gm-Message-State: AOAM530lGTHmb4sZr2drQEBKf1UDWkg9uhzE7Z1dXypCQwefuxwK1iKf lwrm/fNxUA9DF+bDIksroaeNbuWt38J8Sw== X-Google-Smtp-Source: ABdhPJzEfzsfHjbnYrzG2MJHbDnDQpS5+no9wmUwB4JoL9wFs10Y1XxL8mS3Fe3X3IoahdT+MjSSCg== X-Received: by 2002:a05:6830:1548:b0:5b2:3046:5b9a with SMTP id l8-20020a056830154800b005b230465b9amr11147105otp.286.1647267609211; Mon, 14 Mar 2022 07:20:09 -0700 (PDT) Received: from ?IPV6:2804:431:c7ca:99a3:efb5:51f9:e70:3f04? ([2804:431:c7ca:99a3:efb5:51f9:e70:3f04]) by smtp.gmail.com with ESMTPSA id y16-20020a9d6350000000b005c9653ab377sm1256934otk.17.2022.03.14.07.20.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Mar 2022 07:20:08 -0700 (PDT) Message-ID: Date: Mon, 14 Mar 2022 11:20:05 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: Re-port Intent for HPE NonStop (a.k.a. Tandem) Content-Language: en-US To: Florian Weimer , rsbecker@nexbridge.com Cc: libc-help@sourceware.org, mike_kilpatrick@nskopensource.com, 'Bill Honaker' , jojo@schmitz-digital.de, 'Shiva Subramanian' References: <01ec01d836d7$f59d39a0$e0d7ace0$@nexbridge.com> <87k0cxynn8.fsf@oldenburg.str.redhat.com> <025601d837a1$ce111d00$6a335700$@nexbridge.com> <877d8wy8yb.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: <877d8wy8yb.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2022 14:20:12 -0000 On 14/03/2022 10:12, Florian Weimer via Libc-help wrote: >>> Can you use a GCC cross-compiler? >> >> No. GCC does not generate code that will run on the platform. While it is >> x86-based, there are complex endian concerns in the code generator, >> significant ELF header differences, and major ELF debug section differences >> that cannot be emitted by GCC. There have been at least 3 unsuccessful >> attempts I know of to port gcc to the platform and/or to generate cross >> compile code for it. > > In this case, we would really need an open toolchain, otherwise we can't > maintain the ELF parts. > > Keep in mind that glibc contains the dynamic linker, so it really has to > know about the details of your architecture. > >> I have successfully done ports of other products with the same constraint >> (git, openssh, openssl). Usually ports are possible with minimal >> changes. > > That's because you rely on the C run-time library to paper over the > differences in kernel interfaces. With glibc itself, that's different. > >> I would like to do a bit of an impact analysis to see how difficult >> this one would be. > > You need to provide the rest of the toolchain first, and that seems to > require a major effort (and it's not just about writing code). > > I also doubt that we would accept patches which retarget to a > proprietary kernel, but that depends on how invasive those patches are. > >> How should I proceed, if I need glibc as a dependency? > > You need to port GCC and binutils first, and then you can proceed with > glibc. It's how new ports are brought up. I'm not aware of any other > port in recent times that has been done in a different way (not using > GCC). This is not me being snarky, it's just that the GNU toolchain > (binutils/GCC/GDB/glibc) is an integrated whole and works best in > conjunction. Besides all Florian has pointed out, I am inclined to say that porting glibc to a non opensource architecture and also without aiming to be the 'de facto' loader/libc of the system is a dead-end. Without open-source support for at least the toolchain pieces, it is really a no-go. Also, besides probably requiring a lot of work to support any ELF and/or ABI extension, the resulting loader won't easily support the system shared libraries without a compat layer (which imposes another set of issues). Although there are some examples where it has been done with some relative success (such as gcompat for musl, or linuxabi for FreeBSD) it a relative time consuming effort where maintaining this out of tree usually ends up as a bitrotten project (as we saw for prelink, which was removed recently). Also, most of the generic interfaces glibc provide is already provided by gnulib in a extent. There are other interface that are reliant on proper kernel support, so using a different kernel might ended required *a lot* of glue code and, worse, some interfaces might not be actually be proper implemented. The truth is glibc is currently Linux oriented projected, there are some Hurd work but it is moving to nowhere (it barely supports one legacy architecture). > > It might be possible to get away with an LLVM-based toolchain, but the > porting of glibc istelf to LLVM is not yet complete, so you would > struggle on this front as well. > I am working to get glibc in a somewhat usable state with clang [1]. It still requires a *lot* of patches and I still struggling in the loader bootstrap, but at least it *builds*. [1] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/clang