In Unix/Linux systems:
.a
is the usual extension for static libraries (aka Archives of multiple.o
files, made withar(1)
). Dynamic libraries, aka Shared Objects, use.so
..s
is used for asm compiler output. (gcc -S foo.c
produces asm output, with a default filename offoo.s
).S
is used for hand-written asm source files.gcc -c foo.S
runs it through the C preprocessor (so you can use#include<>
,#if
,#define
, and C-style comments.) Some C headers, likeasm/unistd.h
only have#define
s, and so can be included in a .S to get definitions like__NR_write
system call numbers, for example.
In x86, there are two separate versions of asm syntax: AT&T (used by Unix compilers like gcc), and Intel/NASM (with a couple dialects, like MASM vs. NASM itself).
.S
is appropriate for asm in GNU as
syntax, whether you use any C preprocessor features or not.
In x86, .asm
is more often associated with Intel-syntax NASM/YASM, or MASM, source code. Outside of x86, it’s probably a good choice for asm source files that could be assembled by the platform-specific assembler, if it uses different directives than GNU as
.
The glibc source tree uses .S
for all asm source files.
People with a gcc background might put their MIPS asm into .S
or .s
files, while people with more NASM/YASM experience (or Windows), might go for .asm
.
I’d recommend against .s
files, because it’s easy to accidentally overwrite with gcc -S foo.c
.