Van egy 32-bites .o fileom, szeretnek egy 64-est ...

 ( axt | 2008. július 25., péntek - 11:21 )

A probléma az alábbi: Van egy 32 bites .o fileom. Tudom a benne szereplő függvények szignatúráját (megvan a .h file hozzá).

Van egy programom, ami 64 bites, és nem akarom az egészet újraforditani (a libekkel együtt) 32-re, de össze akarom linkelni a .o filelal, hogy használhassam a .o fileban lévő függvényt.

Megoldható ez valahogy?

Wrappelhető a .o?

Ötletek?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Akarjad újrafordítani. Gyorsabb, mint napokig próbálkozni, és utána feladni.
Egyébként meg egyelőre felejtsd el a 64 bitet, még néhány évig nem lesz rá szükséged.

Másképp mondom: Van egy 64 bites rendszerem itthon. Ahhoz hogy a programot, amihez hozzá szeretném linkelni a .o file-t újrafordítsam
egy halom libet le kell forgassak 32 bitre. Ezt mindenképpen el szeretném kerülni. Szal ha nem lehet wrappelni, akkor kivágom a .o-t a francba és inkább megírom azt. Csak gondoltam hátha van okos megoldás...

Az a halom lib mostanra már talán kész is lenne, ha 11:21-kor hozzákezdtél volna.

Csak hogy kettőt említsek: :)

sci-libs/blas-atlas-3.8.2 merge time: 1 hour, 24 minutes and 25 seconds.
sci-libs/gsl-1.9 merge time: 25 minutes and 30 seconds.

[szerk]
Meg most már érdekel a téma ... :D

nem lehet osszelinkelni szerintem, mert az azt jelentene, hogy minden 32<->64 bit fuggvenyhivasnal at kene kapcsolni a procit masik modba (abban a processben), erre meg bizonyara nincs az OS-ben mechanizmus.

- Use the Source Luke ! -

Tudom, hogy nem lehet összelinkelni, de ott van pl az nspluginwrapper, az is csinál valamit, hogy be tudja húzni a 32 bites flasht, a 64bites böngészőbe ... tehát létezik megoldás ... lehet megnézem a forrását.

axt írta:
lehet megnézem a forrását.

Tedd azt!
Egyébként én újrafordítanám! Kevesebb szívás...
--
Bárki aki aritmetikai módszerekkel akar előállítani egy véletlen számot, az a bűn állapotában leledzik.

en megneztem most. szoval kulon process-ben inditja a 32 bites browserplugin-t - es utana valami rpc-vel komunikal a 64bites process a 32 bites processel.

- Use the Source Luke ! -

Én is erre jutottam! Bevallom azt hittem van egyszerűbb megoldás.

Úgyhogy igazat adok azoknak akik már az elején azt javasolták fordítsak újra mindent. [Ennek ellenére inkább kidobom a .o-t :)]

Nem igazan van mas ut. Esetleg taknyolhatsz belole egy IPC/RPC koritest, de ezzel is inkabb magad szopatod halalra, ahelyett hogy normalis megoldas lenne belole. :)

---
pontscho / fresh!mindworkz

Ha csak .o file, akkor meg kellene szerezni a .c fajlt hozza.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Hehe! Ha meglenne a .c file, akkor ez a topic nem jött volna létre ... :)

matlab.c? :)

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nem, nem kereskedelmi dolog. Csak egy régi kód aminek nincs már meg a forrása.

"Matlab.c"-ből már van 64 bites sztem ... de csak tipp, nem használom ... octave párti vagyok, de ezzel nem akarok flame-et gerjeszteni :).

64 bites pointerrel mit kezdhet egy 32 bitesre szamito kod?

Mindenfele prefix atiras/beiras utan meg minidg at kell hegeszteni pointerek tarolo valtozo mereteket, amit automatizalni nem biztos, hogy lehet.

Aztan minden fuggvenyhez kell valami ragasztot iratni ami ABI kulombsegeket fedi el.

Jarhato ut lehet, hogy egy 32 bites process reszeve teszed .o -t amivel mondjuk shm -en es unix domain socketen keresztul kommunikalsz..

Az előbb bukkantam rá az objcopy nevu programra (a binutils csomagból). Épp most tesztelgetem. Majd megirom a tapasztalataimat.

