rtld i386 versus amd64

[Dan Lukes]

kron24 wrote:
>> 1) nainstalovat LIB32 set.
>> to by jeste nemelo mit na bezici system naprosto zadny vliv
>
> Zkousel jsem "make install32", coz nefungovalo.

Ten target existuje, takze to je dobry kandidat na "spravne reseni". 
Problem nejspis bude v tom, ze 'install' faze se pokousi pouzit uz 
"novy" make - tedy ten co je prelozeny v /usr/obj

Sice si myslim, ze tam ta logika je dost dobra na to, aby v tomto 
pripade prisla na to, ze ten 64bitovy co tam je nemuze pouzit, ale mozna 
tam je nekde nejaka chybicka.

To je ale, rekneme, drobny detail k doladeni - az/pokud bude zrejme, ze 
"to cele" nema vady zasadni.

Pro instalaci kernelu to plati taky.

>> 3) reboot
>>
>> nyni mame amd64-kerne/i386 world system - mel by byt ovsem normalne
>> funkcni (vcetne portu) - kernel je 64, world je kompletne 32 bitu a 32
>> bitu kernel podporuje, ma tam i potrebne knihovny, vcetne
>> /libexec/ld-elf32.so.1
>
> ... po rebootu je problem s dynamickym linkovanim:
>
> Trying to mount root from ufs:/dev/ad0s1a
> /libexec/ld-elf.so.1: Shared object "libedit.so.7" not found, required
> by "sh"

Jeden problem by tam byt mohl - neni jasne, zda a jakou ma 'ldconfig' 
vnitrni logiku tykajici se architektury. Ja doufal, ze sve chovani meni 
podle toho, an jake architekture (kernelu) je spusten. Je ale mozne, ze 
se chova podle toho, pro jakou architekturu byl prelozen. A protoze v 
teto chvili pouzivame jeste i386/ldconfig, nemusel nam databaze knihoven 
pripravit do spravneho ciloveho stavu (je mozne, ze 64bitove knihovny 
ignoroval a zaznamy o 32 bitovych nedal do souboru, kde maji byt na 
64bitovem systemu lec tam, kam je dava na i386).

Pokud by se tento problem potvrdil, znamemalo by to, ze bud' je treba 
sahnout dovnitr ldconfig a zmenit to, podle ceho urcuje "na cem bezi" 
NEBO nechat ho vytvorit databaze na "spatnem" miste a pak je proste jen 
prekopirovat pod spravne jmeno. Pokud by se ukazalo, ze i386/ldconfig 
nevytvari /var/run/ld-elf32.so.hints tak by to slo udelat dokonce pred 
rebootem - po nabehnuti by na ten soubor uz nesahnul (a ze nam vytvori 
nesmyslny /var/run/ld-elf.so.hints) nevadi, zatim nemame jedinny amd64 
binar.

> Jen tak z legrace jsem se z toho zkusil vyhrabat pomoci rescue:

