DOKK / manpages / debian 13 / manpages-ro / ld.so.8.ro
ld.so(8) System Manager's Manual ld.so(8)

ld.so, ld-linux.so - editor de legături/încărcător dinamic

Editorul de legături dinamice poate fi rulat fie indirect, prin rularea unui program legat dinamic sau a unui obiect partajat (caz în care nu pot fi transmise opțiuni din linia de comandă către editorul de legături dinamice și, în cazul ELF, este executat editorul de legături dinamice care este stocat în secțiunea .interp a programului), fie direct, prin rularea:

/lib/ld-linux.so.* [OPȚIUNI] [PROGRAM [ARGUMENTE]]

Programele ld.so și ld-linux.so* găsesc și încarcă obiectele partajate (biblioteci partajate) necesare unui program, pregătesc programul pentru execuție și apoi îl execută.

Binarele Linux necesită legare dinamică (legare în timpul execuției), cu excepția cazului în care opțiunea -static a fost dată la ld(1) în timpul compilării.

Programul ld.so gestionează binarele a.out, un format binar utilizat cu mult timp în urmă. Programul ld-linux.so* (/lib/ld-linux.so.1 pentru libc5, /lib/ld-linux.so.2 pentru glibc2) gestionează binarii care sunt în formatul ELF mai modern. Ambele programe au același comportament și utilizează aceleași fișiere și programe de suport (ldd(1), ldconfig(8) și /etc/ld.so.conf).

La rezolvarea dependențelor obiectelor partajate, editorul de legături dinamice inspectează mai întâi fiecare șir de dependențe pentru a vedea dacă acesta conține o bară oblică (acest lucru se poate întâmpla dacă un nume de rută al unui obiect partajat care conține bară oblică a fost specificat la momentul realizării legăturii). Dacă se găsește o bară oblică, atunci șirul de dependență este interpretat ca un nume de rută (relativ sau absolut), iar obiectul partajat este încărcat folosind acel nume de rută.

Dacă o dependență de obiect partajat nu conține o bară oblică, atunci este căutată în următoarea ordine:

(1)
Utilizând directoarele specificate în atributul DT_RPATH al secțiunii dinamice a binarului, dacă este prezent și atributul DT_RUNPATH nu există.
(2)
Utilizând variabila de mediu LD_LIBRARY_PATH, cu excepția cazului în care executabilul este rulat în modul de execuție-securizată (a se vedea mai jos), caz în care această variabilă este ignorată.
(3)
Utilizând directoarele specificate în atributul DT_RUNPATH al secțiunii dinamice a binarului, dacă este prezent. Aceste directoare sunt căutate numai pentru a găsi obiectele solicitate de intrările DT_NEEDED (dependențe directe) și nu se aplică copiilor acelor obiecte, care trebuie să aibă propriile lor intrări DT_RUNPATH. Acest lucru este diferit de DT_RPATH, care se aplică căutărilor pentru toți copiii din arborele de dependențe.
(4)
Din fișierul cache /etc/ld.so.cache, care conține o listă compilată de obiecte partajate candidate găsite anterior în ruta bibliotecii augmentate. Dacă, totuși, binarul a fost legat cu opțiunea editorului de legături -z nodefaultlib, obiectele partajate din rutele implicite sunt ignorate. Obiectele partajate instalate în directoarele de capacități hardware (a se vedea mai jos) sunt preferate altor obiecte partajate.
(5)
În ruta implicită /lib, și apoi /usr/lib; (pe unele arhitecturi pe 64 de biți, rutele implicite pentru obiectele partajate pe 64 de biți sunt /lib64, și apoi /usr/lib64). Dacă binarul a fost legat cu opțiunea editorului de legături -z nodefaultlib, acest pas este sărit.

În numeroase locuri, editorul de legături dinamice extinde simbolurile șirurilor dinamice:

•
În variabilele de mediu LD_LIBRARY_PATH, LD_PRELOAD și LD_AUDIT,
•
în interiorul valorilor etichetelor de secțiune dinamică DT_NEEDED, DT_RPATH, DT_RUNPATH, DT_AUDIT și DT_DEPAUDIT ale binarelor ELF,
•
în argumentele opțiunilor de linie de comandă ld.so --audit, --library-path și --preload (a se vedea mai jos), și
•
în argumentele de nume de fișier pentru funcțiile dlopen(3) și dlmopen(3).

