How to move AT&T Style Assembly code over to Visual Studio and Intel Style Syntax?

1
votes

I have a very specialized file written in x86-64 assembly for Linux, compiled under GCC. I need to move that code over to a Visual Studio project and mll64.exe wants the assembly file to be in Intel format.

I have tried to build a cross-platform DLL but it doesn't work:

15:47:19 cpudiag2 > gcc -shared -o my.dll my.o

/usr/bin/ld: my.o: relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC my.o: could not read symbols: Bad value collect2: ld returned 1 exit status

15:47:19 cpudiag2 > gcc -fPIC my.S

/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status

So then I tried to let GCC decompile from the object file into Intel syntax but that doesn't work either. Both of the following two commands result in decompiled assembly code in the AT&T syntax. Why?

objdump -d -M=intel my.o

gcc -S -masm=intel my.o

1
assemblyx86-64intelatt

1 Answers

3
votes

Various confusions there.

  1. Naming your file my.dll won't change its format
  2. since library format is different on linux and windows, you can't make a cross-platform dll
  3. -fPIC will not magically make hand-written asm PIC, it only works for compiler generated code
  4. to get an object file, you should pass -c switch to gcc (but that won't help you in this case)
  5. gcc -S doesn't disassemble an object file, it's for producing assembly from C code
  6. objdump -d -M=intel my.o should work, but what it produces will not be suitable for assembling (especially not on windows, as that uses different calling conventions)

Your best bet might be assembling said code to windows object file (using gcc/gas targeted for windows) and including that as binary in your project (just for linking), with a small glue layer for calling convention conversion if needed. Won't allow you to edit the assembly source, though.