flat assembler
Message board for the users of flat assembler.
Index
> Linux > Which syntax should I learn: AT&T or Intel ? 32 or 64-bit ? |
Author |
|
egy 01 Aug 2017, 19:54
Greetings to all members of the board. I just found this amazing board and I have started learning fasm on linux. There is so much to absorb. I hope I can best benefit from all your experience.
I came across this quora question and it confused me. AFAIK, fasm uses the intel syntax. The first answer of the question discouraged learning the Intel syntax and favored AT&T. To quote: Quote:
Also, on the topic of 32 and 64 bit: Quote: Because it’s one of the few sources for correct kernel calling from Assembly. ALL other sources use crappy old 32bit calls, which means INT $80 calling convention. This calling convention is highly discouraged on 64 bit systems and they said, that this feature can get deactivated at any time. So, my questions are: 1- AT&T syntax or Intel ? 2- 32-bit instructions or 64-bit ? (my machine is 32-bit) 3- Also, will I be able to use a debugger on linux (like gdb) to debug my fasm programs ? Thank you |
|||
01 Aug 2017, 19:54 |
|
Furs 01 Aug 2017, 20:06
No offense but that guy is plain wrong.
I'd go with Intel syntax unless you want to either mix it with GCC a lot, or want to parse the result easier. While GCC (well, GAS) supports intel syntax as well, it's a pain if the project uses AT&T in other inline asms + it's way easier to parse (with automated scripts/tools) AT&T asm output. However, if you code only in asm a specific function or module then use FASM with Intel syntax. AT&T is just plain bad syntax. Intel syntax flows naturally for instructions since they are like C statements, e.g. Code: mov eax, ebx ; eax = ebx add eax, ecx ; eax += ecx shlx eax, edx, ecx ; eax = edx<<ecx For question (2), then of course use 32-bit since it can't run 64-bit (note that 64-bit Linux can in most cases run 32-bit software just fine). What he said about syscall is mostly bullshit. Note that 64-bit code (not instructions, it's a different "mode") uses syscall while 32-bit code uses int 0x80 (or sysenter). 64-bit kernel can in most cases run 32-bit code, so there's no issue there.
For 32-bit when you become more advanced, learn to use the VDSO for faster system calls (which utilize sysenter), but forget that for now (?) For (3), yes why not? (also, FASM can do 16-bit code just fine, wtf is he smoking; I think he meant GCC there) Here's useful syscalls numbers/reference straight from Linus' github (these go into eax when performing the syscall): 32-bit | 64-bit You should bookmark them |
|||
01 Aug 2017, 20:06 |
|
egy 02 Aug 2017, 13:32
I have really enjoyed the answers, and I am surprised I got instant answers! Very active community indeed! Thanks Furs and revolution.
Quote: I'd go with Intel syntax unless you want to either mix it with GCC a lot Sorry for the silly question, but if I wanted to use C libraries alongside my code, will that be a hurdle ? Quote: What he said about syscall is mostly bullshit Glad I asked here before making any careless moves My thanks for the syscalls for 32-bits. I am following a windows-syntax tutorial for fasm and I often see `call [ExitProcess]` after importing kernel32 library. Now at least I have some directions. Quote: For 32-bit when you become more advanced, learn to use the VDSO for faster system calls (which utilize sysenter) Will do. Quote: If you want to keep your sanity and save your shift key then use Intel syntax IKR ? I saw an example of AT&T's last night and... you have to prefix % A LOT! This, is enough to drift away from AT&T syntax. Thanks for the simple plain answer. |
|||
02 Aug 2017, 13:32 |
|
Furs 02 Aug 2017, 14:02
egy wrote: Sorry for the silly question, but if I wanted to use C libraries alongside my code, will that be a hurdle ? Obviously if you write a function fully in asm (or module or even app) then you don't need that so you can just use FASM for that (for later, to get the vdso address you either call getauxval from libc.so or need to scan the auxiliary vector yourself, reading the pseudo-file /proc/self/auxv with simple read operations and scanning it for AT_SYSINFO [yeah it sounds complicated but it's a simple loop through a 2-element struct; I've done that already so probably I can give you the code example when you want it when you get more accustomed to system calls, but I optimized it for size since it's "initialization"]) |
|||
02 Aug 2017, 14:02 |
|
egy 02 Aug 2017, 18:12
Quote: When I was speaking of GCC I was referring to its so-called "inline asm", which is asm statements you embed in C code directly To complete my understanding, the .inline asm statements/instructions are written in AT&T's rather than Intel's, am I right ? EDIT 1: just to re-iterate: I can then put statements/instructions of inclusion for C libraries statements in my assembly code easily ? EDIT 2: Why not pin the links to system calls you provided to the Linux FAQ ? There are three thread links under "specific sections" in the FAQ (on of them about syscalls macros) but none of them was actually useful to me. Links to linuxassembly.org are broken. |
|||
02 Aug 2017, 18:12 |
|
Furs 02 Aug 2017, 21:33
Well I'm not a mod but revolution could merge it to main post, good idea (I wasn't even aware of the FAQ, sorry).
Re: inline asm. Yes you can call anything from asm, don't worry about it. What inline asm means is statements directly inside C source code, for example: Code: /* some C code */ asm("asm_template ...":"+r"(a):"r"(b)); /* more C code */ If you write a function/module in a separate .asm file then it's not "inline asm" anymore, it's simply "asm". And yes asm can call *anything* since you interface with the hardware already. (you can call a library from asm written in *any* language no matter its calling convention ) |
|||
02 Aug 2017, 21:33 |
|
Azagaros 03 Aug 2017, 01:16
At&t source, destination is all you need.
intel destination, source. Addressing may be slightly different but the opp instructions are the same. |
|||
03 Aug 2017, 01:16 |
|
egy 03 Aug 2017, 13:31
Thanks Azagaros for the reply. There is also the painful % before every register and $ before... I don't know. But Intel's is much nicer and simpler.
Quote: You can use an intel syntax thing, but then you have to remember to turn it off at the end of the asm else you screw up the other inline asms I think. Anyway, I made a quick search on SE and found that the flag: Code: gcc -masm=intel Quote: And yes asm can call *anything* since you interface with the hardware already. All has been settled then. Time to work As for the links at the FAQ, I can't access linuxassembly.org, maybe there is a mirror somewhere ? Cheers to all for helping out. |
|||
03 Aug 2017, 13:31 |
|
Tomasz Grysztar 03 Aug 2017, 14:37
egy wrote: As for the links at the FAQ, I can't access linuxassembly.org, maybe there is a mirror somewhere ? |
|||
03 Aug 2017, 14:37 |
|
egy 03 Aug 2017, 15:12
I appreciate it Tomasz.
|
|||
03 Aug 2017, 15:12 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.