Simbolurile substituite sunt următoarele:

$ORIGIN (sau echivalent ${ORIGIN})
Aceasta se extinde la directorul care conține programul sau obiectul partajat. Astfel, o aplicație localizată în vreun-dir/aplicație ar putea fi compilată cu

gcc -Wl,-rpath,'$ORIGIN/../lib'

astfel încât să găsească un obiect partajat asociat în vreun-dir/bibliotecă indiferent unde se află vreun-dir în ierarhia directoarelor. Acest lucru facilitează crearea de aplicații „la cheie” care nu trebuie să fie instalate în directoare speciale, ci pot fi despachetate în orice director și își pot găsi în continuare propriile obiecte partajate.
$LIB (sau echivalent ${LIB})
Aceasta se extinde la lib sau lib64 în funcție de arhitectură (de exemplu, pe x86-64, se extinde la lib64 și pe x86-32, se extinde la lib).
$PLATFORM (sau echivalent ${PLATFORM})
Acesta se extinde la un șir corespunzător tipului de procesor al sistemului gazdă (de exemplu, „x86_64”). Pe unele arhitecturi, nucleul Linux nu furnizează un șir de platformă pentru editorul de legături dinamice. Valoarea acestui șir este preluată din valoarea AT_PLATFORM din vectorul auxiliar (consultați getauxval(3)).

Rețineți că simbolurile de șir dinamice trebuie să fie citate corespunzător atunci când sunt definite dintr-un shell, pentru a preveni extinderea lor ca variabile de shell sau de mediu.

Stabilește argv[0] la valoarea șir înainte de a rula programul.
Utilizează obiectele numite în listă ca auditori. Obiectele din listă sunt delimitate prin două puncte.
Caută subdirectoare încorporate numai dacă sunt în listă.
Caută subdirectoarele glibc-hwcaps din listă.
Nu utilizează /etc/ld.so.cache.
Utilizează ruta în locul valorii variabilei de mediu LD_LIBRARY_PATH (a se vedea mai jos). Numele ORIGIN, LIB și PLATFORM sunt interpretate ca pentru variabila de mediu LD_LIBRARY_PATH.
Ignoră informațiile RPATH și RUNPATH în numele obiectelor din listă. Această opțiune este ignorată la rularea în modul de execuție securizată (a se vedea mai jos). Obiectele din listă sunt delimitate prin două puncte („:”) sau spații.
Listează toate dependențele și modul în care acestea sunt rezolvate.
Imprimă informații de diagnosticare a sistemului într-un format care poate fi citit de mașină, cum ar fi unele variabile interne ale încărcătorului, vectorul auxiliar (vezi getauxval(3)) și variabilele de mediu. Pe unele arhitecturi, comanda poate afișa informații suplimentare (cum ar fi caracteristicile cpu utilizate în selectarea indirectă a funcțiilor GNU pe x86). --list-tunables (de la glibc 2.33) Imprimă numele și valorile tuturor variabilelor de ajustare, împreună cu valorile minime și maxime permise.
Preîncarcă obiectele specificate în listă. Obiectele din listă sunt delimitate prin două puncte („:”) sau spații. Obiectele sunt preîncărcate după cum se explică în descrierea variabilei de mediu LD_PRELOAD de mai jos.
Spre deosebire de LD_PRELOAD, opțiunea --preload oferă o modalitate de a efectua preîncărcarea pentru un singur executabil fără a afecta preîncărcarea efectuată în orice proces copil care execută un program nou.
Verificați dacă programul este legat dinamic și dacă acest editor de legături dinamice îl poate gestiona.

Diverse variabile de mediu influențează funcționarea editorului de legături dinamice.

