Repository navigation
format_args! with certain arguments segfaults at run-time on x86_64-unknown-linux-gnux32 #59220
Description
Trying to display most types causes a segmentation fault at run time when compiled in debug mode for x32 ABI
Example:
echo 'fn main() { println!("{}", 0); }' | rustc --target x86_64-unknown-linux-gnux32 -
./rust_out
Segmentation fault (core dumped)println!,format!andformat_args!equally affected,.to_string()is not.- Only happens in debug mode, works fine in release mode.
- Happens with all integer types from
i8tou128,f32,f64,bool,charandfmt::Argument, but not with references to those types orstr,Stringand raw pointers. - Debug and pointer formatting (
"{:?}","{:#?}"and"{:p}") are not affect, but all other format traits ("{:x}","{:02}","{:#b}"`) all result in a segfault.
Debugging attempt & assembly
The segfault happens at the second instruction in main;
here's what that area looks like with ... --emit asm:
_ZN8rust_out4main17h19287f9e3b324627E:
.cfi_startproc
subl $72, %esp
.cfi_def_cfa_offset 80
movl _ZN4core3fmt3num52_$LT$impl$u20$core..fmt..Display$u20$for$u20$i32$GT$3fmt17ha3b2ffd94f72c608E@GOTPCREL, %esi
leal .L__unnamed_2(%rip), %eax
movl %eax, 68(%esp)
movl 68(%esp), %edi
callq _ZN4core3fmt10ArgumentV13new17hfeb1c719432004d8E
movl %eax, 28(%esp)
movl %edx, 24(%esp)
-- snipand after disassembling: (objcopy -dr rust_out | rg -A10 'rust_out.*?main'
00002610 <_ZN8rust_out4main17h19287f9e3b324627E>:
2610: 83 ec 48 sub $0x48,%esp
2613: 8b 34 25 aa 49 22 00 mov 0x2249aa,%esi
261a: 8d 05 84 9a 01 00 lea 0x19a84(%rip),%eax # 1c0a4 <_fini+0x10>
2620: 67 89 44 24 44 mov %eax,0x44(%esp)
2625: 67 8b 7c 24 44 mov 0x44(%esp),%edi
262a: e8 81 fe ff ff callq 24b0 <_ZN4core3fmt10ArgumentV13new17hfeb1c719432004d8E>
262f: 67 89 44 24 1c mov %eax,0x1c(%esp)
2634: 67 89 54 24 18 mov %edx,0x18(%esp)
2639: 8d 05 c1 36 22 00 lea 0x2236c1(%rip),%eax # 225d00 <debug_section_names+0x40>
263f: 8d 0d 63 9a 01 00 lea 0x19a63(%rip),%ecx # 1c0a8 <_fini+0x14>
-- snipWith -O the compiler emits
72:_ZN8rust_out4main17h19287f9e3b324627E:
73- .cfi_startproc
74- subl $40, %esp
75- .cfi_def_cfa_offset 48
76- leal .L__unnamed_2(%rip), %eax
77- movl %eax, 8(%esp)
78- movl _ZN4core3fmt3num52_$LT$impl$u20$core..fmt..Display$u20$for$u20$i32$GT$3fmt17ha3b2ffd94f72c608E@GOTPCREL(%rip), %eax
79- movl %eax, 12(%esp)
80- leal .L__unnamed_3(%rip), %eax
81- movl %eax, 16(%esp)
82- movl $2, 20(%esp)
-- snipFor println!("{:?}", 0):
314:_ZN8rust_out4main17h19287f9e3b324627E:
315- .cfi_startproc
316- subl $72, %esp
317- .cfi_def_cfa_offset 80
318- leal .L__unnamed_2(%rip), %eax
319- movl %eax, 68(%esp)
320- movl 68(%esp), %edi
321- leal _ZN4core3fmt3num50_$LT$impl$u20$core..fmt..Debug$u20$for$u20$i32$GT$3fmt17had225e6626567b7bE(%rip), %esi
322- callq _ZN4core3fmt10ArgumentV13new17hfeb1c719432004d8E
323- movl %eax, 28(%esp)
324- movl %edx, 24(%esp)
-- snipand for println!("{}", &0)
268:_ZN8rust_out4main17h19287f9e3b324627E:
269- .cfi_startproc
270- subl $72, %esp
271- .cfi_def_cfa_offset 80
272- leal .L__unnamed_2(%rip), %eax
273- movl %eax, 68(%esp)
274- movl 68(%esp), %edi
275- leal _ZN44_$LT$$RF$T$u20$as$u20$core..fmt..Display$GT$3fmt17h1aa6d8d315ee6bb6E(%rip), %esi
276- callq _ZN4core3fmt10ArgumentV13new17h122dce191cc0b572E
277- movl %eax, 28(%esp)
278- movl %edx, 24(%esp)
-- snipMeta
rustc 1.33.0 (2aa4c46cf 2019-02-28)
binary: rustc
commit-hash: 2aa4c46cfdd726e97360c2734835aa3515e8c858
commit-date: 2019-02-28
host: x86_64-unknown-linux-gnu
release: 1.33.0
LLVM version: 8.0
Activity
Mark-Simulacrum commentedon Mar 15, 2019
cc @malbarbo who I believe initially added this target
Since this is not a tier 1 target I am not nominating for the compiler team to take a look (we don't have the resources to support it at this point).
alsoijw commentedon Nov 7, 2020
Some additional information:
--emit=llvm-ir and --emit=llvm-bc aren't affected. They produced less code that rustc, so output binary is smaller.
All this parts build x32 binary that work fine.
And debugging original binary builded from rustc with gdb. I set breakpoint on main and disassemble code. I check 4 variants with
true,&true,"",8. This is example for""There are <<&T as core::fmt::Display>::fmt> in the beginning of main::main In correct binaries. But in corrupted there isn't.
hvdijk commentedon Feb 6, 2021
This should be fixed automatically the next time rust updates to a newer LLVM. I have recently committed patches to fix x32 codegen to upstream LLVM and am locally running rust with those same patches applied. The test case in this issue works fine here, as do various bigger rust programs such as ripgrep, and with a few trivial patches, rustc itself.
alsoijw commentedon Feb 15, 2021
@hvdijk this is about
rustc_data_structures::static_assert_size?hvdijk commentedon Feb 15, 2021
Yes, those are the only modifications needed on the Rust side of things (as opposed to the LLVM side) to get a working x32 rustc binary. The
static_assert_size!s are conditional on#[cfg(target_arch = "x86_64")]and should be conditional on#[cfg(all(target_arch = "x86_64", target_pointer_width = "64"))]. I am planning on submitting PRs for that once the LLVM side of things is ready.alsoijw commentedon Feb 27, 2021
@hvdijk can you say version of llvm or hash with fix?
hvdijk commentedon Feb 27, 2021
LLVM 12 will have the fixes.
malbarbo commentedon Mar 5, 2021
#81451 was merged and I checked that this issue was indeed fixed.