On 19/10/23 10:03, Alejandro Colomar wrote: > Hi Adhemerval, > > On Thu, Oct 19, 2023 at 09:31:39AM -0300, Adhemerval Zanella wrote: >> It was added on glibc 2.33 as a way to improve path search, since >> legacy hardware capabilities combination scheme do not scale >> properly with new hardware support. The legacy support was removed >> on glibc 2.37, so it is the only scheme currently supported. >> >> Signed-off-by: Adhemerval Zanella <adhemerval.zanella@xxxxxxxxxx> >> --- >> man8/ld.so.8 | 48 +++++++++++++++++++++++++++++++++++++++++++++++- >> 1 file changed, 47 insertions(+), 1 deletion(-) >> >> diff --git a/man8/ld.so.8 b/man8/ld.so.8 >> index cf03cb85e..3025da861 100644 >> --- a/man8/ld.so.8 >> +++ b/man8/ld.so.8 >> @@ -208,6 +208,14 @@ The objects in >> .I list >> are delimited by colons. >> .TP >> +.BI \-\-glibc-hwcaps-mask " list" >> +only search built-in subdirectories if in >> +.IR list . >> +.TP >> +.BI \-\-glibc-hwcaps-prepend " list" >> +Search glibc-hwcaps subdirectories in >> +.IR list . >> +.TP >> .B \-\-inhibit\-cache >> Do not use >> .IR /etc/ld.so.cache . >> @@ -808,7 +816,7 @@ as a temporary workaround to a library misconfiguration issue.) >> .I lib*.so* >> shared objects >> .SH NOTES >> -.SS Hardware capabilities >> +.SS Legacy Hardware capabilities (from glibc 2.5 to glibc 2.37) >> Some shared objects are compiled using hardware-specific instructions which do >> not exist on every CPU. >> Such objects should be installed in directories whose names define the >> @@ -843,6 +851,44 @@ z900, z990, z9-109, z10, zarch >> .B x86 (32-bit only) >> acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386, i486, i586, i686, mca, mmx, >> mtrr, pat, pbe, pge, pn, pse36, sep, ss, sse, sse2, tm >> +.SS glibc Hardware capabilities (from glibc 2.33) >> +The legacy hardware capabilities combinations has the drawback where each >> +feature name incur in cascading extra paths added on the search path list, > > Use semantic newlines: > > The legacy hardware capabilities combinations has the drawback where > each feature name incur in > cascading extra paths added on the search path list Right, I am still getting hold on this scheme. I will send a newer version based on your suggestions. > >> +adding a lot of overhead on >> +.B ld.so >> +during library resolution. >> +For instance, on x86 32-bit, if the hardware >> +supports >> +.B i686 >> +and >> +.B sse2 > > .BR sse2 , > > Otherwise, you'll see a space after the comma. BR alternates bold and > roman for its arguments, and puts them together without spaces. > >> +, the resulting search path will be >> +.B >> +i686/sse2:i686:sse2:. . > > .BR i686/sse2:i686:sse2:. . > >> +A new capability >> +.B newcap >> +will set the search path to >> +.B >> +newcap/i686/sse2:newcap/i686:newcap/sse2:newcap:i686/sse2:i686:sse2: . > > .BR newcap/i686/sse2:newcap/i686:newcap/sse2:newcap:i686/sse2:i686:sse2: . > >> + > > .PP > >> +glibc 2.33 added a new hardware capability scheme, where each ABI can define > > s/, /,\n/ > >> +a set of paths based on expected hardware support. >> +Each path is added depending of the hardware of the machine, and they are not > > s/, /,\n/ > >> +combined together. >> +They also have priority over the legacy hardware capabilities. The following > > s/\. /\.\n/ > > Cheers, > Alex > >> +paths are currently supported. >> +.TP >> +.B PowerPC (64-bit little-endian only) >> +power9, power10 >> +.TP >> +.B s390 (64-bit only) >> +z13, z14, z15, z16 >> +.TP >> +.B x86 (64-bit only) >> +x86-64-v2, x86-64-v3, x86-64-v4 >> +.PP >> +The glibc 2.37 removed support for the legacy hardware capabilities. >> +. >> .SH SEE ALSO >> .BR ld (1), >> .BR ldd (1), >> -- >> 2.34.1 >> >