Din motive de securitate, în cazul în care editorul de legături dinamice stabilește că un binar ar trebui să fie executat în modul de execuție securizat, efectele anumitor variabile de mediu sunt anulate sau modificate și, în plus, aceste variabile de mediu sunt eliminate din mediu, astfel încât programul nici măcar nu vede definițiile. Unele dintre aceste variabile de mediu afectează funcționarea editorului de legături dinamice în sine și sunt descrise mai jos. Alte variabile de mediu tratate în acest mod includ: GCONV_PATH, GETCONF_DIR, HOSTALIASES, LOCALDOMAIN, LD_AUDIT, LD_DEBUG, LD_DEBUG_OUTPUT, LD_DYNAMIC_WEAK, LD_HWCAP_MASK, LD_LIBRARY_PATH, LD_ORIGIN_PATH, LD_PRELOAD, LD_PROFILE, LD_SHOW_AUXV, LOCALDOMAIN, LOCPATH, MALLOC_TRACE, NIS_PATH, NLSPATH, RESOLV_HOST_CONF, RES_OPTIONS, TMPDIR și TZDIR.

Un binar este executat în modul de execuție-securizată dacă intrarea AT_SECURE din vectorul auxiliar (a se vedea getauxval(3)) are o valoare diferită de zero. Această intrare poate avea o valoare diferită de zero din diverse motive, inclusiv:

•
ID-urile de utilizator reale și efective ale procesului diferă, sau ID-urile de grup reale și efective diferă. Acest lucru se întâmplă de obicei ca urmare a executării unui program set-user-ID sau set-group-ID.
•
Un proces cu un ID de utilizator non-root a executat un binar care a conferit capacități procesului.
•
Este posibil ca o valoare diferită de zero să fi fost definită de un modul de securitate Linux.

Unele dintre cele mai importante variabile de mediu sunt următoarele:

Fiecare obiect partajat poate informa editorul de legături dinamice cu privire la versiunea ABI minimă a nucleului de care are nevoie. (Această cerință este codificată într-o secțiune de notă ELF care poate fi vizualizată prin readelf -n ca o secțiune etichetată NT_GNU_ABI_TAG). În momentul rulării, editorul de legături dinamice determină versiunea ABI a nucleului care rulează și va respinge încărcarea obiectelor partajate care specifică versiuni ABI minime care depășesc acea versiune ABI.
LD_ASSUME_KERNEL poate fi utilizată pentru a determina editorul de legături dinamice să presupună că rulează pe un sistem cu o versiune ABI de nucleu diferită. De exemplu, următoarea linie de comandă determină editorul de legături dinamice să presupună că rulează pe Linux 2.2.5 atunci când încarcă obiectele partajate solicitate de prog-meu:

$ LD_ASSUME_KERNEL=2.2.5 ./prog-meu

Pe sistemele care furnizează mai multe versiuni ale unui obiect partajat (în directoare diferite în ruta de căutare) care au cerințe diferite privind versiunea ABI minimă a nucleului, LD_ASSUME_KERNEL poate fi utilizată pentru a selecta versiunea obiectului care este utilizată (în funcție de ordinea de căutare în directoare).
Din punct de vedere istoric, cea mai frecventă utilizare a caracteristicii LD_ASSUME_KERNEL a fost selectarea manuală a implementării mai vechi a firelor POSIX LinuxThreads pe sistemele care ofereau atât LinuxThreads, cât și NPTL (aceasta din urmă era de obicei opțiunea implicită pe astfel de sisteme); consultați pthreads(7).
Dacă este definită la un șir de caractere nevid, determină editorul de legături dinamice să rezolve toate simbolurile la pornirea programului, în loc să amâne rezolvarea apelurilor de funcții până în momentul în care acestea sunt referite pentru prima dată. Acest lucru este util atunci când se utilizează un depanator.
O listă de directoare în care să se caute biblioteci ELF la momentul execuției. Elementele din listă sunt separate fie prin două puncte, fie prin punct și virgulă, și nu există suport pentru eludarea niciunui separator. Un nume de director de lungime zero indică directorul de lucru curent.
Această variabilă este ignorată în modul de execuție-securizată.
În cadrul numelor de rute specificate în LD_LIBRARY_PATH, editorul de legături dinamice extinde simbolurile $ORIGIN, $LIB și $PLATFORM (sau versiunile care utilizează acolade în jurul numelor) așa cum este descris mai sus în secțiunea Simboluri dinamice de șir. Astfel, de exemplu, următorul text ar face ca o bibliotecă să fie căutată fie în subdirectorul lib, fie în subdirectorul lib64 de sub directorul care conține programul care urmează să fie executat:

$ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog

Observați utilizarea ghilimelelor simple, care împiedică extinderea $ORIGIN și $LIB ca variabile shell!
O listă de obiecte partajate ELF suplimentare, specificate de utilizator, care urmează să fie încărcate înaintea tuturor celorlalte. Această caracteristică poate fi utilizată pentru a suprascrie selectiv funcții din alte obiecte partajate.
Elementele din listă pot fi separate prin spații sau două puncte și nu există suport pentru eludarea niciunui separator. Obiectele sunt căutate folosind regulile prezentate în secțiunea DESCRIERE. Obiectele sunt căutate și adăugate la tabelul de legături în ordinea de la stânga la dreapta specificată în listă.
În modul de execuție securizată, numele de rute de preîncărcare care conțin bare oblice (slashes) sunt ignorate. În plus, obiectele partajate sunt preîncărcate numai din directoarele de căutare standard și numai dacă bitul de mod set-user-ID este activat (ceea ce nu este tipic).
În cadrul numelor specificate în lista LD_PRELOAD, editorul de legături dinamice înțelege simbolurile $ORIGIN, $LIB și $PLATFORM (sau versiunile care utilizează acolade în jurul numelor), astfel cum sunt descrise mai sus în Simboluri dinamice de șir; (a se vedea, de asemenea, discuția despre punerea între ghilimele în cadrul descrierii lui LD_LIBRARY_PATH).
Există diferite metode de specificare a bibliotecilor care urmează să fie preîncărcate, iar acestea sunt tratate în următoarea ordine:
(1)
Variabila de mediu LD_PRELOAD.
(2)
Opțiunea de linie de comandă --preload la apelarea directă a editorului de legături dinamice.
(3)
Fișierul /etc/ld.so.preload (descris mai jos).
Dacă este definită (la orice valoare), face ca programul să își listeze dependențele dinamice, ca și cum ar fi rulat de ldd(1), în loc să ruleze normal.

Apoi, există o mulțime de variabile mai mult sau mai puțin obscure, multe învechite sau doar pentru uz intern.

