From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) by sourceware.org (Postfix) with ESMTPS id A69663857C43 for ; Wed, 9 Sep 2020 04:23:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A69663857C43 Received: by mail-pf1-x441.google.com with SMTP id o68so1150322pfg.2 for ; Tue, 08 Sep 2020 21:23:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=DtQAdZsOXJ1veVFvor7CMmZlhGOT1Cjrb6KEGXCBO4E=; b=t2k3Gu1sOyNCKcxba/TM9Hg1LUeDJWOVdBdGehoosgiKYX9Tdf4kIuC4Zf38qBZpt5 QFprXqrpI0jlwAWNwMo8holnl9wQ5fFuEsIX1X2Bu4/9iyoDCd4jkueCbuEATuCe6v8A gB9+XzI0Go7FzjaFh43KKiEjwqMcZCriWwL9lNAifb6Dpoxa3JXyb4NnfMGCuvZH1kzj GioI3ra1wZ5ujhwCQP/IbLGban8w0msBIvMDzYYxwNhYHBp8dhSv83oUIyYswAT6kdFd Ch/OESPIvRWs8stgEmC0ePa253OwyIjLOVhH84BVAPBTiRwPtdsuJxatYH7qc6dARd/E hhZQ== X-Gm-Message-State: AOAM530C+FzmANDjjTqZzUvQeBBQIFvvM46NotKsLjOG4MavN21/FojZ xZycDQf85GouW+K1i/mLhiajS88O5XRggDcp X-Google-Smtp-Source: ABdhPJy2iMGHzkXYSWIWzFB5ZS9HRObKJHri6jR3YOgHLm8gkM2gSqb2+CRhFKrAmZ8zUsn6yZdrwg== X-Received: by 2002:aa7:961b:0:b029:13e:d13d:a140 with SMTP id q27-20020aa7961b0000b029013ed13da140mr2300019pfg.40.1599625379521; Tue, 08 Sep 2020 21:22:59 -0700 (PDT) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id d8sm651084pgt.19.2020.09.08.21.22.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2020 21:22:59 -0700 (PDT) Date: Tue, 08 Sep 2020 21:22:59 -0700 (PDT) X-Google-Original-Date: Tue, 08 Sep 2020 21:22:50 PDT (-0700) Subject: Re: RISC-V 64bit and 32bit binaries on the same system In-Reply-To: <12603168.s5MMGUR32x@farino> CC: joseph@codesourcery.com, libc-alpha@sourceware.org From: Palmer Dabbelt To: libc-alpha@sourceware.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-20.5 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 04:23:02 -0000 On Mon, 07 Sep 2020 10:05:22 PDT (-0700), libc-alpha@sourceware.org wrote: >> > gcc and glibc build and install fine. However, there's a fundamental >> > problem with this configuration. ld.so does not filter by ELFCLASS (as it >> > does, e.g., for x64-64 vs i686), and the order of directories in the >> > dynamic linker config determines e.g. which libstdc++ a binary sees >> > first. [#] >> >> Whenever I asked about such configurations, the answer was always that the >> Linux kernel port did not support running RV32I processes on RV64I >> processors, although the architecture definition supported it as an >> optional feature. I don't know if that Linux kernel support has since >> been implemented. > > Not to my knowledge. We don't have any plans to do it soon, as there's no hardware out there and nobody is clamoring for it. The last glibc post I see on this is from January 2018, and since then we have sufficient ISA support to implement this sort of thing (the UXL field) but I know of any hardware that implements it or anyone who's particularly interested in doing so. >> is >> where I described what you need to do in glibc to support that kind of >> configuration for an architecture. > > Yeah, that's the more knowledgeable answer compared to my newbie digging at > what is needed. > > (And it looks like a comparatively large amount of work for a situation that > is right now fairly hypothetical, unless you try silly things with qemu like > me). It'd be great to bootstrap all the multilib stuff, but it's just a matter of priorities. It's a fairly large amount of work to put this all together, but it shouldn't be all that hard to add writable XLEN to QEMU which would allow Linux to spin up rv32 processes. There'd be a big pile of work left at that point, though... > So maybe the multilib defaults of gcc should be changed? Either way, that seems reasonable to me. If we ever implement it we can always add the multilibs back, but it doesn't seem reasonable to default to something broken. I bet you guys are the first to take a shot at the Linux multilib stuff, so I anticipate a bunch of stuff will be broken. Do you want to send a GCC patch, or do you want me to? > -- > Andreas K. Hüttel > dilfridge@gentoo.org > Gentoo Linux developer > (council, qa, toolchain, base-system, perl, libreoffice)