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

C/C++

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?

  • 1613 megtekintés

( NevemTeve | 2008. 07. 25., p – 11:24 )

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...

( denes | 2008. 07. 25., p – 11:36 )

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 ! -

( hrgy84 | 2008. 07. 25., p – 16:18 )

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

( turul16 v | 2008. 07. 27., v – 23:39 )

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 :(

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

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.