O listă de obiecte ELF partajate, specificate de utilizator, care urmează să fie încărcate înaintea tuturor celorlalte într-un spațiu de nume separat al editorului de legături (de exemplu, unul care nu intervine în legăturile normale de simboluri care ar apărea în proces) Aceste obiecte pot fi utilizate pentru a verifica funcționarea editorului de legături dinamice. Elementele din listă sunt separate prin două puncte și nu există suport pentru eludarea separatorului.
LD_AUDIT este ignorată în modul de execuție-securizată.
Editorul de legături dinamice va notifica obiectele partajate de audit la așa-numitele puncte de control de audit - de exemplu, încărcarea unui nou obiect partajat, rezolvarea unui simbol sau apelarea unui simbol dintr-un alt obiect partajat - prin apelarea unei funcții corespunzătoare în cadrul obiectului partajat de audit. Pentru detalii, consultați rtld-audit(7). Interfața de audit este în mare parte compatibilă cu cea furnizată pe Solaris, așa cum este descrisă în Linker and Libraries Guide, în capitolul Runtime Linker Auditing Interface.
În cadrul numelor specificate în lista LD_AUDIT, editorul dinamic înțelege simbolurile $ORIGIN, $LIB și $PLATFORM (sau versiunile care utilizează acolade în jurul numelor), astfel cum sunt descrise mai sus în Simboluri de șir dinamice; (a se vedea, de asemenea, discuția despre punerea între ghilimele în cadrul descrierii lui LD_LIBRARY_PATH).
Începând cu glibc 2.13, în modul de execuție securizată, numele din lista de audit care conțin bare oblice sunt ignorate și sunt încărcate numai obiectele partajate din directoarele de căutare standard care au bitul de mod set-user-ID activat.
Dacă această variabilă de mediu este stabilită la un șir nevid, nu se actualizează GOT („global offset table”, tabelul de poziții globale) și PLT („procedure linkage table”, tabelul de legături al procedurilor) după rezolvarea unui simbol de funcție. Prin combinarea utilizării acestei variabile cu LD_DEBUG (cu categoriile bindings și symbols), se pot observa toate legăturile de funcții în timpul execuției.
Afișează informații de depanare detaliate despre funcționarea editorului de legături dinamice. Conținutul acestei variabile este una sau mai multe dintre următoarele categorii, separate prin două puncte, virgule sau (dacă valoarea este între ghilimele) spații:
Specificând help în valoarea acestei variabile nu se execută programul specificat și se afișează un mesaj de ajutor despre categoriile care pot fi specificate în această variabilă de mediu.
Imprimă toate informațiile de depanare (cu excepția statistics și unused; a se vedea mai jos).
Afișează informații despre definiția la care este legat fiecare simbol.
Afișează progresul pentru fișierul de intrare.
Afișează rutele de căutare a bibliotecii.
Afișează procesarea realocării.
Afișează informații despre domeniul de aplicare.
Afișează statisticile privind realocarea.
Afișați rutele de căutare pentru fiecare simbol căutat.
Determină DSO-urile neutilizate.
Afișează dependențele de versiune.
Începând cu glibc 2.3.4, LD_DEBUG este ignorată în modul de execuție-securizată, cu excepția cazului în care există fișierul /etc/suid-debug (conținutul fișierului este irelevant).
În mod implicit, rezultatul LD_DEBUG este scris la ieșirea de eroare standard. Dacă LD_DEBUG_OUTPUT este definită, atunci rezultatul este scris în numele de rută specificat de valoarea sa, cu sufixul „.” (punct) urmat de ID-ul procesului anexat la numele de rută.
LD_DEBUG_OUTPUT este ignorată în modul de execuție-securizată.
În mod implicit, atunci când caută în bibliotecile partajate pentru a rezolva o referință de simbol, editorul de legături dinamice va rezolva la prima definiție pe care o găsește.
Versiunile vechi ale glibc (înainte de glibc 2.2) aveau un comportament diferit: dacă editorul de legături găsea un simbol slab, acesta reținea acel simbol și continua să caute în bibliotecile partajate rămase. Dacă, ulterior, se găsea o definiție puternică a aceluiași simbol, atunci se folosea în schimb acea definiție; (dacă nu mai găsește niciun alt simbol, atunci editorul de legături dinamice utilizează simbolul slab pe care l-a găsit inițial).
Comportamentul vechi al glibc nu era standard; (practica standard este că distincția dintre simbolurile slabe și puternice ar trebui să aibă efect numai la momentul legăturii statice). În glibc 2.2, editorul de legături dinamice a fost modificat pentru a oferi comportamentul actual (care era comportamentul oferit de majoritatea celorlalte implementări la acel moment).
Definirea variabilei de mediu LD_DYNAMIC_WEAK (cu orice valoare) oferă vechiul comportament (nestandardizat) al glibc, prin care un simbol slab dintr-o bibliotecă partajată poate fi anulat de un simbol puternic descoperit ulterior într-o altă bibliotecă partajată. Rețineți că, chiar și atunci când această variabilă este definită, un simbol puternic dintr-o bibliotecă partajată nu va trece peste o definiție slabă a aceluiași simbol din programul principal.
Începând cu glibc 2.3.4, LD_DYNAMIC_WEAK este ignorată în modul de execuție-securizată.
Mască pentru capacitățile hardware. Începând cu glibc 2.26, opțiunea poate fi ignorată dacă glibc nu acceptă „tunables” (ajustări).
Ruta în care se găsește binarul.
Începând cu glibc 2.4, LD_ORIGIN_PATH este ignorată în modul de execuție-securizată.
Stabiliți valoarea 0 pentru a dezactiva protecția indicatorului. Orice altă valoare activează protecția indicatorilor, care este și valoarea implicită. Protejarea indicatorilor este un mecanism de securitate prin care unii indicatori de cod stocați în memoria programului în care se poate scrie (adresele de retur salvate de setjmp(3) sau indicatorii de funcție utilizați de diverse funcții interne ale glibc) sunt modificați în mod semialeatoriu pentru a face mai dificil pentru un atacator să deturneze indicatorii pentru a fi utilizați în cazul unui atac de tip „buffer overrun” (debordarea memoriei tampon) sau „stack-smashing” (zdrobirea stivelor). Începând cu glibc 2.23, LD_POINTER_GUARD nu mai poate fi utilizat pentru a dezactiva protecția pointerilor, care este acum întotdeauna activată.
Numele unui (singur) obiect partajat care urmează să fie profilat, specificat fie ca nume de rută, fie ca un soname. Rezultatul profilării este anexat la fișierul al cărui nume este: $LD_PROFILE_OUTPUT/$LD_PROFILE.profile.
Începând cu glibc 2.2.5, LD_PROFILE utilizează o rută implicită diferită în modul de execuție-securizată.
Directorul în care ar trebui să fie scrisă ieșirea LD_PROFILE. Dacă această variabilă nu este definită sau este definită ca un șir gol, atunci valoarea implicită este /var/tmp.
LD_PROFILE_OUTPUT este ignorată în modul de execuție-securizată; în schimb, /var/profile este utilizat întotdeauna.
Dacă această variabilă de mediu este definită (cu orice valoare), se afișează matricea auxiliară transmisă de nucleu (a se vedea și getauxval(3)).
Începând cu glibc 2.3.4, LD_SHOW_AUXV este ignorată în modul de execuție-securizată.
Dacă această variabilă de mediu este definită, urmărește pre-legătura obiectului al cărui nume este atribuit acestei variabile de mediu; (utilizați ldd(1) pentru a obține o listă a obiectelor care pot fi urmărite). Dacă numele obiectului nu este recunoscut, atunci este urmărită toată activitatea de pre-legare.
În mod implicit (și anume, dacă această variabilă nu este definită), executabilele și obiectele partajate pre-legate vor onora adresele de bază ale obiectelor partajate dependente, iar executabilele (ne=pre-legate) independente de poziție (PIE) și alte obiecte partajate nu le vor onora. Dacă LD_USE_LOAD_BIAS este definită cu valoarea 1, atât executabilele, cât și PIE-urile vor onora adresele de bază. Dacă LD_USE_LOAD_BIAS este definită cu valoarea 0, nici executabilele, nici PIE-urile nu vor respecta adresele de bază.
Începând cu glibc 2.3.3, această variabilă este ignorată în modul de execuție-securizată.
Dacă este definită la un șir de caractere nevid, furnizează informații despre versiunile simbolurilor despre program dacă a fost definită variabila de mediu LD_TRACE_LOADED_OBJECTS.
Dacă este definită la un șir nevid, avertizează cu privire la simbolurile nerezolvate.
Conform ghidului de optimizare a software-ului Intel Silvermont, pentru aplicațiile pe 64 de biți, performanța de predicție a ramificării poate fi afectată negativ atunci când ținta unei ramificări se află la o distanță mai mare de 4 Go de ramificare. Dacă această variabilă de mediu este definită (la orice valoare), editorul de legături dinamice va încerca mai întâi să cartografieze paginile executabile utilizând fanionul mmap(2) MAP_32BIT și va reveni la cartografierea fără acest fanion dacă încercarea eșuează. NB: MAP_32BIT va face cartografierea către cei 2 Go (nu 4 Go) ai spațiului de adrese.
Deoarece MAP_32BIT reduce intervalul de adrese disponibil pentru generarea aleatorie a spațiului de adrese (ASLR), LD_PREFER_MAP_32BIT_EXEC este întotdeauna dezactivat în modul de execuție-securizată.

