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 <peter.mayd...@linaro.org> wrote: > On Fri, 16 Jul 2021 at 18:50, Kenneth Adam Miller > <kennethadammil...@gmail.com> 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 >
