libstdc++: Do not check getentropy and arc4random for cross builds #8
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The "getentropy" and "arc4random" check may not yield a correct result for the cross compile builds because linking is often not available for them and the C library headers (notoriously, newlib) may still declare these function prototypes even if they are not actually part of the final library -- for this reason, this commit disables the "getentropy" and "arc4random" checks for non-native builds. This effectively prevents the std::random_device from making use of these functions when `--with-newlib` is specified, which is indeed a correct behaviour because the newlib does not provide a default stub for the "getentropy" function (also note that the newlib "arc4random" implementation internally calls the missing "getentropy" function). For other C libraries, the `GLIBCXX_CROSSCONFIG` function may hard-code the availability of these functions by manually defining `HAVE_GETENTROPY` and `HAVE_ARC4RANDOM`, or by calling the `GLIBCXX_CHECK_GETENTROPY` and `GLIBCXX_CHECK_ARC4RANDOM` functions. libstdc++-v3: * configure.ac: Relocate GLIBCXX_CHECK_GETENTROPY and GLIBCXX_CHECK_ARC4RANDOM * configure: Regenerate. Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
stephanosio
force-pushed
the
no_arc4random_for_newlib
branch
from
722afb4 to
55addb0
Compare
|
Has this been reported to upstream GCC? Have you proposed the patch upstream or has this only been fixed in Zephyr's downstream GCC toolchain? |
No, this patch has not been upstreamed. It will likely need some additional work/generalisation to be upstream-worthy. |
algitbot
pushed a commit
to alpinelinux/aports
that referenced
this pull request
Jan 27, 2023
Without this patch, linking any C++ software against libstdc++ fails with an undefined reference to getentropy(3). This is due to the fact that newlib declares a getentropy function prototype without providing the symbol. This patch fixes the issue by backporting a non-upstreamed GCC fix from the SDK for the Zephyr operating system. See: zephyrproject-rtos/gcc#8
nashif
pushed a commit
that referenced
this pull request
May 31, 2025
…o_debug_section [PR116614]
cat abc.C
#define A(n) struct T##n {} t##n;
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7) A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7) B(n##8) B(n##9)
#define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7) C(n##8) C(n##9)
#define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7) D(n##8) D(n##9)
E(1) E(2) E(3)
int main () { return 0; }
./xg++ -B ./ -o abc{.o,.C} -flto -flto-partition=1to1 -O2 -g -fdebug-types-section -c
./xgcc -B ./ -o abc{,.o} -flto -flto-partition=1to1 -O2
(not included in testsuite as it takes a while to compile) FAILs with
lto-wrapper: fatal error: Too many copied sections: Operation not supported
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
The following patch fixes that. Most of the 64K+ section support for
reading and writing was already there years ago (and especially reading used
quite often already) and a further bug fixed in it in the PR104617 fix.
Yet, the fix isn't solely about removing the
if (new_i - 1 >= SHN_LORESERVE)
{
*err = ENOTSUP;
return "Too many copied sections";
}
5 lines, the missing part was that the function only handled reading of
the .symtab_shndx section but not copying/updating of it.
If the result has less than 64K-epsilon sections, that actually wasn't
needed, but e.g. with -fdebug-types-section one can exceed that pretty
easily (reported to us on WebKitGtk build on ppc64le).
Updating the section is slightly more complicated, because it basically
needs to be done in lock step with updating the .symtab section, if one
doesn't need to use SHN_XINDEX in there, the section should (or should be
updated to) contain SHN_UNDEF entry, otherwise needs to have whatever would
be overwise stored but couldn't fit. But repeating due to that all the
symtab decisions what to discard and how to rewrite it would be ugly.
So, the patch instead emits the .symtab_shndx section (or sections) last
and prepares the content during the .symtab processing and in a second
pass when going just through .symtab_shndx sections just uses the saved
content.
2024-09-07 Jakub Jelinek <jakub@redhat.com>
PR lto/116614
* simple-object-elf.c (SHN_COMMON): Align comment with neighbouring
comments.
(SHN_HIRESERVE): Use uppercase hex digits instead of lowercase for
consistency.
(simple_object_elf_find_sections): Formatting fixes.
(simple_object_elf_fetch_attributes): Likewise.
(simple_object_elf_attributes_merge): Likewise.
(simple_object_elf_start_write): Likewise.
(simple_object_elf_write_ehdr): Likewise.
(simple_object_elf_write_shdr): Likewise.
(simple_object_elf_write_to_file): Likewise.
(simple_object_elf_copy_lto_debug_section): Likewise. Don't fail for
new_i - 1 >= SHN_LORESERVE, instead arrange in that case to copy
over .symtab_shndx sections, though emit those last and compute their
section content when processing associated .symtab sections. Handle
simple_object_internal_read failure even in the .symtab_shndx reading
case.
(cherry picked from commit bb8dd09)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The "getentropy" and "arc4random" check may not yield a correct result
for the cross compile builds because linking is often not available for
them and the C library headers (notoriously, newlib) may still declare
these function prototypes even if they are not actually part of the
final library -- for this reason, this commit disables the "getentropy"
and "arc4random" checks for non-native builds.
This effectively prevents the std::random_device from making use of
these functions when
--with-newlibis specified, which is indeed acorrect behaviour because the newlib does not provide a default stub
for the "getentropy" function (also note that the newlib "arc4random"
implementation internally calls the missing "getentropy" function).
For other C libraries, the
GLIBCXX_CROSSCONFIGfunction may hard-codethe availability of these functions by manually defining
HAVE_GETENTROPYandHAVE_ARC4RANDOM, or by calling theGLIBCXX_CHECK_GETENTROPYandGLIBCXX_CHECK_ARC4RANDOMfunctions.libstdc++-v3:
* configure.ac: Relocate GLIBCXX_CHECK_GETENTROPY and
GLIBCXX_CHECK_ARC4RANDOM
* configure: Regenerate.
Signed-off-by: Stephanos Ioannidis root@stephanos.io