Dynamisk innlasting (.so/.dll); hva er trygt?

[Ernie]

Hei!

 

Har lett litt rundt-omkring på nettet etter hva som faktisk er trygt og ikke trygt å laste over et dynamisk interface (.so/.dll) i C++. Sett at man har et plugin-system hvor man ikke benytter samme kompilator for exe og dll. Hva kan man faktisk lene seg tilbake på? Jeg har en antagelse om at exception og templates er no-go. Samtidig har jeg sett at shared_ptr påståes å være trygt, men bruker ikke den template i bakgrunnen? STL generelt er jo beryktet for å være no-go over et dynamisk interface, men det er jo forsåvidt pga. ulik implementasjon ABI-messig.

 

Noen som har litt mer håndfast info om det her, eller ev. veit hvor sånt finnes?

 

Sitter forøvirg primært i linux, så hva som er trygt/ikke trygt i windows er av mindre interesse forsåvidt.

Endret 23. april 2012 av Ernie

[GeirGrusom]

Det er ingenting som er trygt å laste over et dynamisk interface. Det er derimot en funksjonalitet som ofte er veldig nyttig.

Etter det jeg vet er det ikke spesielle problemer med å benytte templates i seg selv. Eneste som er viktig er vel at ABI er likt på begge sider.

[zotbar1234]

Har lett litt rundt-omkring på nettet etter hva som faktisk er trygt og ikke trygt å laste over et dynamisk interface (.so/.dll) i C++.

 

Er spørsmålet rent teoretisk eller praktisk?

 

Men uansett, et greit startpunkt er muligens Eli sin artikkel?

[Ernie]

Det er ingenting som er trygt å laste over et dynamisk interface. Det er derimot en funksjonalitet som ofte er veldig nyttig.

Etter det jeg vet er det ikke spesielle problemer med å benytte templates i seg selv. Eneste som er viktig er vel at ABI er likt på begge sider.

Ja, at ABIet er likt er jo en forutsetning, ellers vil det jo fort bli mildt sagt kompliserte krasj ut av det. Det ser jo ut som templater under tvil kan være trygt. Eksportering av de skal visst hjelpe på.

 

Har lett litt rundt-omkring på nettet etter hva som faktisk er trygt og ikke trygt å laste over et dynamisk interface (.so/.dll) i C++.

 

Er spørsmålet rent teoretisk eller praktisk?

 

Men uansett, et greit startpunkt er muligens Eli sin artikkel?

Pr. nå er det i grunn halveis teoretisk i den forstand at både program og plugin-er blir kompilert av samme kompilator, ergo er det ikke ABI-forskjeller etc. og ting fungerer. Derimot er det ikke så skrekkelig interessant i lengden å være bundet opp til en og samme kompilator (spesielt i forhold til versjoner av kompilatorer). Det finnes såklart flere løsninger på det, som embedded skriptspråk, kjøre ting i individuelle prosesser (noe ala sandkassen i Google Chrome) eller virkelig snøre igjen muligheten i .so/.dll-overgangen.

 

Forsåvidt er det bare en måte å virkelig finne ut av det her. Teste det ut og i verstefall rekompilere med eksakt samme kompilator når det krasjer stygt og hardt. Det kan til en viss grad fungere, men en alternativ løsning er nok nødvendig uansett. Plugin i sandkasse er jo i og for seg fristende.

[GeirGrusom]

Du kan ikke eksportere templates, så det er jo ikke akkurat aktuelt uansett.

[Gjest Slettet+9871234]

Har lett litt rundt-omkring på nettet etter hva som faktisk er trygt og ikke trygt å laste over et dynamisk interface (.so/.dll) i C++.

Du mener vel i det ferdige programmet. Generelt er et program ikke sikrere enn kunnskapene til den som har programmert det.

 

Sett at man har et plugin-system hvor man ikke benytter samme kompilator for exe og dll.

Hvorfor er det bedre enn å bruke samme kompilator?

 

En template er jo bare en mal. For eksempel multiplikasjon. Dersom templatet (via overloading) skal dekke multiplikasjon av alle kjente objekter som ints, floats, komplekse tall, matriser, tensorer og ukjente objekter hvor multiplikasjon er veldefinert, åpner det selvsagt for flere feilkilder. Men i bunn å grunn avhenger det av den som programmerer.

 

Unntaks og feilhåndtering blir derfor svært viktig. Under testing finner man ikke alle grensetilfeller og hjørner om koden er generisk og generell.

