Summary
On x86-64 Linux, compiling Objects/obmalloc.c with GCC and -masm=intel turns every inline-asm read of the thread-pointer slot in the vendored mimalloc into a write to %fs:0. The build succeeds with exit status 0 and only an assembler warning. Clang rejects the same code with a hard error. The asm template in Include/internal/mimalloc/mimalloc/prim.h is written only in AT&T syntax and has no {AT&T|Intel} dialect alternative.
Reproduction Code
Requires x86-64 Linux with glibc and a CPython tree configured with mimalloc (WITH_MIMALLOC 1 in pyconfig.h, the default). Tested with GCC 13.3.0, GNU binutils objdump and Ubuntu Clang 18.1.3.
./configure
CFLAGS_COMMON="-O2 -std=c11 -DPy_BUILD_CORE -I. -IInclude -IInclude/internal -IInclude/internal/mimalloc"
gcc $CFLAGS_COMMON -masm=att -c Objects/obmalloc.c -o obm_att.o
gcc $CFLAGS_COMMON -masm=intel -c Objects/obmalloc.c -o obm_intel.o; echo "gcc exit=$?"
# fs:0x0 accesses that carry no TLS relocation come from the mimalloc slot-0 asm
for m in att intel; do
echo "== $m"
objdump -dr -Mintel --no-show-raw-insn obm_$m.o |
awk '/fs:0x0/{l=$0; getline n; if (n !~ /R_X86_64/) {sub(/^ *[0-9a-f]+:\t/,"",l); print l}}' |
sort | uniq -c
done
clang $CFLAGS_COMMON -masm=intel -c Objects/obmalloc.c -o obm_clang.oMinimal stand-alone reproducer using the same asm statement:
void *get(long slot) {
void *res;
const unsigned long ofs = slot * sizeof(void *);
__asm__("movq %%fs:%1, %0" : "=r" (res) : "m" (*((void **)ofs)) : );
return res;
}gcc -O2 -masm=intel -c tls.c && objdump -d -Mintel --no-show-raw-insn tls.o
Actual Behavior
GCC with -masm=intel exits with status 0. The assembler prints one warning per expansion:
Include/internal/mimalloc/mimalloc/prim.h: Assembler messages:
Include/internal/mimalloc/mimalloc/prim.h:171: Warning: redundant segment overrides
Accesses to fs:0x0 without a relocation:
== att
6 mov rax,QWORD PTR fs:0x0
4 mov rcx,QWORD PTR fs:0x0
12 mov rdx,QWORD PTR fs:0x0
2 mov rsi,QWORD PTR fs:0x0
== intel
6 mov QWORD PTR fs:0x0,rax
4 mov QWORD PTR fs:0x0,rcx
12 mov QWORD PTR fs:0x0,rdx
2 mov QWORD PTR fs:0x0,rsi
All 24 loads become stores. Affected functions include mi_free, _mi_free_delayed_block, mi_heap_collect_ex, _mi_heap_done, mi_heap_get_backing, _mi_heap_init_ex, mi_heap_malloc_small_zero, _mi_heap_malloc_zero_ex and mi_heap_try_new. For example, the same instruction in mi_heap_get_backing is:
-masm=att: 15a5f: mov rdx,QWORD PTR fs:0x0
-masm=intel: 15a5f: mov QWORD PTR fs:0x0,rdx
The stand-alone reproducer compiles to:
4: mov QWORD PTR fs:[rdi*8+0x0],rax
d: ret
Clang with -masm=intel fails:
Include/internal/mimalloc/mimalloc/prim.h:171:13: error: unknown token in expression
Expected Behavior
mi_prim_tls_slot() should load from the thread control block in either assembler dialect. With -masm=intel, the generated code should match the -masm=att build (mov reg,QWORD PTR fs:0x0). If the dialect is unsupported, the build should fail instead of producing a store.
Detail
The TLS slot accessors in Include/internal/mimalloc/mimalloc/prim.h use inline asm templates written only in AT&T syntax. They have no {AT&T|Intel} dialect alternative. There are eight: four loads in mi_prim_tls_slot() (lines 165–171) and four stores in mi_prim_tls_slot_set() (lines 192–198), one each for i386 (%gs), macOS x86-64 (%gs), x32 and x86-64 Linux/BSD (%fs):
__asm__("movq %%fs:%1, %0" : "=r" (res) : "m" (*((void**)ofs)) : ); // x86_64 Linux, BSD uses FSGCC does not translate an asm template. It only substitutes operands, and it formats them for the selected dialect. With -masm=intel, the AT&T template receives Intel-formatted operands:
-masm=att: movq %fs:0, %rax
-masm=intel: movq %fs:QWORD PTR ds:0, rax
movq %fs:QWORD PTR 0[0+rdi*8], rax
GCC's Intel mode puts the assembler in .intel_syntax noprefix. There, the first operand is the destination, so the assembler encodes the line as mov QWORD PTR fs:0x0,rax, a store of rax into the TCB. The %fs: written in the template and the ds: that GCC prints for a constant address are two segment overrides. That is what the redundant segment overrides warning reports. Clang's integrated assembler rejects the mixed text instead (unknown token in expression), so only GCC builds are miscompiled.
On glibc x86-64, _mi_prim_thread_id() reaches the load through mi_prim_tls_slot(0). It is inlined into allocation and free paths such as mi_free and _mi_heap_malloc_zero_ex. Slot 0 is the TCB self-pointer, so the miscompiled code overwrites %fs:0 with a register value instead of reading it.
Summary
On x86-64 Linux, compiling
Objects/obmalloc.cwith GCC and-masm=intelturns every inline-asm read of the thread-pointer slot in the vendored mimalloc into a write to%fs:0. The build succeeds with exit status 0 and only an assembler warning. Clang rejects the same code with a hard error. The asm template inInclude/internal/mimalloc/mimalloc/prim.his written only in AT&T syntax and has no{AT&T|Intel}dialect alternative.Reproduction Code
Requires x86-64 Linux with glibc and a CPython tree configured with mimalloc (
WITH_MIMALLOC 1inpyconfig.h, the default). Tested with GCC 13.3.0, GNU binutilsobjdumpand Ubuntu Clang 18.1.3.Minimal stand-alone reproducer using the same asm statement:
gcc -O2 -masm=intel -c tls.c && objdump -d -Mintel --no-show-raw-insn tls.oActual Behavior
GCC with
-masm=intelexits with status 0. The assembler prints one warning per expansion:Accesses to
fs:0x0without a relocation:All 24 loads become stores. Affected functions include
mi_free,_mi_free_delayed_block,mi_heap_collect_ex,_mi_heap_done,mi_heap_get_backing,_mi_heap_init_ex,mi_heap_malloc_small_zero,_mi_heap_malloc_zero_exandmi_heap_try_new. For example, the same instruction inmi_heap_get_backingis:The stand-alone reproducer compiles to:
Clang with
-masm=intelfails:Expected Behavior
mi_prim_tls_slot()should load from the thread control block in either assembler dialect. With-masm=intel, the generated code should match the-masm=attbuild (mov reg,QWORD PTR fs:0x0). If the dialect is unsupported, the build should fail instead of producing a store.Detail
The TLS slot accessors in
Include/internal/mimalloc/mimalloc/prim.huse inline asm templates written only in AT&T syntax. They have no{AT&T|Intel}dialect alternative. There are eight: four loads inmi_prim_tls_slot()(lines 165–171) and four stores inmi_prim_tls_slot_set()(lines 192–198), one each for i386 (%gs), macOS x86-64 (%gs), x32 and x86-64 Linux/BSD (%fs):GCC does not translate an asm template. It only substitutes operands, and it formats them for the selected dialect. With
-masm=intel, the AT&T template receives Intel-formatted operands:GCC's Intel mode puts the assembler in
.intel_syntax noprefix. There, the first operand is the destination, so the assembler encodes the line asmov QWORD PTR fs:0x0,rax, a store ofraxinto the TCB. The%fs:written in the template and theds:that GCC prints for a constant address are two segment overrides. That is what theredundant segment overrideswarning reports. Clang's integrated assembler rejects the mixed text instead (unknown token in expression), so only GCC builds are miscompiled.On glibc x86-64,
_mi_prim_thread_id()reaches the load throughmi_prim_tls_slot(0). It is inlined into allocation and free paths such asmi_freeand_mi_heap_malloc_zero_ex. Slot 0 is the TCB self-pointer, so the miscompiled code overwrites%fs:0with a register value instead of reading it.