From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8B5DC12002 for ; Fri, 16 Jul 2021 18:22:23 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0A235613F1 for ; Fri, 16 Jul 2021 18:22:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A235613F1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:52768 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m4STc-00040r-V7 for qemu-devel@archiver.kernel.org; Fri, 16 Jul 2021 14:22:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37838) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m4SSJ-0003JB-6S for qemu-devel@nongnu.org; Fri, 16 Jul 2021 14:20:59 -0400 Received: from mail-ot1-x333.google.com ([2607:f8b0:4864:20::333]:34737) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m4SSE-0004XM-V3 for qemu-devel@nongnu.org; Fri, 16 Jul 2021 14:20:58 -0400 Received: by mail-ot1-x333.google.com with SMTP id t4-20020a05683014c4b02904cd671b911bso2719018otq.1 for ; Fri, 16 Jul 2021 11:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z31sDMBu18ZNjblDN3KPwvVI3k+dnrNCCDieExRiBjI=; b=nyprU7RezkOesXSf+gydgzJlFero1OeidvNmQU7e0DkLFvI4Y6UHxRCiKps/S5QLAo KCR4AQeJtic0hZ3J3fxh8mowgUw4nUUgqQEq9g5OoJpxPq0QCodi99LtukTuulRMFRPO jKdtfLYxnVpLdzHgtyPQshbM/5M0BjhaD3XQKaEWB6NrB4KkCZ5pcMVZCqdZ6QAkTOEu LXosp2wn62cOCNfzNkidBPbIUiIr5ymmSgXcgiUR6FQIJt3+kfIbyAIR4kyOG6W45OBp 3UsqPrDpWUmnqmbSXV57NYXnq1LgQ89Q79mL7BHDhvMRSD4duugGOeG5s2cYljWgQIo7 6cVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z31sDMBu18ZNjblDN3KPwvVI3k+dnrNCCDieExRiBjI=; b=HAu84jE8Xg4IULu42wGj09SU3ZnsrlOONyPnLRqrh0OHLYH40LfNY+SaVKYCq6j0TV ETOqGoAgnUW40j3uXBxeNC3ybIw7rDDD6PjTeyW3YJkwiK0McHdoZTC4KvFjeP/vvrBB KrzI0EVfctkS7hVcVELMmiXQ04owsLh7RJssxuVWaYQ5H6nVqxmO8HjpLMB8SBTevQOx 0g8G2qTp8+uCUMRXLSkS+6IN4+ibtlvYJiZqjVxjQpaZ+RsE0eIalshklLUCrc91sjjD dRfTUriWHyRztQ8sMmSY57QM3g6DUlDPXszz9JJzsFr6Canqy4apR/5hd/CJdBu9fxr+ DN+g== X-Gm-Message-State: AOAM531Fz3oNKPzuW/BARqsrust912hvVWCbySA/Cb7DrbkHGx/eiZy6 o7WYmr9Sdz6zYgquUz0LBD31OHCUb1lzTK0EREE= X-Google-Smtp-Source: ABdhPJycmToNAN03sonxgPrE7rgCIwz1Sen4osGc5cKT2wpPzl0Rxn1bfm7rlI9w9djAEZrJigGxrRo0DuMPixFRohQ= X-Received: by 2002:a9d:3e06:: with SMTP id a6mr9132349otd.50.1626459653610; Fri, 16 Jul 2021 11:20:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kenneth Adam Miller Date: Fri, 16 Jul 2021 13:20:41 -0500 Message-ID: Subject: Re: QEMU System and User targets To: Peter Maydell Content-Type: multipart/alternative; boundary="000000000000e5207b05c741a5cc" Received-SPF: pass client-ip=2607:f8b0:4864:20::333; envelope-from=kennethadammiller@gmail.com; helo=mail-ot1-x333.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: QEMU Developers Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000e5207b05c741a5cc Content-Type: text/plain; charset="UTF-8" Right, that's what I was thinking, that I shouldn't be building that for the system target. That's why I started out with the question that I did, because I was thinking that it probably hard codes it to user emulation. Currently though, understanding qemu internals is not so clear to me as I'm just becoming familiar with the code base. On Fri, Jul 16, 2021 at 1:05 PM Peter Maydell wrote: > On Fri, 16 Jul 2021 at 18:50, Kenneth Adam Miller > wrote: > > There's a lot of files and I don't want to muddy up the discussion with > too many details. > > If you don't provide details, you get vague answers. Your choice :-) > > > And for sure, this is not a problem with the upstream qemu. I'm working > on adding a target, and this is just what I'm experiencing. As for my > target, it has includes that correspond to finds within sub-directories of > qemu components, and I just mean that the include directives are only the > file name (no path prefix), but such file can be found only in folders > other than the include directory. One example is qemu.h; it is in > linux-user. You can get the compilation to find exactly just that file, but > it includes other files, and it isn't reasonable to edit anything outside > of my own architecture implementation. I'm wondering if perhaps anything > that makes an include to linux-user would need to be moved into the user > target source set, because currently it is in the shared. > > The broad-strokes answer is "your code in target/whatever should generally > not be including files that are neither in include/ nor in > target/whatever". > If you find yourself doing that you've probably structured something wrong > (otherwise other targets would also have run into this). > > For linux-user/qemu.h in particular, the top level meson.build does > add linux-user/ to the include path, but only for when it is building > files for the linux-user targets. (It makes no sense to include that header > file into code built for system emulation.) > > Of the 4 targets that #include "qemu.h" in target/whatever code, 3 of them > (m68k, nios2, arm) do it only for their semihosting .c file, and there > the #include "qemu.h" is inside an #ifdef CONFIG_USER_ONLY. (Semihosting > is a bit of an odd thing which works differently for usermode and > system emulation mode, which is why it needs this linux-user header.) > The 4th is hexagon, and that is a bug in the hexagon code which is only > going unnoticed because hexagon currently supports only the linux-user > target and not system emulation. > > thanks > -- PMM > --000000000000e5207b05c741a5cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right, that's what I was thinking, that I shouldn'= t be building that for the system target. That's why I started out with= the question that I did, because I was thinking that it probably hard code= s it to user emulation. Currently though, understanding qemu internals is n= ot so clear to me as I'm just becoming familiar with the code base.
On F= ri, Jul 16, 2021 at 1:05 PM Peter Maydell <peter.maydell@linaro.org> wrote:
On Fri, 16 Jul 2021 at 18:50, Kennet= h Adam Miller
<kennet= hadammiller@gmail.com> wrote:
> There's a lot of files and I don't want to muddy up the discus= sion with too many details.

