6 ms·
For actual analysis as opposed to cutesy blog post demos I'd actually use vi test.s But if you insist on doing things the hard way on stdout, GCC has got
by disas 5y ago
For actual analysis as opposed to cutesy blog post demos I'd actually use
vi test.s
But if you insist on doing things the hard way on stdout, GCC has got you covered as well. Add -o - to the command line.
- WalterBright 5y agoThen I get: .file "test.c" .text .globl fn .type fn, @function fn: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 popq %rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size fn, .-fn .ident "GCC: (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4" .section .note.GNU-stack,"",@progbits No thanks.
- disas 5y ago<shrug> At this point we have reduced your blog post's message from "Look at this amazing new feature! It's so novel and unique! All other compiler developers are complete idiots!" to "Sometimes when I read assembly code I'm not interested in debug information.". I am happy to concede this point.
- astrange 5y agoThere is rather a lot of garbage in those .s files for things like debuginfo, stray comments the GCC developers accidentally put in their asm output, linker commands, etc. On the other hand it properly shows relocations (like global variable references) which disassemblers tend to get wrong.