Ezt leviszi, de ez nem egy nagy kód :)

main.c:

#include <stdio.h>

extern int func(int);

int main()
{
    printf("%d\n",func(10));
}

func.c:

int func(int in)
{
    return in+3;
}

fordítás:

gcc -m32 -c func.c -o func.o
objcopy -O elf64-x86-64 func.o 
gcc main.c func.o -o main

szerk: helyesebben egyszer lefutott azóta segfault :(

Nekem egyszer se. Lehet kihagytad egyszer az m32 -t ?

kezdek erre gyanakodni én is :)

mov %esp,%ebp -nel eltunik ugyeber a stack cimenek felso 32 bitje.
Es hiaba keresi a veremben a parametert, mert az az rdi regiszteren jott.

Az ilyeneket at kell irni r betusre.
Ill kell egy disz fuggveny ami rendesen lebassza verembe a parametereket, majd meghivja(v. ugrik) az "igazit", vagy az "igazit" igy kezdeni.

Egy kis ganyolas:

int func2(int arg)
{
 asm
 (
 	"mov %edi,%eax\n\t"
	"push $next\n\t"
	"push %rbp\n\t"
	"jmp func+6\n\t"
	"next: \n"

 );
}
int main()
{
    printf("%d\n",func2(10));
}

Az ilyen binaris hekkek onmagukban sosem lesznek sikeresek. Plane, mert az objdump csak formatumot konvertal, nem nezi a kod mukodeset. Ha mindenkepp ilyesmivel akartok szopni, akkor szedjetek ossze egy IDA-t, es disassemblaljatok a cuccot. Persze elotte nem art a 32 vs. 64 bites dolgok legmelyere nezni, hogy tudd mikepp kell a kodot modositani ahhoz, hogy e konverzio utan is mukodjon. Eh, regi szep idok, mikor meg fejben tudtam disassemblalni az x86 utasitasokat es hexaeditorral javitottuk sokszor a hibas kodokat... :)

---
pontscho / fresh!mindworkz

Ez már csak ilyen hobbi-reszelés, komoly célom nincs a dologgal. Az eredeti probléma is megoldódott már.

Azon gondolkoztam, hogy valószínűleg meg lehet oldani (gondolom kernel szinten), hogy olyan címteret kapjon,
ahol a stack-pointer felső 32 bitje 0-val kezdődik és akkor ez a probléma talán megszűnik ...
(Érdekes egyébként hogy az objkonv a 'mov 0,%eax'-ból 'mov 0,%rax'-ot csinál, míg a 'mov %esp,%ebp'-ből nem
lesz 'mov %rsp,%rbp'. Gondolom van valami alap utasítás-"szélesség" ... )

Én is néztem hogy az egyik esetben veremben megy át a paraméter a másik esetben meg regiszterben. Kérdés hogy
rá tudom-e venni a fordítót, hogy 64 bites kód esetén is stacken adja át. Igy egy fokkal közelebb lennék a megoldáshoz.

az a baj, hogy ha 64 bites processzben akarod futtani a 32 bites kodot (vagy forditva), akkor magukat a gepikodu utasitasokat kell sok helyen kicserelned (pl. rex prefix 64 biten az inc/dec utasitas 32 biten), es ez meg csak a kezdet (mert aztan jon az address space problema, etc). Vagy neked kell atkapcsolgatnod 32 es 64 bites cpu mod kozott (szerk: marmint a compatibility mode meg a masik kozott 64 biten), a megfelelo kodhoz - ez sem hiszem, hogy egyszeru dolog userspaceben.

lehetseges megoldas szerintem csak az nspluginwrapper altal is alkalmazott, ket kulon 32 es 64 bites processzel.

- Use the Source Luke ! -

Jaja! Sőt! Állítólag nem elég a kapcsolgatás, hanem két külön kód-szegmensbe kell tegyed őket, stb. Én eleinte azt hittem, hogy az objkopy a kódhoz is hozzányúl, de látszik, hogy ez nem igaz, szóval ez a 32 bites kód futtatása 64bites kódon bellül így objkopy-val, meg "ragasztóréteggel" tényleg egy zsákutca.