From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62210 invoked by alias); 5 Jun 2018 01:18:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 62201 invoked by uid 89); 5 Jun 2018 01:18:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:p8-v6so, struggling, H*RU:74.125.83.68, Hx-spam-relays-external:74.125.83.68 X-HELO: mail-pg0-f68.google.com Received: from mail-pg0-f68.google.com (HELO mail-pg0-f68.google.com) (74.125.83.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Jun 2018 01:18:49 +0000 Received: by mail-pg0-f68.google.com with SMTP id p8-v6so318555pgq.10 for ; Mon, 04 Jun 2018 18:18:49 -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=LFSlEC90Vekf0pxdOlbSyeNoSgz7GuJvoiPjDNvQ/0g=; b=rTPtrtl6AGz1loFaMoz+wHPCWNql8roJfDdjtJ6AXpHtSVHnulD+hYs2RcbmhJoCo2 tnrCIhu50gFhciuZSx9Q44442al4T7XXrKklDqWGIbXlW/ExDe+QGbnkAOimI0pjSq7M a7DnMAtDmSuK9tFkdFwZnvqHnSin4md+du5R2dw2gYIv7EcHGXmHWP91E2GfaRSvvi2m UAwDJQjky5A4zYsbupJzfu9Np8LEWkbJFmyK+7GYI3Q55lPckrc0JQwnCyl0G65U5HNU 3y3Aqpeu8SQeC1r7i9uPfXBRi9tHXoeO8BDqMR6FbH9DVFR7C5ll8xV19o8aBP5qNO0Z mcbQ== X-Gm-Message-State: ALKqPwcuCYTnfCTIoXckGUNHVf2uZsk7PmRt+ZzdOsb0RCU84mXP1vTT joxgMLLTame8gHgba0gKZfFTPA== X-Google-Smtp-Source: ADUXVKLxRlJXfb9vRlG+qNoaBCMQoz/AkiGZNFjG8pRxHzw0FXrOse6uSUyzSu4sn7G0k938WBkLww== X-Received: by 2002:a63:ba56:: with SMTP id l22-v6mr19203483pgu.161.1528161527724; Mon, 04 Jun 2018 18:18:47 -0700 (PDT) Received: from localhost ([12.206.222.5]) by smtp.gmail.com with ESMTPSA id b74-v6sm59685805pfl.138.2018.06.04.18.18.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jun 2018 18:18:47 -0700 (PDT) Date: Tue, 05 Jun 2018 01:18:00 -0000 X-Google-Original-Date: Mon, 04 Jun 2018 18:14:33 PDT (-0700) Subject: RE: RISC-V ELF multilibs In-Reply-To: CC: Jim Wilson , sebastian.huber@embedded-brains.de, gcc@gcc.gnu.org From: Palmer Dabbelt To: Matthew.Fortune@mips.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2018-06/txt/msg00047.txt.bz2 On Thu, 31 May 2018 07:23:22 PDT (-0700), Matthew.Fortune@mips.com wrote: > Palmer Dabbelt writes: >> On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote: >> > On 05/26/2018 06:04 AM, Sebastian Huber wrote: >> >> Why is the default multilib and a variant identical? >> > >> > This is supposed to be a single multilib, with two names. We use >> > MULTILIB_REUSE to map the two names to a single multilib. >> > >> > rohan:1030$ ./xgcc -B./ -march=rv64imafdc -mabi=lp64d --print-libgcc >> > ./rv64imafdc/lp64d/libgcc.a >> > rohan:1031$ ./xgcc -B./ -march=rv64gc -mabi=lp64d --print-libgcc >> > ./rv64imafdc/lp64d/libgcc.a >> > rohan:1032$ ./xgcc -B./ --print-libgcc >> > ./libgcc.a >> > rohan:1033$ >> > >> > So this is working right when the -march option is given, but not >> when >> > no -march is given. I'd suggest a bug report so I can track this, if >> > you haven't already filed one. >> >> IIRC this is actually a limit of the GCC build system: there needs to >> be some >> default multilib, and it has to be unprefixed. I wanted to keep the >> library >> paths orthogonal (ie, not bake in a default that rv64gc/lp64d lives at >> /lib), >> so I chose to just build a redundant multilib. >> >> It'd be great to get rid of this, but I'm afraid it's way past my level >> of >> understanding as to how all this works. > > I do actually have a solution for this but it is not submitted upstream. > MIPS has basically the same set of problems that RISC-V does in this area > and in an ideal world there would be no 'fallback' multilib such that if > you use compiler options that map to a library variant that does not > exist then the linker just fails to find any libraries at all rather than > using the default multilib. > > I can share the raw patch for this and try to give you some idea about how > it works. I am struggling to find time to do much open source support at > the moment so may not be able to do all the due diligence to get it > committed. Would you be willing to take a look and do some of the work to > get it in tree? If you have a rough patch that'd be great, it'll be at least a starting point. Last time I poked around I wasn't ever sure where to look. Thanks!