From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCO8w-0000U6-1T for qemu-devel@nongnu.org; Mon, 13 Jun 2016 05:26:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCO8t-0007M4-UT for qemu-devel@nongnu.org; Mon, 13 Jun 2016 05:26:48 -0400 Received: from mail-vk0-x22e.google.com ([2607:f8b0:400c:c05::22e]:36597) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCO8t-0007Lw-Pn for qemu-devel@nongnu.org; Mon, 13 Jun 2016 05:26:47 -0400 Received: by mail-vk0-x22e.google.com with SMTP id u64so59733399vkf.3 for ; Mon, 13 Jun 2016 02:26:47 -0700 (PDT) MIME-Version: 1.0 From: Peter Maydell Date: Mon, 13 Jun 2016 10:26:27 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: [Qemu-devel] linux-user: drop support for "unknown" host CPUs (ie hppa and m68k) ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: QEMU Developers Cc: Riku Voipio , Laurent Vivier Currently our configure script allows linux-user targets to be built for "unknown" host CPU architectures (which must be using the TCI interpreter). However, code like user-exec.c has host-architecture #ifdef ladders which in practice mean you can't build linux-user for an arbitrary host architecture. The only two host architectures which have code in user-exec.c but aren't recognised by configure are HPPA and m68k. I'd like to move to an "every supported host architecture has a linux-user/host/$(ARCH)/hostdep.h header" model (this fixes a problem in the code currently in master where make doesn't notice it needs to rebuild if a host arch moves from "using generic/" to "using $(ARCH)"). Host architectures which we sort-of-but-don't support are an annoying corner case I'd like to be able to drop entirely, by either: (1) just dropping the support outright (2) promoting them to at least being recognised by configure as a known architecture, even if one without a tcg backend Does this seem like a good idea? I think HPPA should definitely be in category (1) -- we dropped the TCG backend years back, and I don't think any of us has a machine to test changes on,. Which category should m68k host support go into? Does anybody actually use m68k host + TCI interpreter linux-user ? My guess is this isn't actually used, because the m68k-specific code in user-exec.c doesn't set the "is_write" flag correctly, which means that guests which do self-modifying code won't work (including anything using a signal handler with an on-stack trampoline). So my preference would be to drop the m68k-host code too. thanks -- PMM