From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15680 invoked by alias); 11 Jan 2019 23:23:40 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 15669 invoked by uid 89); 11 Jan 2019 23:23:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org 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=sk:return_ X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: excelsior.roeckx.be Received: from excelsior.roeckx.be (HELO excelsior.roeckx.be) (195.234.45.115) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 Jan 2019 23:23:37 +0000 Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id B2BE4A8A0C80; Fri, 11 Jan 2019 23:23:32 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 82E4A1FE0AF0; Sat, 12 Jan 2019 00:23:32 +0100 (CET) Date: Fri, 11 Jan 2019 23:23:00 -0000 From: Kurt Roeckx To: Mark Wielaard Cc: Jim Wilson , elfutils-devel@sourceware.org, Karsten Merker Subject: Re: RISC-V support Message-ID: <20190111232332.GA12090@roeckx.be> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00025.txt.bz2 On Tue, Jan 08, 2019 at 02:52:33PM +0100, Mark Wielaard wrote: > > There is a problem here though. The riscv support was written to try > > to handle both 32-bit and 64-bit targets with a single elfutils > > backend. But I have 6 ABIs I need to (theoretically) handle in > > riscv_retval.c. The return_value_location function doesn't take any > > ebl or elf pointer, so I can't handle it there. I can handle it in > > riscv_init.c by checking ebl and elf pointers there, and calling an > > appropriate function, but I'm not sure if that is OK. Currently, > > none > > of the *_init.c files are using the elf pointer argument. > > The ppc64 init does (to lookup the odp table which is necessary for > ppc64[be], but not ppc64le). It is allowed. And the backends/ebl > interface is completely internal, so feel free to suggest changes if > they make sense for riscv. If it is necessary we'll just update the > other backends. I've been looking at mips, and it seems to have many different ABIs too. A patch I've received does this: int mips_return_value_location (Dwarf_Die *functypedie, const Dwarf_Op **locp) { /* First find the ABI used by the elf object */ enum mips_abi abi = find_mips_abi(functypedie->cu->dbg->elf); The patch only supports 6 ABIs, but I think there are really over 10 ABIs. Maybe it would be good that we only need to determine the ABI once, instead of each time the function is called. Kurt