qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] linux-user's __get_user/__put_user macros vs clang-7 -Waddr


From: Peter Maydell
Subject: [Qemu-devel] linux-user's __get_user/__put_user macros vs clang-7 -Waddress-of-packed-member
Date: Thu, 27 Sep 2018 18:02:26 +0100

clang 7 complains about taking the address of a member of a
packed struct, which is good because those are usually bugs.
Unfortunately it also means it complains a lot if you pass
&packed_struct->field to __get_user or __put_user, even
though in fact those macros are totally safe, since their
entire purpose is to deal with the data via a load/store
function that can handle an unaligned address:

linux-user/syscall.c:6831:25: warning: taking address of packed member
'l_type' of class or structure 'target_oabi_flock64' may result in an
unaligned pointer value [-Waddress-of-packed-member]
    __get_user(l_type, &target_fl->l_type);
                        ^~~~~~~~~~~~~~~~~
linux-user/qemu.h:491:47: note: expanded from macro '__get_user'
# define __get_user(x, hptr)  __get_user_e(x, hptr, le)
                                              ^~~~
linux-user/qemu.h:479:19: note: expanded from macro '__get_user_e'
  ((x) = (typeof(*hptr))(                                               \
                  ^~~~
linux-user/syscall.c:6831:25: warning: taking address of packed member
'l_type' of class or structure 'target_oabi_flock64' may result in an
unaligned pointer value [-Waddress-of-packed-member]
    __get_user(l_type, &target_fl->l_type);
                        ^~~~~~~~~~~~~~~~~
linux-user/qemu.h:491:47: note: expanded from macro '__get_user'
# define __get_user(x, hptr)  __get_user_e(x, hptr, le)
                                              ^~~~
linux-user/qemu.h:480:35: note: expanded from macro '__get_user_e'
   __builtin_choose_expr(sizeof(*(hptr)) == 1, ldub_p,                  \
                                  ^~~~
linux-user/syscall.c:6831:25: warning: taking address of packed member
'l_type' of class or structure 'target_oabi_flock64' may result in an
unaligned pointer value [-Waddress-of-packed-member]
    __get_user(l_type, &target_fl->l_type);
                        ^~~~~~~~~~~~~~~~~
linux-user/qemu.h:491:47: note: expanded from macro '__get_user'
# define __get_user(x, hptr)  __get_user_e(x, hptr, le)
                                              ^~~~
linux-user/qemu.h:481:35: note: expanded from macro '__get_user_e'
   __builtin_choose_expr(sizeof(*(hptr)) == 2, lduw_##e##_p,            \
                                  ^~~~
linux-user/syscall.c:6831:25: warning: taking address of packed member
'l_type' of class or structure 'target_oabi_flock64' may result in an
unaligned pointer value [-Waddress-of-packed-member]
    __get_user(l_type, &target_fl->l_type);
                        ^~~~~~~~~~~~~~~~~
linux-user/qemu.h:491:47: note: expanded from macro '__get_user'
# define __get_user(x, hptr)  __get_user_e(x, hptr, le)
                                              ^~~~
linux-user/qemu.h:482:35: note: expanded from macro '__get_user_e'
   __builtin_choose_expr(sizeof(*(hptr)) == 4, ldl_##e##_p,             \
                                  ^~~~
linux-user/syscall.c:6831:25: warning: taking address of packed member
'l_type' of class or structure 'target_oabi_flock64' may result in an
unaligned pointer value [-Waddress-of-packed-member]
    __get_user(l_type, &target_fl->l_type);
                        ^~~~~~~~~~~~~~~~~
linux-user/qemu.h:491:47: note: expanded from macro '__get_user'
# define __get_user(x, hptr)  __get_user_e(x, hptr, le)
                                              ^~~~
/home/petmay01/linaro/qemu-from-laptop/qemu/linux-user/qemu.h:483:35:
note: expanded from macro '__get_user_e'
   __builtin_choose_expr(sizeof(*(hptr)) == 8, ldq_##e##_p, abort))))   \
                                  ^~~~


The problem here is that clang complains about
sizeof(*&p->member) and typeof(*&p->member).
Arguably this is a compiler bug, but does anybody
have a suggestion for working around it ?

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]