Hi and sorry to jump in so late in the discussion, On Thu, Oct 19, 2023 at 8:23 PM Adhemerval Zanella <adhemerval.zanella@xxxxxxxxxx> 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. I would suggest (caveat: non-native English speaker here): s/It was added on glibc/The feature was added in glibc/ s/improve path search/improve the path search/ s/since legacy/since the legacy/ s/hardware capabilities combination scheme do not/hardware capabilities scheme does not/ s/was removed on glibc/was removed in glibc/ > > 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..5b02ae88f 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, IMO, this part could use some rephrasing. How about: The legacy hardware capabilities support has the drawback that each feature grows the number of paths added to the search list. Also, maybe this would better fit under the legacy capabilities section? > +adding a lot of overhead on I think "adding a lot of overhead to" sounds better here. "Adding to" instead of "adding on". > +.B ld.so > +during library resolution. > +For instance, on x86 32-bit, if the hardware > +supports > +.B i686 > +and > +.BR sse2 > +, the resulting search path will be > +.BR i686/sse2:i686:sse2:. . > +A new capability > +.B newcap > +will set the search path to > +.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 Maybe s/each ABI/each ABI version/? I'm not familiar with the feature, just guessing from the examples below; they were very helpful, IMO. > +a set of paths based on expected hardware support. a set of paths where to find the expected hardware support? This is based on how I (mis)understood the feature, though, if that's wrong, then the above might also be wrong. I guess the x86-64 glibc would install the x86-64-v2, -v3 and -v4 directories on disk; when running a program, glibc can then check what the current CPU supports - say if it supports x86-64-v3, it loads the contents of that folder? > +Each path is added depending of the hardware of the machine, > +and they are not combined together. > +They also have priority over the legacy hardware capabilities. > +The following 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. s/The glibc/glibc Regards, Stefan. > +. > .SH SEE ALSO > .BR ld (1), > .BR ldd (1), > -- > 2.34.1 >