/lib/ld.so
editor de legături/încărcător dinamic a.out
/lib/ld-linux.so.{1,2}
editor de legături/încărcător dinamic ELF
/etc/ld.so.cache
Fișier care conține o listă compilată de directoare în care să se caute obiecte partajate și o listă ordonată de obiecte partajate candidate. A se vedea ldconfig(8).
/etc/ld.so.preload
Fișier care conține o listă separată prin spații albe de obiecte partajate ELF care urmează să fie încărcate înainte de program. A se vedea discuția de mai sus despre LD_PRELOAD. Dacă sunt utilizate atât LD_PRELOAD, cât și /etc/ld.so.preload, bibliotecile specificate de LD_PRELOAD sunt preîncărcate primele. /etc/ld.so.preload are un efect la nivelul întregului sistem, făcând ca bibliotecile specificate să fie preîncărcate pentru toate programele care sunt executate pe sistem; (acest lucru este de obicei nedorit și este utilizat de obicei numai ca remediu de urgență, de exemplu, ca o soluție temporară la o problemă de configurare greșită a bibliotecilor).

Translated with DeepL.com (free version)

Obiecte partajate

Capacități Hardware vechi (de la glibc 2.5 la glibc 2.37)

Unele obiecte partajate sunt compilate folosind instrucțiuni specifice hardware care nu există pe fiecare CPU. Astfel de obiecte trebuie instalate în directoare ale căror nume definesc capacitățile hardware necesare, cum ar fi /usr/lib/sse2/. Editorul de legături dinamice verifică aceste directoare în funcție de hardware-ul mașinii și selectează cea mai adecvată versiune a unui anumit obiect partajat. Directoarele de capacități hardware pot fi puse în cascadă pentru a combina caracteristicile CPU. Lista de nume de capacități hardware acceptate depinde de CPU. În prezent, sunt recunoscute următoarele nume:

