From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4930 invoked by alias); 9 Aug 2018 00:25:58 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 4919 invoked by uid 89); 9 Aug 2018 00:25:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=minute, chromebook X-HELO: mail-wr1-f65.google.com Received: from mail-wr1-f65.google.com (HELO mail-wr1-f65.google.com) (209.85.221.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Aug 2018 00:25:56 +0000 Received: by mail-wr1-f65.google.com with SMTP id h15-v6so3550604wrs.7 for ; Wed, 08 Aug 2018 17:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nOcTo5ngKdJVco72ie1bSqkVjx79jpo5hTN5h+B7AVE=; b=dJ1lYfcy+W08ZTJvy4QKrsToENo6knkcO1s0qELIkAlT7G0PtVaHSxMTnHxALofeNQ XH2sP6ZpCnPZrObxylyVCdEsL+INY115Erosv2nsuWozb1rpNkKNU8u1Y/sTYE7cshwu PnYHrGxnQn1/z6Uzpa78gWgbRNu01JAhb2N37UyzMQpU4kfB1cvt74rhoAjfh81Ffs3x T/RQSr8+8FUkKqMquVgfNbfBNN5EDxnAVm9hNjYlssnU/SSGLR7CGC7+Z6A95j4cUL5A JNMPGv2Lm9SA7CdCynBBGEb0qq4XI2KBhkAdaRUnzKxXv1BnfDceshQcAXweh+FCyFDn KniA== MIME-Version: 1.0 Received: by 2002:adf:e44b:0:0:0:0:0 with HTTP; Wed, 8 Aug 2018 17:25:53 -0700 (PDT) In-Reply-To: <871sb8ahs9.fsf@tromey.com> References: <20180808021734.7844-1-jimw@sifive.com> <871sb8ahs9.fsf@tromey.com> From: Jim Wilson Date: Thu, 09 Aug 2018 00:25:00 -0000 Message-ID: Subject: Re: [PATCH 5/5] RISC-V: Add configure support riscv*-linux*. To: Tom Tromey Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-08/txt/msg00197.txt.bz2 On Wed, Aug 8, 2018 at 10:29 AM, Tom Tromey wrote: >>>>>> "Jim" == Jim Wilson writes: > > Jim> * Makefile.in (ALLDEPFILES): Add riscv-linux-nat.c, riscv-linux-tdep.c. > > This doesn't mention the ALL_TARGET_OBS change. This is something I noticed was missing at the last minute and managed to screwed it up when i tried to fix it. I added the missing ChangeLog entry. > Jim> ravenscar-thread.o \ > Jim> + riscv-linux-nat.o \ > Jim> + riscv-linux-tdep.o \ > Jim> riscv-tdep.o \ > Jim> rl78-tdep.o \ > Jim> rs6000-aix-tdep.o \ > > I think only the tdep file should be listed here. Yes. I removed the riscv-linux-nat.o file from this list. > Is riscv a 64-bit architecture? (I don't know.) If so, gdb still > splits 64-bit targets into a separate variable, I think in case one is > building on a 32-bit machine without a 64-bit integer type (or maybe if > you didn't want to use the extra memory to inflate a bunch of type > sizes, not sure). In this case you'd want to add the tdep file to > ALL_64_TARGET_OBS instead. > > I wonder if this 32/64 bit thing is needed any more. To add to what Palmer said, the current riscv port is intended to support both 32-bit and 64-bit. It checks a hardware register or the ELF header flags to get the word size, and then things like register sizes are based on the word size. However, I only have access to a working 64-bit linux port, so the 32-bit linux support has not been tested yet. 32-bit glibc support was just recently submitted upstream, and we are hoping to get that resolved in time for the next glibc release early next year. The 32-bit linux kernel was booting but not running init last I heard, so that needs some bug fixing too. Once 32-bit linux support is sorted out I will start testing the gdb support for that. I am currently testing 32-bit linux binutils and gcc support using a user-mode qemu and some old glibc sources, but I don't think that I can do any useful gdb testing that way. While we have support for both 32-bit and 64-bit in theory, we can probably only support one target at the time, as this gets computed early and I don't think that we support changes to it. I think I'd have to define two targets, and have two sets of initialization functions, etc. This is something I can't easily do when I don't have access to the 32-bit linux target for testing yet. We also don't have any support for running 32-bit code on 64-bit systems yet, so this would be an issue only for cross gdb, and we don't have gdbserver yet so cross gdb isn't actually very useful at this time. So this all ends up being a moot question at the current time. Only the riscv64 linux gdb support is usable today. I have an ARM v7 chromebook with crouton Ubuntu chroot environment that I can use for 32-bit builds. I can try a build with --disable-64-bit-bfd and see what happens. This could take a little time, it is a slow machine, and I'll have to get the machine set up for builds again. Jim