GCC with -masm=intel produces AT&T syntax

Question

Below is a gcc command line string I used to output to assembly language listing using -masm=intel. Both command line strings work, but they both produce AT&T syntax, not Intel syntax.

gcc -S -masm=intel Svx.c

but that produces a mixed Intel and AT&T syntax.

      .file "Svx.c"
    .intel_syntax noprefix
    .text
    .globl  main
        .type   main, @function
    main:
.LFB0:
        .cfi_startproc
    push    rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    mov rbp, rsp
    .cfi_def_cfa_register 6
    mov DWORD PTR -4[rbp], 0
    jmp .L2
.L3:
    add DWORD PTR -4[rbp], 1
.L2:
    cmp DWORD PTR -4[rbp], 1000000000
    jne .L3
    mov eax, DWORD PTR -4[rbp]
    pop rbp
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc
.LFE0:
    .size   main, .-main
    .ident  "GCC: (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0"
    .section    .note.GNU-stack,"",@progbits

The output looks like a modified Intel syntax, but the AT&T-specific cfi directives for stack handling are not translated. And add DWORD PTR -4[rbp],1 is not Intel syntax.

Why do I get mixed AT&T and Intel syntax with -masm=intel?

AT&T syntax uses a %. For example xorq %rax, %rax or pop %rbp — nissim abehcera, Sep 21 '19 at 19:35
@nissimabehcera Not for GNU directives mate ([example](https://stackoverflow.com/q/17794533/560648)). It's a bit like macros in C. Not an actual part of the assembly language (whose dialect you control; Intel vs AT&T) but instructions to the assembler itself. — Lightness Races in Orbit, Sep 21 '19 at 19:35
@Lightness Races in Orbit You're right but I'm talking about a instructions not about directives. — nissim abehcera, Sep 21 '19 at 19:41
@nissimabehcera The question is (mostly) asking about the directives. That's the point! — Lightness Races in Orbit, Sep 21 '19 at 19:44
There is some information about variations of the intel syntax between assemblers (although I don't know it applies here) in the [intel-syntax tag wiki](https://stackoverflow.com/tags/intel-syntax/info). Maybe helpful regarding the cfe directives: https://stackoverflow.com/questions/38552116/how-to-remove-noise-from-gcc-clang-assembly-output/38552509#38552509 — walnut, Sep 21 '19 at 20:04

score 2 · Accepted Answer · answered Sep 21 '19 at 19:30

2

The CFI directives are directives for the GNU assembler. In general, such directives (which begin with a .) have nothing to do with which assembler dialect you've chosen, and as such the lines you're worried about are not "AT&T specific" nor indeed even related to AT&T.

And add DWORD PTR -4[rbp],1 is Intel syntax.

answered Sep 21 '19 at 19:30

Lightness Races in Orbit

378,754
76
643
1,055

tl;dr "no it doesn't" – Lightness Races in Orbit Sep 21 '19 at 19:40
Thanks for the answer. As you added in your comment, add DWORD PTR -4[rbp],1 is not Intel syntax because Intel syntax does not use -4[rbp]. – RTC222 Sep 21 '19 at 19:42
Why does [this tool](https://defuse.ca/online-x86-assembler.htm#disassembly) accept the line then? And why does GCC emit it? And it's obviously not an AT&T line because of the argument order and because (as nissim pointed out) there are no `%` in it. Simply put, sorry, but the claims in your question are false. – Lightness Races in Orbit Sep 21 '19 at 19:43
When I paste the code above into the tool you referred to and select x64 and assemble, it says: "Sorry, your input is too big or contains unsafe directives! The period (.) character must not appear anywhere in your source code." – RTC222 Sep 21 '19 at 19:47
"The CFI directives . . . have nothing to do with which assembler dialect you've chosen." I have never seen or used CFI directives in Intel syntax. – RTC222 Sep 21 '19 at 19:49
@RTC222 That's because the tool accepts one line of assembly at a time, not the whole file. Plug in the `add` instruction (that you think is erroneous) and you'll get your result. – Lightness Races in Orbit Sep 21 '19 at 19:49
@RTC222 _"I have never seen or used CFI directives in Intel syntax."_ You mean except for in the code you yourself posted? It's not a part of Intel syntax. Or of AT&T syntax. It's a directive to the GNU assembler. You're not listening to me. – Lightness Races in Orbit Sep 21 '19 at 19:49
It seems to me they should have translated that into Intel syntax for managing the stack frame. And why not translate cmp DWORD PTR -4[rbp], 1000000000, which is not Intel syntax. – RTC222 Sep 21 '19 at 19:53
Repeating your misconception over and over again is not useful, @RTC222. The conclusion is that GCC is not wrong about what GNU Assembler code (with either dialect used for the underlying instructions) looks like: you are. But since you're apparently unwilling to accept that fact, there's nothing more I can say to help you. Good evening – Lightness Races in Orbit Sep 21 '19 at 19:54
I'm not being critical of your answer at all. I just think they should have translated the cfi directives because they are manipulating the stack pointer, which is done differently in Intel syntax. But neither you nor I have any control over how GCC does that. Thanks very much for your help. – RTC222 Sep 21 '19 at 19:58
@RTC222: It does not make any sense to keep going on about some "translation". You keep thinking that the directives are part of the underlying instruction set. They are not. They are part of GNU Assembler's additional "directives", and those _directives_ look the same regardless of what dialect you use for the _instructions_. These are TWO DIFFERENT THINGS. If you don't want the CFI directives, you can turn them off with `fno-asynchronous-unwind-tables`. – Lightness Races in Orbit Sep 21 '19 at 19:59

GCC with -masm=intel produces AT&T syntax

1 Answers1