From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129334 invoked by alias); 19 Sep 2018 23:20:59 -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 129314 invoked by uid 89); 19 Sep 2018 23:20:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_3,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=ham version=3.3.2 spammy=2s, adopt, UD:texinfo, gdb.texinfo X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Sep 2018 23:20:56 +0000 Received: from ralph.com (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id BB14B10B476; Wed, 19 Sep 2018 19:20:53 -0400 (EDT) From: John Baldwin To: gdb-patches@sourceware.org Cc: andrew.burgess@embecosm.com, jimw@sifive.com, palmer@sifive.com Subject: [PATCH 0/4] Initial support for FreeBSD/riscv Date: Wed, 19 Sep 2018 23:20:00 -0000 Message-Id: <20180919231950.22634-1-jhb@FreeBSD.org> X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00714.txt.bz2 This series adds support for FreeBSD/riscv targets. Note that I've attempted to make the port support either RV32 or RV64, but FreeBSD currently only supports RV64. Patch 1 tries to make it easier to write handlers for signal frame by allowing the register map structures used with register caches to be used with trad-frame to supply a block of registers at a starting address. It gets somewhat squishy when thinking about how to handle registers whose size doesn't match the "slot" size in a register map. I've attempted to make the trad-frame handling match the semantics that regcache uses. However, these semantics aren't documented anywhere and we should perhaps document them. Also, in this patch I used 'void *' for the map only because it matches what the regcache functions do. I'm happy to make the map argument type-safe instead if others prefer that. Also, the comments for regcache_map_entry should perhaps be made more generic to say it isn't specific to regcache but is used to describe the layout of a register block. Arguably the type should even be renamed to something less regcache-specific (register_map_entry?). If we do adopt this patch I will probably make use of it in some other FreeBSD architectures (aarch64 and arm at least, possibly x86). Patch 2's commit log is a bit preachy perhaps and can be toned down if needed. I'm curious if my thoughts about using target descriptions are correct? It is what x86 does to handle 32-bit vs 64-bit as well as handling various optional register sets. John Baldwin (4): Add helper functions to trad_frame to support register cache maps. Fall back to a default value of 0 for the MISA register. Add FreeBSD/riscv architecture. Add native target for FreeBSD/riscv. gdb/ChangeLog | 30 ++++++ gdb/Makefile.in | 4 + gdb/NEWS | 2 + gdb/configure.host | 1 + gdb/configure.nat | 4 + gdb/configure.tgt | 5 + gdb/doc/ChangeLog | 5 + gdb/doc/gdb.texinfo | 6 ++ gdb/riscv-fbsd-nat.c | 135 +++++++++++++++++++++++++++ gdb/riscv-fbsd-tdep.c | 206 ++++++++++++++++++++++++++++++++++++++++++ gdb/riscv-fbsd-tdep.h | 33 +++++++ gdb/riscv-tdep.c | 13 ++- gdb/trad-frame.c | 69 ++++++++++++++ gdb/trad-frame.h | 8 ++ 14 files changed, 519 insertions(+), 2 deletions(-) create mode 100644 gdb/riscv-fbsd-nat.c create mode 100644 gdb/riscv-fbsd-tdep.c create mode 100644 gdb/riscv-fbsd-tdep.h -- 2.18.0