ev4, ev5, ev56, ev6, ev67
loongson2e, loongson2f, octeon, octeon2
4xxmac, altivec, arch_2_05, arch_2_06, booke, cellbe, dfp, efpdouble, efpsingle, fpu, ic_snoop, mmu, notb, pa6t, power4, power5, power5+, power6x, ppc32, ppc601, ppc64, smt, spe, ucache, vsx
flush, muldiv, stbar, swap, ultra3, v9, v9v, v9v2
dfp, eimm, esan3, etf3enh, g5, highgprs, hpage, ldisp, msa, stfle, z900, z990, z9-109, z10, zarch
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

Suportul capacităților hardware vechi are dezavantajul că fiecare caracteristică nouă adăugată mărește exponențial ruta de căutare, deoarece trebuie să fie adăugată la fiecare combinație a celorlalte caracteristici existente.

De exemplu, pe x86 pe 32 de biți, dacă hardware-ul acceptă i686 și sse2, ruta de căutare rezultată va fi i686/sse2:i686:sse2:.. O nouă capacitate newcap va defini ruta de căutare la newcap/i686/sse2:newcap/i686:newcap/sse2:newcap:i686/sse2:i686:sse2:.

Capacități hardware glibc (de la glibc 2.33)

în care, în cadrul fiecărei arhitecturi de procesor, pot fi definite anumite niveluri, care grupează suportul pentru anumite caracteristici sau instrucțiuni speciale. Fiecare nivel de arhitectură are un set fix de rute pe care le adaugă la lista de căutare a editorului de legături dinamice, în funcție de hardware-ul mașinii. Deoarece fiecare nou nivel de arhitectură nu este combinat cu cele existente anterior, noua schemă nu are dezavantajul creșterii necontrolate a listei de căutare a editorului de legături dinamice.

De exemplu, pe x86 pe 64 de biți, dacă hardware-ul acceptă x86_64-v3 (de exemplu Intel Haswell sau AMD Excavator), ruta de căutare rezultată va fi glibc-hwcaps/x86-64-v3:glibc-hwcaps/x86-64-v2:. Următoarele rute sunt acceptate în prezent, în ordinea priorităților.

power10, power9
z16, z15, z14, z13
x86-64-v4, x86-64-v3, x86-64-v2

glibc 2.37 a eliminat suportul pentru capacitățile hardware moștenite(învechite).

ld(1), ldd(1), pldd(1), sprof(1), dlopen(3), getauxval(3), elf(5), capabilities(7), rtld-audit(7), ldconfig(8), sln(8)

Traducerea în limba română a acestui manual a fost făcută de Remus-Gabriel Chelu <remusgabriel.chelu@disroot.org>

Această traducere este documentație gratuită; citiți Licența publică generală GNU Versiunea 3 sau o versiune ulterioară cu privire la condiții privind drepturile de autor. NU se asumă NICIO RESPONSABILITATE.

Dacă găsiți erori în traducerea acestui manual, vă rugăm să trimiteți un e-mail la translation-team-ro@lists.sourceforge.net.

8 mai 2024 Pagini de manual de Linux 6.9.1