https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
--- Comment #20 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Sergio Durigan Junior from comment #0)
> Hi,
>
> This is an interesting bug which took me quite some time to (partially)
> understand. I decided to file this upstream report to:
>
> - See if an upstream developer could help me fully understand what's going
> one, and
> - Get a patch backported to GCC 14 to fix the issue.
>
> It all started when we noticed that compiling a glibc using the following
> hardening flags (from the OpenSSF project) would lead to an abortion in
> certain scenarios:
>
> ====
> *self_spec:
> + %{!O:%{!O1:%{!O2:%{!O3:%{!O0:%{!Os:%{!0fast:%{!0g:%{!0z:-O2}}}}}}}}}
> -fhardened -Wno-error=hardened -Wno-hardened
> %{!fdelete-null-pointer-checks:-fno-delete-null-pointer-checks}
> -fno-strict-overflow -fno-strict-aliasing
> %{!fomit-frame-pointer:-fno-omit-frame-pointer} -mno-omit-leaf-frame-pointer
>
> *link:
> + --as-needed -O1 --sort-common -z noexecstack -z relro -z now
> ====
>
> It is important to notice that:
>
> - The bug only happens when using a glibc compiled with the "-z now"
> hardening flag. If the flag is removed, then the abort doesn't occur.
> - The bug only happens when using a glibc compiled with GCC 14.x (14.3
> included).
Please provide the output of
# readelf -rW elf/rtld.os | grep __ehdr_start
on the bad glibc build. Is there
0000000000000000 0000000800000001 R_X86_64_64 0000000000000000
__ehdr_start + 0