Endret 23. april 2012 av Slettet+9871234

[Ernie]

Du kan ikke eksportere templates, så det er jo ikke akkurat aktuelt uansett.

Nei, ikke template-en i seg selv, men utgaven av den virker det som. Har ikke fått sett så nøye på det enda, men det er visst noen som påstår at det er null problem å eksportere myTemplateClass<int> ut nærmest som en forward declaration.

 

Har lett litt rundt-omkring på nettet etter hva som faktisk er trygt og ikke trygt å laste over et dynamisk interface (.so/.dll) i C++.

Du mener vel i det ferdige programmet. Generelt er et program ikke sikrere enn kunnskapene til den som har programmert det.

Mulig jeg har uttrykt meg uklart, men det jeg tenker på er hvilken funksjonalitet i C++-språket man faktisk kan overføre dynamisk til/fra en .so/.dll. Både kjørbar fil og .so/.dll er da skrevet i C++.

 

 

Sett at man har et plugin-system hvor man ikke benytter samme kompilator for exe og dll.

Hvorfor er det bedre enn å bruke samme kompilator?

• Individuell frihet i forhold til hver enkelt .so/.dll.
  
• Slippe å rekompilere store programmer bare fordi noe i kompilatoren endres
  
• Forutsetter at alle har kildekoden, og det er ikke nødvendigvis tilfellet
  

Sikkert flere grunner også uten at jeg kommer på de midt på natta. Uansett, burde ikke et plugin-system takle at ikke alle benytter eksakt samme kompilator ned til versjon og tildeles innstillinger?

 

En template er jo bare en mal. For eksempel multiplikasjon. Dersom templatet (via overloading) skal dekke multiplikasjon av alle kjente objekter som ints, floats, komplekse tall, matriser, tensorer og ukjente objekter hvor multiplikasjon er veldefinert, åpner det selvsagt for flere feilkilder. Men i bunn å grunn avhenger det av den som programmerer.

Akkurat det å dekke templater med enhver type er nok direkte uaktuelt. Det må være noe fastsatt, ellers ber man bare i grunn om feil. Dvs. å eksponere en funksjon, klasse e.l. som tar hva som helst inn som argument er no-go, men derimot er det kjekt å kunne eksponere enkeltutgaver, altså si man tar inn en vector<int> et sted og en vector<float> et annet sted.

[GeirGrusom]

Hvis du eksporterer templates må du sørge for at kompilatoren faktisk bygger dem, men ellers går det greit. Visstnok i C++ for WinRT (C++/CLR) så kan man visst eksportere templates rent. Aner ikke hvordan det skal funke.

 

Uansett så skal ikke templates i seg selv være et problem hverken funksjonelt eller sikkerhetsmessig.

 

Forresten en ting som kan være smart å ha i hodet hvis du har tenkt til å porte:

I Windows kan ikke forskjellige moduler frigjøre minne til hverandre. Den DLL-en som allokerer minne må også frigjøre den. Det er ikke slik i Linux som fungerer i utgangspunktet på en ganske annen måte.

[Ernie]

Forresten en ting som kan være smart å ha i hodet hvis du har tenkt til å porte:

I Windows kan ikke forskjellige moduler frigjøre minne til hverandre. Den DLL-en som allokerer minne må også frigjøre den. Det er ikke slik i Linux som fungerer i utgangspunktet på en ganske annen måte.

Ja, akkurat det der har jeg allerede et system på, forhåpentligvis. Det er et problem hvis man skulle være så uheldig å blande debug og release kode, hvor det isåfall definitivt ikke er samme kode som kjøres ved delete. Pr. nå pålegger jeg alle klasser å ha en destroy-funksjon som sletter objektet fra riktig sted. Det ser ut til å fungere, men det er ikke akkurat noen perfekt løsning i og med at man faktisk må huske på det. Mulig jeg må se litt nærmere på det ved en anledning.

[[kami]]

http://inspircd.github.com/

 

Denne irc serveren har i utganspunktet moduler (.so) som lastes dynamisk etter hva som skrus på i config fila. Kanskje du kan hente noe inspirasjon derfra. (Nå er vel ikke akuratt dette et kroneksempel på noe som er tenkt å funke med flere forskjellige kompilatorer osv, bare så det er sagt)

 

Spørs jo litt på hva du tenker å implementere her, men det kunne jo vært en (bedre) idè å bruke et scriptspråk istede (lua, etc), og heller implementere modulene på den måten.