From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13492 invoked by alias); 31 May 2018 09:09:02 -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 13467 invoked by uid 89); 31 May 2018 09:09:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:sk:c2-v6mr, blog, H*RU:209.85.160.67, Hx-spam-relays-external:209.85.160.67 X-HELO: mail-pl0-f67.google.com Received: from mail-pl0-f67.google.com (HELO mail-pl0-f67.google.com) (209.85.160.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 31 May 2018 09:08:59 +0000 Received: by mail-pl0-f67.google.com with SMTP id t12-v6so12860429plo.7 for ; Thu, 31 May 2018 02:08:58 -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:message-id:mime-version :content-transfer-encoding:cc:from:to; bh=JAU06E73oaFr6RCo4vUZqz29v6Aa7exy5AApJu/wJds=; b=CS2Rbq6nlBBU4/+WyFt83RjLRvnk9aJW7p+AsQloagDmEWRnkufsmmZrEFjMb7d3Us YG7cshBybKutkgZ8tEuvsj2RFq1OULniQAXU4ew6xYNe4x0q51YfMI5ve/NmCL8AghSA Xu3vHB7nvSrwV/0wLC1s+dnB6foakZgsBptEEQuCoe8qf7bHg5ILU7kWizu86tCtGBeM F5gYOjcQOytE9fmb6ARV2LK2F9Gmq9GsdJIx6uTUjWq/DMn1MIrCh/wDVgWfxgQlY/Bb Qu6QrZScTh1twn45dIZBaS/A5CBe4SFgrlH9bbqCChCZZsSdZkHTh+fQJDftQzRwoXxc K1ZA== X-Gm-Message-State: ALKqPwdht+lIqjriz27KjBclnMQGL5HzxJFQtHy/DKIWR4NbGvIS4R3o GBlGy+DkBCbUBAQa5CJrfj4QkQ== X-Google-Smtp-Source: ADUXVKJ32xliLbDiloioSfLOYeTPVZMtq+Wg5VrmTNQv4cFABaT0QbLlZrwoqldD2MTNYpWiRRXBkQ== X-Received: by 2002:a17:902:2702:: with SMTP id c2-v6mr6063157plb.297.1527757737521; Thu, 31 May 2018 02:08:57 -0700 (PDT) Received: from localhost ([1.214.161.170]) by smtp.gmail.com with ESMTPSA id f21-v6sm68479294pfa.106.2018.05.31.02.08.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 02:08:56 -0700 (PDT) Date: Thu, 31 May 2018 09:09:00 -0000 X-Google-Original-Date: Thu, 31 May 2018 02:08:06 PDT (-0700) Subject: Re: RISC-V ELF multilibs In-Reply-To: Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit CC: sebastian.huber@embedded-brains.de, gcc@gcc.gnu.org From: Palmer Dabbelt To: Jim Wilson X-SW-Source: 2018-05/txt/msg00302.txt.bz2 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. >> Most variants include the C extension. Would it be possible to add -march=rv32g and -march=rv64g variants? > > The expectation is that most implementations will include the C > extension. It reduces code size, improves performance, and I think I > read somewhere that it takes only 400 gates to implement. > > It isn't practical to try to support every possible combination of > architecture and ABI here, as there are too many possible combinations. > But if there is a major RISC-V target that is rv32g or rv64g then we > should consider it. You can of course define your own set of multilibs. While that's the standard answer, note that Sebastian added the RISC-V RTEMS target in the first place so as far as I'm concerned he can add additional multilibs to it if he wants. While I'm not opposed to RTEMS multilibs for rv32g/ilp32d and rv64g/lp64d, note that we have made the decision in Linux land that the C extension will be common and thus I expect most RISC-V implementations with virtual memory to also have the C extension. If you go down this route then you should move RTEMS to its own multilib target fragment (t-rtems-multilib or something similar). If you need help figuring out the patch feel free to ask. I wrote a blog that might be useful https://www.sifive.com/blog/2017/09/18/all-aboard-part-5-risc-v-multilib/