The 30379efad1 added _FORTIFY_SOURCE checks without check if compiler
does support all used fortify levels. This patch fixes it by first
checking at configure time the maximum support fortify level and using
it instead of a pre-defined one.
Checked on x86_64 with gcc 11, 12, and 13.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Tested-by: Florian Weimer <fweimer@redhat.com>
We mentioned eventual dropping of libcrypt in the 2.28 NEWS. Actually
put that plan in motion by first disabling building libcrypt by default.
note in NEWS that the library will be dropped completely in a future
release.
Also add a couple of builds into build-many-glibcs.py.
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Andreas K. Hüttel <dilfridge@gentoo.org>
The _FORTIFY_SOURCE is used as default by some system compilers,
and there is no way to check if some fortify extension does not
trigger any conformance issue.
Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Add --enable-fortify-source option.
It is now possible to enable fortification through a configure option.
The level may be given as parameter, if none is provided, the configure
script will determine what is the highest level possible that can be set
considering GCC built-ins availability and set it.
If level is explicitly set to 3, configure checks if the compiler
supports the built-in function necessary for it or raise an error if it
isn't.
If the configure option isn't explicitly enabled, it _FORTIFY_SOURCE is
forcibly undefined (and therefore disabled).
The result of the configure checks are new variables, ${fortify_source}
and ${no_fortify_source} that can be used to appropriately populate
CFLAGS.
A dedicated patch will follow to make use of this variable in Makefiles
when necessary.
Updated NEWS and INSTALL.
Adding dedicated x86_64 variant that enables the configuration.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
We add a 'make check' test that lints all Makefiles in the source
directory of the glibc build. This linting test ensures that the
lines in all Makefiles will be sorted correctly as developers
creates patches. It is added to 'make check' because it is
light-weight and supports the existing developer workflow
The test adds ~3s to a 'make check' execution.
No regressions on x86_64 and i686.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
We must return < 0, 0, or > 0 as the result of the comparison function
for cmp_to_key() to work correctly across all comparisons.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The scripts/sort-makefile-lines.py script sorts Makefile variables
according to project expected order.
The script can be used like this:
$ scripts/sort-makefile-lines.py < elf/Makefile > elf/Makefile.tmp
$ mv elf/Makefile.tmp elf/Makefile
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
This patch updates build-many-glibcs.py to use Linux 6.3 and GCC 13
branch by default.
Tested with build-many-glibcs.py (host-libraries, compilers and glibc
builds).
And make always supported. The configure option was added on glibc 2.25
and some features require it (such as hwcap mask, huge pages support, and
lock elisition tuning). It also simplifies the build permutations.
Changes from v1:
* Remove glibc.rtld.dynamic_sort changes, it is orthogonal and needs
more discussion.
* Cleanup more code.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
It is the default since 2.26 and it has bitrotten over the years,
By using it multiple malloc tests fails:
FAIL: malloc/tst-memalign-2
FAIL: malloc/tst-memalign-2-malloc-hugetlb1
FAIL: malloc/tst-memalign-2-malloc-hugetlb2
FAIL: malloc/tst-memalign-2-mcheck
FAIL: malloc/tst-mxfast-malloc-hugetlb1
FAIL: malloc/tst-mxfast-malloc-hugetlb2
FAIL: malloc/tst-tcfree2
FAIL: malloc/tst-tcfree2-malloc-hugetlb1
FAIL: malloc/tst-tcfree2-malloc-hugetlb2
Checked on x86_64-linux-gnu.
Reviewed-by: DJ Delorie <dj@redhat.com>
This patch makes build-many-glibcs.py use the new MPFR 4.2.0 and MPC
1.3.1 releases.
Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).
The only way to override LD, AR, OBJCOPY, and GPROF is through
--with-binutils (setting the environments variables on configure is
overridden by LIBC_PROG_BINUTILS).
The build-many-glibcs.py (bmg) glibcs option generates a working config,
but not fully concise (some tools will be set from environment variable,
while other will be set from $CC --print-prog-name). So remove the
environment variable set to always use the "$CC --print-prog-name".
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
I've updated copyright dates in glibc for 2023. This is the patch for
the changes not generated by scripts/update-copyrights and subsequent
build / regeneration of generated files.
With modern ssh clients and daemons it is required to use AcceptEnv and
SendEnv configuration options to correctly support testing the DSO sort
ordering tests. This requirement is present because
scripts/dso-ordering-test.py injects GLIBC_TUNABLES to the left of the
${test_wrapper_env} and so it must both be sent by the ssh client and
accepted by the ssh daemon. This requirement is removed in this change
and the injected GLIBC_TUNABLES is placed after ${run_program_env} and
so still correctly provides the override that the test requires.
This is similar to existing tests like elf/tst-pathopt.sh,
elf/tst-rtld-load-self.sh, and locale/tst-locale-locpath.sh.
Tested that it fixes two failures when cross-testing on aarch64 with
scripts/cross-test-ssh.sh and an ssh client and daemon that do not pass
GLIBC_TUNABLES. Without this fix such a configuration will report the
following failures (since the GLIBC_TUNABLES not preserved):
FAIL: elf/tst-bz15311
FAIL: elf/tst-bz28937
Tested without regression on native x86_64 and aarch64 builds.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
The assembler is not issued directly, but rather always through CC
wrapper. The binutils version check if done with LD instead.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
From the tests point of view, this is a necessary step for another
patch [1] and allows parsing macros such as "#define A | B". Without
it, a few tests [2] choke when the other patch [1] is applied:
/src/glibc/scripts/../elf/elf.h:4167: error: uninterpretable macro
token sequence: ( EF_ARC_MACH_MSK | EF_ARC_OSABI_MSK )
Traceback (most recent call last):
File "/src/glibc/elf/tst-glibcelf.py", line 23, in <module>
import glibcelf
File "/src/glibc/scripts/glibcelf.py", line 226, in <module>
_elf_h = _parse_elf_h()
^^^^^^^^^^^^^^
File "/src/glibc/scripts/glibcelf.py", line 223, in _parse_elf_h
raise IOError('parse error in elf.h')
OSError: parse error in elf.h
[1] ARC: update definitions in elf/elf.h
https://sourceware.org/pipermail/libc-alpha/2022-November/143503.html
[2]
tst-glibcelf, tst-relro-ldso, and tst-relro-libc
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
Without this change, parse failures result in an exception:
Traceback (most recent call last):
File "tst-glibcelf.py", line 23, in <module>
import glibcelf
File "/path/to/git/scripts/glibcelf.py", line 226, in <module>
_elf_h = _parse_elf_h()
File "/path/to/git/scripts/glibcelf.py", line 221, in _parse_elf_h
result = glibcpp.macro_eval(glibcpp.macro_definitions(tokens), reporter)
File "/path/to/git/scripts/glibcpp.py", line 379, in macro_eval
reporter.error(md.line, 'macro {} redefined'.format(md.name))
File "/path/to/git/scripts/glibcelf.py", line 214, in error
errors += 1
UnboundLocalError: local variable 'errors' referenced before assignment
The initializer for a tunable_t set the bool initialized flag to NULL.
This causes a build failure when pointer to bool conversion warns.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
On csky-linux-gnuabiv2, binutils 2.33 produces a DT_JMPREL entry
for the dynamic loader if it does not contain any PLT relocations:
Dynamic section at offset 0x1df48 contains 19 entries:
Tag Type Name/Value
0x0000000e (SONAME) Library soname: [ld-linux-cskyv2-hf.so.1]
0x00000004 (HASH) 0xd4
0x6ffffef5 (GNU_HASH) 0x1a8
0x00000005 (STRTAB) 0x4ac
0x00000006 (SYMTAB) 0x28c
0x0000000a (STRSZ) 527 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000003 (PLTGOT) 0x1f000
0x00000002 (PLTRELSZ) 0 (bytes)
0x00000014 (PLTREL) RELA
0x00000017 (JMPREL) 0xaa4
0x00000007 (RELA) 0x75c
0x00000008 (RELASZ) 840 (bytes)
0x00000009 (RELAENT) 12 (bytes)
0x6ffffffc (VERDEF) 0x700
0x6ffffffd (VERDEFNUM) 3
0x6ffffff0 (VERSYM) 0x6bc
0x6ffffff9 (RELACOUNT) 68
0x00000000 (NULL) 0x0
This confuses the script:
Unexpected output from check-localplt: …/elf/ld.so.jmprel:
*** DT_JMPREL does not match any section's address
This commit changes the script to record the DT_PLTRELSZ value and
reject DT_JMPREL values not a section boundary only if DT_PLTRELSZ
is present with a non-zero value.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The need to maintain elf/elf.h and scripts/glibcelf.py in parallel
results in a backporting hazard: they need to be kept in sync to
avoid elf/tst-glibcelf consistency check failures. glibcelf (unlike
tst-glibcelf) does not use the C implementation to extract constants.
This applies the additional glibcpp syntax checks to <elf.h>.
This changereplaces the types derived from Python enum types with
custom types _TypedConstant, _IntConstant, and _FlagConstant. These
types have fewer safeguards, but this also allows incremental
construction and greater flexibility for grouping constants among
the types. Architectures-specific named constants are now added
as members into their superclasses (but value-based lookup is
still restricted to generic constants only).
Consequently, check_duplicates in elf/tst-glibcelf has been adjusted
to accept differently-named constants of the same value if their
subtypes are distinct. The ordering check for named constants
has been dropped because they are no longer strictly ordered.
Further test adjustments: Some of the type names are different.
The new types do not support iteration (because it is unclear
whether iteration should cover the all named values (including
architecture-specific constants), or only the generic named values),
so elf/tst-glibcelf now uses by_name explicit (to get all constants).
PF_HP_SBP and PF_PARISC_SBP are now of distinct types (PfHP and
PfPARISC), so they are how both present on the Python side. EM_NUM
and PT_NUM are filtered (which was an oversight in the old
conversion).
The new version of glibcelf should also be compatible with earlier
Python versions because it no longer depends on the enum module and its
advanced features.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The main program needs to depend on all shared objects, even objects
that have link-time dependencies among shared objects. Filtering
out shared objects that already have an link-time dependencies is not
necessary here; make will do this automatically.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This reverts commit 6f85dbf102.
Once this change hits the release branches, it will require relinking
of all statically linked applications before static dlopen works
again, for the majority of updates on release branches: The NEWS file
is regularly updated with bug references, so the __libc_early_init
suffix changes, and static dlopen cannot find the function anymore.
While this ABI check is still technically correct (we do require
rebuilding & relinking after glibc updates to keep static dlopen
working), it is too drastic for stable release branches.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The files NEWS, include/link.h, and sysdeps/generic/ldsodefs.h
contribute to the version fingerprint used for detection. The
fingerprint can be further refined using the --with-extra-version-id
configure argument.
_dl_call_libc_early_init is replaced with _dl_lookup_libc_early_init.
The new function is used store a pointer to libc.so's
__libc_early_init function in the libc_map_early_init member of the
ld.so namespace structure. This function pointer can then be called
directly, so the separate invocation function is no longer needed.
The versioned symbol lookup needs the symbol versioning data
structures, so the initialization of libc_map and libc_map_early_init
is now done from _dl_check_map_versions, after this information
becomes available. (_dl_map_object_from_fd does not set this up
in time, so the initialization code had to be moved from there.)
This means that the separate initialization code can be removed from
dl_main because _dl_check_map_versions covers all maps, including
the initial executable loaded by the kernel. The lookup still happens
before relocation and the invocation of IFUNC resolvers, so IFUNC
resolvers are protected from ABI mismatch.
The __libc_early_init function pointer is not protected because
so little code runs between the pointer write and the invocation
(only dynamic linker code and IFUNC resolvers).
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
ELF and GNU hashes can now be computed using the elf_hash and
gnu_hash functions.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
This patch makes build-many-glibcs.py use binutils 2.39 branch.
Tested with build-many-glibcs.py (compilers and glibcs builds). Note:
binutils 2.39 shows the same failures for i686-linux-gnu-no-pie,
x86_64-linux-gnu-no-pie and x86_64-linux-gnu-x32-no-pie building the
glibc testsuite as binutils mainline does.
This patch updates various miscellaneous files from their upstream
sources (version 2022-05-25).
It is required for loongarch support.
Checked on aarch64-linux-gnu.
