Commit Graph

3 Commits

Author SHA1 Message Date
Peter Maydell ee8e76141b linux-user: Use correct target SHMLBA in shmat()
The shmat() handling needs to do target-specific handling
of the attach address for shmat():
 * if the SHM_RND flag is passed, the address is rounded
   down to a SHMLBA boundary
 * if SHM_RND is not passed, then the call is failed EINVAL
   if the address is not a multiple of SHMLBA

Since SHMLBA is target-specific, we need to do this
checking and rounding in QEMU and can't leave it up to the
host syscall.

Allow targets to define TARGET_FORCE_SHMLBA and provide
a target_shmlba() function if appropriate, and update
do_shmat() to honour them.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Riku Voipio <riku.voipio@linaro.org>
2016-09-21 14:28:52 +03:00
Markus Armbruster 3622634bc6 linux-user: Clean up target_syscall.h header guards
Some of them use guard symbol TARGET_SYSCALL_H, but we also have
CRIS_SYSCALL_H, MICROBLAZE_SYSCALLS_H, TILEGX_SYSCALLS_H and
__UC32_SYSCALL_H__.  They all upset scripts/clean-header-guards.pl.

Reuse of the same guard symbol TARGET_SYSCALL_H in multiple headers is
okay as long as they cannot be included together.  The script can't
tell, so it warns.

The script dislikes the other guard symbols, too.  They don't match
their file name (they should, to make guard collisions less likely),
and __UC32_SYSCALL_H__ is a reserved identifier.

Clean them all up: use guard symbol $target_TARGET_SYSCALL_H for
linux-user/$target/target_sycall.h.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
2016-07-12 16:19:16 +02:00
Lluís Vilanova 460c579f3d build: [linux-user] Rename "syscall.h" to "target_syscall.h" in target directories
This fixes double-definitions in linux-user builds when using the UST
tracing backend (which indirectly includes the system's "syscall.h").

Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Riku Voipio <riku.voipio@linaro.org>
2016-02-23 21:25:09 +02:00