Add GNU_PROPERTY_1_GLIBC_2_NEEDED
Checks
Commit Message
Motivations:
1. Some binaries which require new ELF features, like DT_RELR, only
work with the new glibc binary. They crash at run-time with the older
glibc binaries.
2. Somes binaries compiled with the new language features, like C2X
printf specifiers, only generate correct results with the new glibc
binary. Since we don't add new glibc versions to the printf function
family, they generate incorrect results at run-time with the older
glibc binaries.
Here is a proposal to encode glibc version dependencies in relocatable
objects:
/* The glibc 2 minor versions needed by the object file. */
#define GNU_PROPERTY_1_GLIBC_2_NEEDED (GNU_PROPERTY_UINT32_OR_LO + 1)
/* The lowest glibc 2 minor version. */
#define GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_BASE 35
/* Set if the object file requires glibc 2 minor version M. */
#define GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_VERSION(m) \
(1U << ((m) - GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_BASE))
Linker adds glibc versions in GNU_PROPERTY_1_GLIBC_2_NEEDED to the
.gnu.version_r section and removes GNU_PROPERTY_1_GLIBC_2_NEEDED note
when generating shared libraries and executables.
[hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n x.o
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
Properties: x86 ISA used:
x86 feature used: x86
[hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n glibc-2-minor-1.o
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: 1_glibc_2_needed: 2.35, 2.38
GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
Properties: x86 ISA used:
x86 feature used: x86
[hjl@gnu-cfl-2 elfvers-1]$ make x
gcc -B./ -o x x.o glibc-2-minor-1.o
[hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n --version-info x
Version symbols section '.gnu.version' contains 4 entries:
Addr: 0x00000000004004ae Offset: 0x0004ae Link: 6 (.dynsym)
000: 0 (*local*) 2 (GLIBC_2.34) 3 (GLIBC_2.2.5) 1 (*global*)
Version needs section '.gnu.version_r' contains 1 entry:
Addr: 0x00000000004004b8 Offset: 0x0004b8 Link: 7 (.dynstr)
000000: Version: 1 File: libc.so.6 Cnt: 4
0x0010: Name: GLIBC_2.38 Flags: none Version: 5
0x0020: Name: GLIBC_2.35 Flags: none Version: 4
0x0030: Name: GLIBC_2.2.5 Flags: none Version: 3
0x0040: Name: GLIBC_2.34 Flags: none Version: 2
...
[hjl@gnu-cfl-2 elfvers-1]$ ./x
./x: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by ./x)
./x: /lib64/libc.so.6: version `GLIBC_2.35' not found (required by ./x)
[hjl@gnu-cfl-2 elfvers-1]$
---
object-files.tex | 50 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
Comments
* H. J. Lu via llvm-dev:
> 1. Some binaries which require new ELF features, like DT_RELR, only
> work with the new glibc binary. They crash at run-time with the older
> glibc binaries.
> 2. Somes binaries compiled with the new language features, like C2X
> printf specifiers, only generate correct results with the new glibc
> binary. Since we don't add new glibc versions to the printf function
> family, they generate incorrect results at run-time with the older
> glibc binaries.
Solaris uses SHT_SUNW_verneed sections for this, not a property note.
Property notes seem the wrong approach for this. And there is no reason
to make this specific to glibc.
However, I still very much dislike this proposal.
Thanks,
Florian
On Wed, Oct 27, 2021 at 11:52 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu via llvm-dev:
>
> > 1. Some binaries which require new ELF features, like DT_RELR, only
> > work with the new glibc binary. They crash at run-time with the older
> > glibc binaries.
> > 2. Somes binaries compiled with the new language features, like C2X
> > printf specifiers, only generate correct results with the new glibc
> > binary. Since we don't add new glibc versions to the printf function
> > family, they generate incorrect results at run-time with the older
> > glibc binaries.
>
> Solaris uses SHT_SUNW_verneed sections for this, not a property note.
> Property notes seem the wrong approach for this. And there is no reason
> to make this specific to glibc.
>
> However, I still very much dislike this proposal.
>
Can you share your concerns?
Thanks.
* H. J. Lu:
> On Wed, Oct 27, 2021 at 11:52 PM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * H. J. Lu via llvm-dev:
>>
>> > 1. Some binaries which require new ELF features, like DT_RELR, only
>> > work with the new glibc binary. They crash at run-time with the older
>> > glibc binaries.
>> > 2. Somes binaries compiled with the new language features, like C2X
>> > printf specifiers, only generate correct results with the new glibc
>> > binary. Since we don't add new glibc versions to the printf function
>> > family, they generate incorrect results at run-time with the older
>> > glibc binaries.
>>
>> Solaris uses SHT_SUNW_verneed sections for this, not a property note.
>> Property notes seem the wrong approach for this. And there is no reason
>> to make this specific to glibc.
>>
>> However, I still very much dislike this proposal.
>>
>
> Can you share your concerns?
See the other thread (mostly on libc-alpha I think).
Florian
On Thu, Oct 28, 2021 at 6:43 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > On Wed, Oct 27, 2021 at 11:52 PM Florian Weimer <fweimer@redhat.com> wrote:
> >>
> >> * H. J. Lu via llvm-dev:
> >>
> >> > 1. Some binaries which require new ELF features, like DT_RELR, only
> >> > work with the new glibc binary. They crash at run-time with the older
> >> > glibc binaries.
> >> > 2. Somes binaries compiled with the new language features, like C2X
> >> > printf specifiers, only generate correct results with the new glibc
> >> > binary. Since we don't add new glibc versions to the printf function
> >> > family, they generate incorrect results at run-time with the older
> >> > glibc binaries.
> >>
> >> Solaris uses SHT_SUNW_verneed sections for this, not a property note.
> >> Property notes seem the wrong approach for this. And there is no reason
> >> to make this specific to glibc.
> >>
> >> However, I still very much dislike this proposal.
> >>
> >
> > Can you share your concerns?
>
> See the other thread (mostly on libc-alpha I think).
>
OK. Let's resolve it in the glibc community first.
Thanks.
On Wed, 27 Oct 2021, H.J. Lu via Libc-alpha wrote:
> Linker adds glibc versions in GNU_PROPERTY_1_GLIBC_2_NEEDED to the
> .gnu.version_r section and removes GNU_PROPERTY_1_GLIBC_2_NEEDED note
> when generating shared libraries and executables.
Note that there is no guarantee that a new glibc version actually has any
symbols in libc at the corresponding symbol version (there are no
GLIBC_2.20 symbols in any ABI test baseline for any architecture, for
example). If it happens not to, will the symbol version exist at all to
satisfy this check?
On Thu, Oct 28, 2021 at 10:43 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Wed, 27 Oct 2021, H.J. Lu via Libc-alpha wrote:
>
> > Linker adds glibc versions in GNU_PROPERTY_1_GLIBC_2_NEEDED to the
> > .gnu.version_r section and removes GNU_PROPERTY_1_GLIBC_2_NEEDED note
> > when generating shared libraries and executables.
>
> Note that there is no guarantee that a new glibc version actually has any
> symbols in libc at the corresponding symbol version (there are no
> GLIBC_2.20 symbols in any ABI test baseline for any architecture, for
> example). If it happens not to, will the symbol version exist at all to
> satisfy this check?
>
Then we need to add a new glibc version if it happens.
@@ -444,6 +444,7 @@ The following program property types are defined:
\texttt{GNU_PROPERTY_UINT32_AND_HI} & \texttt{0xb0007fff} \\
\texttt{GNU_PROPERTY_UINT32_OR_LO} & \texttt{0xb0008000} \\
\texttt{GNU_PROPERTY_1_NEEDED} & \texttt{GNU_PROPERTY_UINT32_OR_LO + 0} \\
+ \texttt{GNU_PROPERTY_1_GLIBC_2_NEEDED} & \texttt{GNU_PROPERTY_UINT32_OR_LO + 1} \\
\texttt{GNU_PROPERTY_UINT32_OR_HI} & \texttt{0xb000ffff} \\
\texttt{GNU_PROPERTY_LOPROC} & \texttt{0xc0000000} \\
\texttt{GNU_PROPERTY_HIPROC} & \texttt{0xdfffffff} \\
@@ -492,6 +493,11 @@ The following program property types are defined:
\item[GNU_PROPERTY_1_NEEDED]
The \code{pr_data} field contains a 4-byte integer to indicate the
properties needed by object file.
+ \item[GNU_PROPERTY_1_GLIBC_2_NEEDED]
+ The \code{pr_data} field contains a 4-byte integer to indicate the
+ minor versions of the GNU C library version 2 needed by object file.
+ This property is only valid in relocatable object files. Linker
+ should not add it to executables nor shared libraries.
\item[GNU_PROPERTY_LOPROC through GNU_PROPERTY_HIPROC]
Values in this inclusive range are reserved for processor-specific
semantics.
@@ -528,6 +534,50 @@ The following bits are defined for \code{GNU_PROPERTY_1_NEEDED}:
\end{sloppypar}
\end{description}
+The following values are defined for \code{GNU_PROPERTY_1_GLIBC_2_NEEDED}:
+
+\begin{table}[H]
+\Hrule
+ \caption{GNU_PROPERTY_1_GLIBC_2_NEEDED Values}
+ \begin{center}
+ \begin{footnotesize}
+ \begin{tabular}[t]{l|l}
+ \multicolumn{1}{c}{Name} & \multicolumn{1}{c}{Value} \\
+ \hline
+ \texttt{GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_BASE} & \texttt{35} \\
+ \texttt{GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_VERSION(m)}
+ & \texttt{1U << (m - 35)} \\
+ \end{tabular}
+ \end{footnotesize}
+ \end{center}
+\Hrule
+\end{table}
+
+\begin{description}
+ \item[GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_BASE]
+ \begin{sloppypar}
+ This specifies the oldest minor version of the GNU C library version 2
+ supported by \code{GNU_PROPERTY_1_GLIBC_2_NEEDED}.
+ \end{sloppypar}
+ \item[GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_VERSION]
+ \begin{sloppypar}
+ The bit \code{n} in \code{GNU_PROPERTY_1_GLIBC_2_NEEDED} represents
+ the minor version \code{35 + n} of the GNU C library version 2 needed
+ by object file. This macro:
+ \begin{footnotesize}
+ \begin{verbatim}
+#define GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_VERSION(m) \
+ (1U << ((m) - GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_BASE))
+ \end{verbatim}
+ \end{footnotesize}
+ maps the minor version \code{m} to a bit in
+ \code{GNU_PROPERTY_1_GLIBC_2_NEEDED}.
+ Linker should add minor versions of the GNU C library version 2
+ which are set in \code{GNU_PROPERTY_1_GLIBC_2_NEEDED} to the run-time
+ requirements of executables and shared libraries.
+ \end{sloppypar}
+\end{description}
+
\subsection{\code{.note.ABI-tag} section}
\label{sec_abi_tag}