* Jan Beulich: > On 21.07.2020 20:04, Florian Weimer wrote: >> * Premachandra Mallappa: >> >>> [AMD Public Use] >>> >>> Hi Floarian, >>> >>>> I'm including a proposal for the levels below. I use single letters for >>>> them, but I expect that the concrete implementation of this proposal will >>>> use >>>> names like “x86-100”, “x86-101”, like in the glibc patch referenced above. >>>> (But we can discuss other approaches.) >>> >>> Personally I am not a big fan of this, for 2 reasons >>> 1. uses just x86 in name on x86_64 as well >> >> That's deliberate, so that we can use the same x86-* names for 32-bit >> library selection (once we define matching micro-architecture levels >> there). > > While indeed I did understand it to be deliberate, in the light of > 64-bit only ISA extensions (like AMX, and I suspect we're going to > see more) I nevertheless think Premachandra has a point here.
Let me explain how I ended up there. Maybe I'm wrong. Previously, I observed that it is difficult to set LD_PRELOAD and LD_LIBRARY_PATH on combined x86-64/i386 systems, so that the right libraries are loaded for both variants, and users aren't confused by dynamic linker warning messages. On some systems, it is possible to use dynamic string tokens ($LIB), but not all. Eventually, it will be possible to add and restrict glibc-hwcaps subdirectories by setting an environment variable. The original patch series only contains ld.so command line options because I wanted to avoid a discussion about the precise mechanism for setting the environment variable (current glibc has two approaches). But the desire to provide this functionality is there: for adding additional glibc-hwcaps subdirectories to be searched first, and for restricting selection to a subset of the built-in (automatically-selected) subdirectories. I was worried that we would run into the same problem as with LD_PRELOAD, where x86-64 and i386 binaries may have different requirements. I wanted to minimize the conflict by sharing the names (eventually, once we have 32-bit variants). But thinking about this again, I'm not sure if my worry is warranted. The main selection criteria is still the library load path, and that is already provided by some different means (e.g. $LIB). Within the library path, there is the glibc-hwcaps subdirectory, but since it is nested under a specific library path subdirectory (determined by the architecture), adding subdirectories to be searched which do not exist on the file system, or surpressing directories which would not be searched in the first place, is not a problem. The situation is completely benign and would not warrant any error message from the dynamic loader. If this analysis is correct, there is no reason to share the subdirectory names between x86-64 and i386 binaries, and we can put “64” somewhere in the x86-64 strings. The remaining issue is the - vs _ issue. I think GCC currently uses “x86-64” in places that are not part of identifiers or target triplets. Richard mentioned “x86_64-” as a potential choice. Would it be too awkward to have ”-march=x86_64-…”? Thanks, Florian