If you don't provide details, you get vague answers. Your choice :-)
> And for sure, this is not a problem with the upstream qemu. I'm wo= rking on adding a target, and this is just what I'm experiencing. As fo= r my target, it has includes that correspond to finds within sub-directorie= s of qemu components, and I just mean that the include directives are only = the file name (no path prefix), but such file can be found only in folders = other than the include directory. One example is qemu.h; it is in linux-use= r. You can get the compilation to find exactly just that file, but it inclu= des other files, and it isn't reasonable to edit anything outside of my= own architecture implementation. I'm wondering if perhaps anything tha= t makes an include to linux-user would need to be moved into the user targe= t source set, because currently it is in the shared.

The broad-strokes answer is "your code in target/whatever should gener= ally
not be including files that are neither in include/ nor in target/whatever&= quot;.
If you find yourself doing that you've probably structured something wr= ong
(otherwise other targets would also have run into this).

For linux-user/qemu.h in particular, the top level meson.build does
add linux-user/ to the include path, but only for when it is building
files for the linux-user targets. (It makes no sense to include that header=
file into code built for system emulation.)

Of the 4 targets that #include "qemu.h" in target/whatever code, = 3 of them
(m68k, nios2, arm) do it only for their semihosting .c file, and there
the #include "qemu.h" is inside an #ifdef CONFIG_USER_ONLY. (Semi= hosting
is a bit of an odd thing which works differently for usermode and
system emulation mode, which is why it needs this linux-user header.)
The 4th is hexagon, and that is a bug in the hexagon code which is only
going unnoticed because hexagon currently supports only the linux-user
target and not system emulation.

thanks
-- PMM
--000000000000e5207b05c741a5cc--