[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I don't see how that would help much.  You still wouldn't know if the recvmsg
or sendmsg that is being called by whatever library and is interposed by
libasan etc. is the one with 64-bit msg_iovlen, msg_controllen or cmsg_len, or
32-bit one.
E.g. in write_msghdr used by recvmsg wrapper, there is:
  if (msg->msg_iov && msg->msg_iovlen)
    COMMON_INTERCEPTOR_WRITE_RANGE(ctx, msg->msg_iov,
                                   sizeof(*msg->msg_iov) * msg->msg_iovlen);
  write_iovec(ctx, msg->msg_iov, msg->msg_iovlen, maxlen);
The broken change committed to llvm repo makes this a static choice - if you
compile libsanitizer against glibc older than 2.24, you assume msg_iovlen must
be always 64-bit, even if you e.g. at runtime link against glibc 2.24 and run a
program that uses recvmsg@@GLIBC_2.24.
If you compile libsanitizer against glibc 2.24+, you assume msg_iovlen must be
always 32-bit, even if the app calls recvmsg@GLIBC_2.2.5.  Not sure what dlsym
actually gives you in that case, I think recvmsg@@GLIBC_2.24, but it would need
to be verified.
What we could do is just assume people don't really use > 2G values in these
cases, and just use (int) msg->msg_iovlen instead of msg->msg_iovlen (for Linux
only).  Similarly for the other two fields, and perhaps keep the structures as
is and just make the size and offset checks for these fields accept all the
expected variants (i.e. also the case where the glibc headers have the field
half the size and for big endian also at a different offset (difference of half
the size).
For e.g. asan, this would just mean that programs linked against glibc < 2.24
that use > 2GB msg_iovlen and overwrite through that some buffer wouldn't be
detected, I think that is sufficiently rare that it might be acceptable.
Over time more and more programs/libraries will be rebuilt against glibc >=
2.24 and the problem will go away there.