After checking around, I don't see any <target>_user_ss in any target directory. And I only see *_user_ss in the linux-user subdirectory. Were you talking about that meson.build in linux-user?
On Fri, Jul 16, 2021 at 1:20 PM Kenneth Adam Miller < kennethadammil...@gmail.com> wrote: > 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 >> >