Jo, v tomto pripade je /rescue/* - protoze to je staticky linkovane, 
naprosto nezbytna vec.

> Jediny na prvni podhled viditelny zadrhel byla routovaci tabulka:
>
> # netstat -rn
> netstat: no namelist
> # /etc/rc.d/routing restart
> route: writing to routing socket: Invalid argument
> add net default: gateway 192.168.235.1: Invalid argument

> - Neznamena ten problem s routovanim, ze nektere "systemove"
> 32bit programy nad 64bit kernelem prece jenom nepojedou?

Skoro to tak vypada. Patrne nektere predavane datove struktury jsou 
"architektonicky variabilni". Otazka je, jestli je to "design" nebo 
"bug". Jadro by melo byt schopno zdetekovat, ze volajici program bezi v 
"compatibility" rezimu a podle toho by melo parsovat predavana data - 
bud' to nedela, nebo je zakopany pes nekde jinde.

> - Jak to, ze ten ldconfig zafunguje jenom "jednorazove"? Jak
> dosahnout preziti rebootu?

To je mi taky divny, ale bez detailnejsiho ladeni - jak se lisi spusteni 
ldconfigu behem startupu a to "rucni" to nedokazu rict.

> - Nebude kvuli tomu linkovani prece jenom nutne hrabnout
> na zdrojaky, jak jsi puvodne zamyslel?

Je to porad otevrena moznost, ale pokud to jde bez zasahu do zdrojaku, 
byl bych radsi. Vlastni zasahy do zdrojaku jsou vzdycky problem a snazim 
se jim maximalne vyhybat. Uz tak jich tam mam jako maku ...

A kdyz uz jsou fakt nutny, tak pokud mozno ne do klicovych komponent - 
jako je jadro nebo prave ld-elf.so.1. To daleko radeji sahnu do kodu 
'ldconfig', coz je sice dulezity, presto vsak v podstate jednorazove 
pouzivany program.

> - Jako workaround me napadlo pouzit staticke programy - do /bin
> a /sbin jsem z /rescue nakopiroval sh, mount a ldconfig. To
> bylo na start systemu prece jen dost malo :-) Muzu pokracovat
> dal a asi bych se dostal k nejake minimalne sade potrebnych
> statickych programu, ale ma tahle cesta smysl?

Prekladem /bin a /sbin s optionem -DNO_SHARED bys mel ziskat kompletni 
statickou sadu zakladnich programu.

Ale ja si nemyslim, ze to pomuze (pominu-li, ze se tak bude lepe ladit, 
protoze proste budes mit k dispozici funkcni programy - zase ale 
nepoznas co by nefungovalo, kdyby byly "normalni").

Vypada to, ze problemy jsou dva - nejak spatne se nam chova ldconfig - 
to bdue v lepsim pripade problem s jeho volanim, v horsim pripade 
problem s jeho vnitrni logikou. A nejake napady jak z toho vybruslit 
jsem popsal nahore. Zmena logiky dynamickeho linkovani nam problem spis 
nevyresi.

Druhy problem je komunikace pres routing-socket, kde se predavaji 
binarni data a asi jsou spatne interpretovana - to je trochu horsi. 
Lepsi varianta je, ze to je nezamysleny bug - bud' ta data nemaji byt 
architekturne zavisla (a chyba je, ze jsou), nebo zavisla byt mohou a 
kernel je ma zavisle interpretovat (a chyba je v teto logice). V takovem 
pripade je treba chybu najit, odreportovat - oni ji do nekolika let do 
kodu vlozi. Do te doby to ja mohu mit jako lokalni "vlastni" patch. 
Takove patche me tolik netrapi. Horsi je, pokud se commiteri rozhodnou, 
z enebylo zamerem dosahnou tohoto typu kompatibility a tudiz nejde o 
bug, ale "by design".

I tak to samozrejem mohu opravit, ale jde o "trvalou diversitu" od 
spolecneho kodu - a tomu se opravdu chci vyhybat. Alespon v jadre.

A uz vybec se mi nechce zanaset trvale potencialni problemy do systemu 
kvuli necemu tak vyjimecnemu jako je i386->amd64 cross upgrade. I kdyby 
to cele fungovalo dokonale - za zivot jich tezko udelam dve stovky. 
Kvuli tomu nebudu riskovat potize, ze nebude fungovat neco, co se 
pouziva rutinne.

Pokdu s eukaze, ze kompatibilita neni cilem, tak by resenim mohl byt 
vlastni 'route' (vznikly upravou ze "standardniho"), ktery by se na 
system nakopiroval pred rebootem - za standardni by byl nahrazen 
pozdeji, v ramci 'installworld'. Uprava by spocivala v tom, z eby datove 
struktury predaval v takovem tvaru, v najem jim dokze amd64 jadro 
rozumet ...

>> Ja sam se ted nebudu pokouset to zkouset a doladit do finalne
>> pouziteneho stavu ...
>
> ... ale jsem ochoten se tomu jeste venovat a jestli me Ty nebo
> nekdo dalsi popostrci, pokusim se k tomu pouzitelnemu stavu
> dostat.

To je spoluprace, ktera mi momentalne vyhovuje. Ja fakt nemam cas si s 
tim ted hrat. Pokud ty cas a naladu mas, zkus se podivat co po tom 
startu vlastne vyrobil ten ldconfig - zda vyrobil jen 
/var/run/ld-elf.so.hints nebo i /var/run/ld-elf32.so.hints - a co do 
nich vlastne dal. To je vec, ktera se na "normalnim" systemu spatrit neda.

Na "route" se podivat muzu - na to nemusim "zparchantet" zadnou masinu, 
to si proste i386/route nakopiruju domu a zkusim to, to zadne velke 
mnozstvi casu nevyzaduje.

Dan