Provided by: manpages-ro_4.27.0-1_all 
NUME
ld.so, ld-linux.so - editor de legături/încărcător dinamic
SINOPSIS
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]]
DESCRIERE
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.
Simboluri dinamice de șir
Î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.
OPȚIUNI
--argv0 șir (începând cu glibc 2.33)
Stabilește argv[0] la valoarea șir înainte de a rula programul.
--audit listă
Utilizează obiectele numite în listă ca auditori. Obiectele din listă sunt delimitate prin două
puncte.
--glibc-hwcaps-mask listă
Caută subdirectoare încorporate numai dacă sunt în listă.
--glibc-hwcaps-prepend listă
Caută subdirectoarele glibc-hwcaps din listă.
--inhibit-cache
Nu utilizează /etc/ld.so.cache.
--library-path ruta
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.
--inhibit-rpath listă
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.
--list Listează toate dependențele și modul în care acestea sunt rezolvate.
--list-diagnostics (începând cu glibc 2.33)
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.
--preload list (începând cu glibc 2.30)
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.
--verify
Verificați dacă programul este legat dinamic și dacă acest editor de legături dinamice îl poate
gestiona.
MEDIU
Diverse variabile de mediu influențează funcționarea editorului de legături dinamice.
Modul de „execuție securizată”
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.
Variabile de mediu
Unele dintre cele mai importante variabile de mediu sunt următoarele:
LD_ASSUME_KERNEL (de la glibc 2.2.3 la glibc 2.36)
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).
LD_BIND_NOW (începând cu glibc 2.1.1)
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.
LD_LIBRARY_PATH
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!
LD_PRELOAD
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).
LD_TRACE_LOADED_OBJECTS
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.
LD_AUDIT (începând cu glibc 2.4)
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.
LD_BIND_NOT (începând cu glibc 2.1.95)
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.
LD_DEBUG (începând cu glibc 2.1)
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:
help 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.
all Imprimă toate informațiile de depanare (cu excepția statistics și unused; a se vedea
mai jos).
bindings Afișează informații despre definiția la care este legat fiecare simbol.
files Afișează progresul pentru fișierul de intrare.
libs Afișează rutele de căutare a bibliotecii.
reloc Afișează procesarea realocării.
scopes Afișează informații despre domeniul de aplicare.
statistics Afișează statisticile privind realocarea.
symbols Afișați rutele de căutare pentru fiecare simbol căutat.
unused Determină DSO-urile neutilizate.
versions 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).
LD_DEBUG_OUTPUT (începând cu glibc 2.1)
Î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ă.
LD_DYNAMIC_WEAK (începând cu glibc 2.1.91)
Î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ă.
LD_HWCAP_MASK (de la glibc 2.1la glibc 2.38)
Mască pentru capacitățile hardware. Începând cu glibc 2.26, opțiunea poate fi ignorată dacă glibc
nu acceptă „tunables” (ajustări).
LD_ORIGIN_PATH (începând cu glibc 2.1)
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ă.
LD_POINTER_GUARD (de la glibc 2.4 la glibc 2.22)
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ă.
LD_PROFILE (începând cu glibc 2.1)
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ă.
LD_PROFILE_OUTPUT (începând cu glibc 2.1)
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.
LD_SHOW_AUXV (începând cu glibc 2.1)
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ă.
LD_TRACE_PRELINKING (de la glibc 2.4 la glibc 2.35)
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.
LD_USE_LOAD_BIAS (de la glibc 2.3.3 la glibc 2.35)
Î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ă.
LD_VERBOSE (începând cu glibc 2.1)
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.
LD_WARN (începând cu glibc 2.1.3)
Dacă este definită la un șir nevid, avertizează cu privire la simbolurile nerezolvate.
LD_PREFER_MAP_32BIT_EXEC (doar x86-64; începând cu glibc 2.23)
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ă.
FIȘIERE
/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)
lib*.so*
Obiecte partajate
NOTE
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:
Alpha ev4, ev5, ev56, ev6, ev67
MIPS loongson2e, loongson2f, octeon, octeon2
PowerPC
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
SPARC flush, muldiv, stbar, swap, ultra3, v9, v9v, v9v2
s390 dfp, eimm, esan3, etf3enh, g5, highgprs, hpage, ldisp, msa, stfle, z900, z990, z9-109, z10, zarch
x86 (doar 32-biți)
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)
glibc 2.33 a adăugat o nouă schemă de capacități hardware,
î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.
PowerPC (numai little-endian pe 64 de biți)
power10, power9
s390 (doar 64-bți)
z16, z15, z14, z13
x86 (doar 64-biți)
x86-64-v4, x86-64-v3, x86-64-v2
glibc 2.37 a eliminat suportul pentru capacitățile hardware moștenite(învechite).
CONSULTAȚI ȘI
ld(1), ldd(1), pldd(1), sprof(1), dlopen(3), getauxval(3), elf(5), capabilities(7), rtld-audit(7),
ldconfig(8), sln(8)
TRADUCERE
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.
Pagini de manual de Linux 6.9.1 8 mai 2024 ld.so(8)