GCC currently hard-codes the size of struct pthread in the sanitizers, in ThreadDescriptorSize in libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp. Starting with glibc 2.34 and this commit commit fef400a2f976d1fd6a4639e6980f6c50ee13fbf5 Author: Florian Weimer <fweimer> Date: Mon Jun 28 14:33:53 2021 +0200 nptl: Export libthread_db-used symbols under GLIBC_PRIVATE This allows distributions to strip debugging information from libc.so.6 without impacting the debugging experience. Reviewed-by: Carlos O'Donell <carlos> it is possible to determine sizeof (struct pthread) using dl(v)sym, like this: const unsigned int *psize = dlvsym(RTLD_DEFAULT, "_thread_db_sizeof_pthread", "GLIBC_PRIVATE"); if (psize != nullptr) { val = *psize; atomic_store_relaxed(&thread_descriptor_size, val); return val; } I'm not sure if upstream (GCC or Clang) will take this change, but we should definitely make it downstream, to avoid mysterious sanitizer problems if we need to change struct pthread in glibc.
That change would be fine with me but I think we should at least have an upstream bug report.
(In reply to Marek Polacek from comment #1) > That change would be fine with me but I think we should at least have an > upstream bug report. Opened: https://github.com/llvm/llvm-project/issues/52989
I'll leave this for RHEL 9.1, I think.
(In reply to Marek Polacek from comment #3) > I'll leave this for RHEL 9.1, I think. I changed the layout of struct pthread in glibc-2.34-19.el9 (bug 2024347). I think this means that we need to verify that the hard-coded constants are still correct on all architectures. I had hoped to avoid that by getting rid of the constants.
And if this gets fixed in RHEL 9.0, we can avoid all that verification? If this is more important than I though, I'm happy to reconsider.
(In reply to Marek Polacek from comment #6) > And if this gets fixed in RHEL 9.0, we can avoid all that verification? I think so, that's why I'm suggesting it. GCC (the sanitizers) will then just use the constant computed from sizeof (struct pthread) during the glibc build, using glibc's internal definition of struct pthread. Maybe we should bring this up during tomorrow's cross-team call, given that the sanitizers live more on the LLVM side of things.
(In reply to Florian Weimer from comment #7) > (In reply to Marek Polacek from comment #6) > > And if this gets fixed in RHEL 9.0, we can avoid all that verification? > > I think so, that's why I'm suggesting it. GCC (the sanitizers) will then > just use the constant computed from sizeof (struct pthread) during the glibc > build, using glibc's internal definition of struct pthread. Ok. > Maybe we should bring this up during tomorrow's cross-team call, given that > the sanitizers live more on the LLVM side of things. Sounds good. Moving back to RHEL 9.0.
LLVM upstream patch review: https://reviews.llvm.org/D119007
Patch pushed upstream: commit ef14b78d9a144ba81ba02083fe21eb286a88732b (HEAD -> main, origin/main) Author: Florian Weimer <fweimer> Date: Tue Feb 8 12:46:41 2022 -0800 [sanitizer] Use _thread_db_sizeof_pthread to obtain struct pthread size This symbol has been exported (as an internal GLIBC_PRIVATE symbol) from libc.so.6 starting with glibc 2.34. glibc uses it internally for its libthread_db implementation to enable thread debugging on GDB, so it is unlikely to go away for now. Fixes #52989. Reviewed By: #sanitizers, MaskRay, vitalybuka Differential Revision: https://reviews.llvm.org/D119007 I think I'll put it into RHEL 9 gcc now, hoping that eventually it'll be squeezed out when the patch makes its way into Fedora gcc. Thanks Florian.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (new packages: gcc), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:3966