jiebi/CodeConvo huggingface dataset:
Code change:
impl_from!(u32 => f64, #[stable(feature = "lossless_float_conv", since = "1.6.0")]); // float -> float <del> impl_from!(f16 => f32, #[stable(feature = "lossless_float_conv", since = "1.6.0")]); impl_from!(f16 => f64, #[stable(feature = "lossless_float_conv", since = "1.6.0")]); </del> <ins> // FIXME(f16_f128): adding additional `From` impls for existing types breaks inference. See // <https://github.com/rust-lang/rust/issues/123824> </ins> impl_from!(f16 => f128, #[stable(feature = "lossless_float_conv", since = "1.6.0")]); impl_from!(f32 => f64, #[stable(feature = "lossless_float_conv", since = "1.6.0")]); impl_from!(f32 => f128, #[stable(feature = "lossless_float_conv", since = "1.6.0")]);

Related discussion:
text: We caught this bug with too, though the error originates from the crate (0.3.18).
Awesome, thanks for the report! I started a list of known regressions at , and there is a crater run going to figure out how best to deal with this behavior. The fix for this was merged so should be available on the next nightly (couple of hours?).
Code change:
{ let start_len = buf.len(); let mut g = Guard { len: buf.len(), buf }; <del> let ret; </del> loop { if g.len == g.buf.len() { unsafe {

Related discussion:
text: At line 393, the guard object's field is incremented by the value returned from a read implementation. If a questionable returns a value larger than the buffer size, it will take that value and set the length of the vector over the boundary. This bug is reachable from and . Here is a that demonstrates the bug. It segfaults with .
This is definitely broken - nice find. A simple fix would be to just add an in the drop impl: You can still get weird behavior in readtoendwithreservation, but it should be memory safe and it seems best to avoid a bunch of extra logic in the main loop.
It looks like the bug was introduced in
Assigning as and removing .
Code change:
lint_improper_ctypes_char_reason = the `char` type has no C equivalent lint_improper_ctypes_dyn = trait objects have no C equivalent <del> lint_improper_ctypes_enum_phantomdata = this enum contains a PhantomData field </del> lint_improper_ctypes_enum_repr_help = consider adding a `#[repr(C)]`, `#[repr(transparent)]`, or integer `#[repr(...)]` attribute to this enum

Related discussion:
text: The function itself is considered FFI-safe and does not trigger the warning (). Its function pointer should also be allowed, to be consistent. Discovered on CI The original code has several more levels of indirection, but is also considered FFI-safe before. <details<summaryExtracted original code</summary</detailsAccording to CI logs, the warning occurs since rust 1.72.0-nightly ( 2023-07-03). Probably caused by . cc
Okay, so, I had a fix for this that just got rid of the regression, but I'm not sure that's the correct solution here - I think this is correct to be linting in the fn-ptr case and should be linting for the function case. is FFI-unsafe, but we allow a function to return because that's the default, but that doesn't mean that a within a type is okay (with the exception of a wrapper around the - because that's just returning , which we've already decided is okay). In the function case that works right now, that's being allowed because of this code.. ..which is there to support the case. However, it's not quite the right check. It doesn't actually check for ! It checks that the type - however nested - which was deemed FFI-unsafe is and that type is part of a return type. So any FFI-unsafe in a return type makes the entire return type FFI-safe - which is clearly incorrect. That's making the example below compile, which absolutely shouldn't. I've submitted , which makes this even more of a regression by making the function case fail too. We already had a simple "is it a unit" check, so I extended that to check for transparent newtype wrappers too, and removed the incorrect check.
This is unfortunate since I'm trying to return a where is likely to be . What should I do instead if I want to be FFI-safe with layout ?
I'm not so sure anymore after reading comment (). It's clear that some changes are required regardless - our current implementation wrong as demonstrated in the final example from my previous comment, but it's also inconsistent, in that this example... lint for the argument use of , but not the return use of , when really it should be both or neither. After my pull request, it's both.
Code change:
lint_improper_ctypes_char_reason = the `char` type has no C equivalent lint_improper_ctypes_dyn = trait objects have no C equivalent <del> lint_improper_ctypes_enum_phantomdata = this enum contains a PhantomData field </del> lint_improper_ctypes_enum_repr_help = consider adding a `#[repr(C)]`, `#[repr(transparent)]`, or integer `#[repr(...)]` attribute to this enum

Related discussion:
text: With and without my pull request, when you change this to , it doesn't lint.
I'll nominate this issue so that it sees some discussion - see also and .
I posted some more info on zulip but it may also worth mentioning here. ZST is still zero-sized under repr(C), rather than FFI-unsafe.
The issue now also exists in beta. I also found uitests which seems to expect ZST to be FFI-safe, but ends in to suppress the warning and tests nothing.
We discussed this in today's meeting. We didn't have consensus that this should warn; at least some people thought the code in the top comment should continue to compile without warnings. We did have consensus that changing that (to warn) would need an FCP. So, we felt that we'd like to see a fix removing the warning applied to beta and nightly, and then separately if someone wants to propose that we change this to warn, we could evaluate that and do an FCP on it. But at the moment the temperature of the team seems to be that we don't have consensus for such an FCP.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
labels -I-lang-nominated We rendered our opinion
Code change:
# riscv targets currently do not need a C compiler, as compiler_builtins # doesn't currently have it enabled, and the riscv gcc compiler is not # installed. <del> ENV CC_mipsel_unknown_linux_musl=mipsel-openwrt-linux-gcc  </del> <ins> ENV CFLAGS_armv5te_unknown_linux_musleabi="-march=armv5te -marm -mfloat-abi=soft"  CFLAGS_arm_unknown_linux_musleabi="-march=armv6 -marm"  CFLAGS_arm_unknown_linux_musleabihf="-march=armv6 -marm -mfpu=vfp"  CFLAGS_armv7_unknown_linux_musleabihf="-march=armv7-a"  CC_mipsel_unknown_linux_musl=mipsel-openwrt-linux-gcc  </ins> CC_mips_unknown_linux_musl=mips-openwrt-linux-gcc  CC_mips64el_unknown_linux_muslabi64=mips64el-linux-gnuabi64-gcc  CC_mips64_unknown_linux_muslabi64=mips64-linux-gnuabi64-gcc 

Related discussion:
text: Upstream issue: The version of used in the (and possibly the one too?) standard library has a bug where it will sometimes walk off the end of the segment containing the section and segfault. I've struggled to reproduce this except in some proprietary code, but the backtrace looks like: There's a proposed fix in the linked LLVM issue, which can possibly be patched into libunwind before building the musl target if taking an updated libunwind isn't possible.
I ran into this as well.
There doesn't seem to be any movement on the LLVM issue since I raised it, not even an assignee. Do you know if this is normal behaviour for them? Or if I've mis-raised the issue?
Running into this as well at OneSignal
I can reproduce this on latest stable on an open source project: On the second run of the final command, the background process will segfault.
After much investigation, I think there's two bugs here, one that LLVM's unwinder will consider unreadable memory as part of the section, and one that the rust compiler creates invalid (unusual?) unwind information. The crash is specifically happening when trying to find unwind information for the frame above (not but the "c-runtime" main. Since the frames above the C entry point are provided by the runtime (musl in this case), they are contained in / which, in rust's musl-targeting stdlib have been provided. The provided object files have no unwind information in them: This in and of itself isn't a huge problem, the code stops trying to unwind when it can't find unwind information for the next frame (), so it should stop after which would be fine. so long as we can safely fail to find the unwind information. The issue is that libunwind's logic for searching for FDE (frame description entry) for the parent frame is pretty all-encompassing and runs in many phases, and one of these crashes (sometimes) if there searched for address is not present in the unwind information).
Code change:
# riscv targets currently do not need a C compiler, as compiler_builtins # doesn't currently have it enabled, and the riscv gcc compiler is not # installed. <del> ENV CC_mipsel_unknown_linux_musl=mipsel-openwrt-linux-gcc  </del> <ins> ENV CFLAGS_armv5te_unknown_linux_musleabi="-march=armv5te -marm -mfloat-abi=soft"  CFLAGS_arm_unknown_linux_musleabi="-march=armv6 -marm"  CFLAGS_arm_unknown_linux_musleabihf="-march=armv6 -marm -mfpu=vfp"  CFLAGS_armv7_unknown_linux_musleabihf="-march=armv7-a"  CC_mipsel_unknown_linux_musl=mipsel-openwrt-linux-gcc  </ins> CC_mips_unknown_linux_musl=mips-openwrt-linux-gcc  CC_mips64el_unknown_linux_muslabi64=mips64el-linux-gnuabi64-gcc  CC_mips64_unknown_linux_muslabi64=mips64-linux-gnuabi64-gcc 

Related discussion:
text: At a high level the process looks like () Look for a "compact unwinding table" Look for "DWARF unwind information" Look for ARM EHABI unwind info Look for dynamically created DWARF unwind entries For Rust x8664 musl binaries, the compiler has provided DWARF unwind information, so we fall into the second bullet (): No compact encoding hint, so the first section isn't interesting Search the section for an index for the frame - not present Check the local cache in case we've seen this frame before - we haven't Scan the whole of the section for the address of interest - CRASH! Digging further, we see that the logic for scanning the sector looks like (): Read a length field If it's 0 stop, we're done - rustc never seems to generate this "end-of-information" marker Skip over CIE entries For non-CIE entries work out if the address we're looking for is in the range of the entry, if so we've got our FDE Jump forward by the length of the CFI entry In each loop we check that the newly found CIE entry is in a reasonable place (between and ). If it's not, bail out for safety and fail the lookup. Unfortunately, as in the linked issue originally is incorrectly set too big (it's set to which is almost always wrong) so the unwind code will step right off the end of the segment and into one of: (LSDA) - This starts with a signature that is approximately , which is bigger than the error introduced by the miscalculation, so (after failing to parse the LSDA as a CFI entry) it jumps forward out of the range and bails out because the of the "reasonable location" check I mentioned above. The gap before (if the did not have a length that's a multiple of 32 and thus there's padding between the sections). In this case when it tries to read the next entry one of three things happens: The padding bytes happen to have a large value (when interpreted as a ) and we're in a similar position to the case where there's no padding, fail to parse the CFI entry, try to jump to the next one, realise we're jumping out of the allowed range and bail out for safety.
Code change:
# riscv targets currently do not need a C compiler, as compiler_builtins # doesn't currently have it enabled, and the riscv gcc compiler is not # installed. <del> ENV CC_mipsel_unknown_linux_musl=mipsel-openwrt-linux-gcc  </del> <ins> ENV CFLAGS_armv5te_unknown_linux_musleabi="-march=armv5te -marm -mfloat-abi=soft"  CFLAGS_arm_unknown_linux_musleabi="-march=armv6 -marm"  CFLAGS_arm_unknown_linux_musleabihf="-march=armv6 -marm -mfpu=vfp"  CFLAGS_armv7_unknown_linux_musleabihf="-march=armv7-a"  CC_mipsel_unknown_linux_musl=mipsel-openwrt-linux-gcc  </ins> CC_mips_unknown_linux_musl=mips-openwrt-linux-gcc  CC_mips64el_unknown_linux_muslabi64=mips64el-linux-gnuabi64-gcc  CC_mips64_unknown_linux_muslabi64=mips64-linux-gnuabi64-gcc 

Related discussion:
text: The padding bytes are medium sized when interpreted as a , in this case, after the failed parse, the unwinder jumps far enough to be off the end of the loaded segment, but not far enough to be past the so the sanity check passes and the unwinder attempts to read the next CFI entry, reads a 32-bit number from an invalid address and... :boom: The padding bytes are small when interpreted as a , and the unwinder jumps into a random part of the LSDA and we're back in a situation that's functionally similar to when we're reading the padding bytes and the same three options are still applicable in the next lookup. So, what's the bug(s) here? LLVM is miscalculating the section length (the original issue) Rustc (or the linker?) doesn't include the marker at the end of Either of these would fix this issue, probably both should be done?
Ah, there's another possible route for the crash: If the LOAD segement is really big, the signature at the start of the LSDA might not be big enough to jump past leading to an invalid read and a :boom:
I've ran into this issue as well. What's the status of this?
I've been looking at a proper fix for this and neither of the two paths I proposed above are yeilding simple results: LLVM miscalculating the section length: The simple fix I proposed in the upstream issue allows the unwinder to read arbitrary parts of the LOAD segment before bailing, which might have unexpected effects A more complex fix needs to calculate the section length at runtime, which is tricky as sections don't exist at runtime... Neither the nor section contains a length field so we're not simply told the length Maybe read the executable off disk (look in ) and parse the section table? Might not be readable to the current user. Might not even exist (not sure if this is possible, can you create a linux executable from an in-memory image?) Add terminator entry to the end of the section This relies on the static linker's behaviour, which is a shame as allows you to bring your own linker and both seem inconsistent about whether they add terminator entries, sometimes they do, sometimes they don't This feels like something that rustc can't fix locally or rely on externally Another option would be for LLVM to skip walking the section if the lookup in the fails.
Code change:
# riscv targets currently do not need a C compiler, as compiler_builtins # doesn't currently have it enabled, and the riscv gcc compiler is not # installed. <del> ENV CC_mipsel_unknown_linux_musl=mipsel-openwrt-linux-gcc  </del> <ins> ENV CFLAGS_armv5te_unknown_linux_musleabi="-march=armv5te -marm -mfloat-abi=soft"  CFLAGS_arm_unknown_linux_musleabi="-march=armv6 -marm"  CFLAGS_arm_unknown_linux_musleabihf="-march=armv6 -marm -mfpu=vfp"  CFLAGS_armv7_unknown_linux_musleabihf="-march=armv7-a"  CC_mipsel_unknown_linux_musl=mipsel-openwrt-linux-gcc  </ins> CC_mips_unknown_linux_musl=mips-openwrt-linux-gcc  CC_mips64el_unknown_linux_muslabi64=mips64el-linux-gnuabi64-gcc  CC_mips64_unknown_linux_muslabi64=mips64-linux-gnuabi64-gcc 

Related discussion:
text: It's unlikely to ever reveal anything new, and it seems that this section is just un-walkable with any kind of reliability.
Here are two tested workarounds, neither very pretty, but both work: to your Cargo config a build, extract the link script from the linker verbose output the lines: .ehframe : ONLYIFRO { KEEP ((.ehframe)) (.ehframe.) } ... .ehframe : ONLYIFRW { KEEP ((.ehframe)) (.ehframe.) } them to: .ehframe : ONLYIFRO { KEEP ((.ehframe)) (.ehframe.) LONG(0x0) } ... .ehframe : ONLYIFRW { KEEP ((.ehframe)) (.ehframe.) LONG(0x0) } ( is the CIE terminator) off this script somewhere in Cargo config (probably under the Musl target) an object containing just the terminator: 2, Add to your Cargo config (probably under the Musl target)
Hi! Is this still an issue? If so, is there perhaps a simpler way to reproduce this than the instructions linked above?
The setup that's needed is: A large LOAD segment (the one containing and ) Specifically the section needs to be deep into the segment How deep it has to be is roughly determined by the first of the section So something like the following should trigger the fault: This builds a huge section, which lives before the section so should lead to the crash. Hedging words because I can't reproduce the issue on my development machine (I run out of RAM and get OOM-killered).
Hmm, that doesn't seem to be sufficient (tested on the current stable and nightly). I get this output when building and running this on Arch Linux: I also get the same output when using to capture the backtrace.
I noticed the wrong ehSectionEnd calculation independently and filed
It looks like the gcc driver on Alpine adds the file to the link, which includes a terminator in . It seems that the rustc driver doesn't add something like this? (LLVM has a that has an .ehframe terminator, so maybe that's relevant to rustc.)
Code change:
# riscv targets currently do not need a C compiler, as compiler_builtins # doesn't currently have it enabled, and the riscv gcc compiler is not # installed. <del> ENV CC_mipsel_unknown_linux_musl=mipsel-openwrt-linux-gcc  </del> <ins> ENV CFLAGS_armv5te_unknown_linux_musleabi="-march=armv5te -marm -mfloat-abi=soft"  CFLAGS_arm_unknown_linux_musleabi="-march=armv6 -marm"  CFLAGS_arm_unknown_linux_musleabihf="-march=armv6 -marm -mfpu=vfp"  CFLAGS_armv7_unknown_linux_musleabihf="-march=armv7-a"  CC_mipsel_unknown_linux_musl=mipsel-openwrt-linux-gcc  </ins> CC_mips_unknown_linux_musl=mips-openwrt-linux-gcc  CC_mips64el_unknown_linux_muslabi64=mips64el-linux-gnuabi64-gcc  CC_mips64_unknown_linux_muslabi64=mips64-linux-gnuabi64-gcc 

Related discussion:
text: FWIW, it looks like LLVM's LLD linker automatically adds a terminator to the end of .ehframe, even if one isn't present in the linker inputs, so that could be a workaround: I think libunwind should stop scanning .ehframe when it finds unwind info from .ehframehdr (i.e. the GNUEH_FRAME segment).
Rustc's musl-targeting link includes: I don't exactly know where the files come from (they're shipped with the compiler toolchain, e.g. mine are in ) but looking at the musl codebase, there's no terminator in : (Intriguingly there's also no in the musl codebase, suggesting Rustc gets these objects from somewhere else?)_ I wouldn't expect to see a or since the rustc musl target doesn't include a C++ runtime and musl libc doesn't define either of these objects for the C runtime either.
It looks like musl's crt1 is a C file, not assembly. crt/{S,r,}crt1.c When crtbegin and crtend were to LLVM (), there was some discussion about which project is responsible for which aspects of the CRT begin/end files. Apparently the status quo on Linux is that: the compiler (e.g. libgcc) provides crtbegin/crtend the libc provides crti/crte (and maybe crt1, too?) That is the case on my gLinux (i.e. Debian) system: /usr/lib/x8664-linux-gnu/crt[1ie].o all come from the libc6-dev:amd64 package /usr/lib/gcc/x8664-linux-gnu/9/{crtbegin.o,crtend.o} come from libgcc-9-dev:amd64 The .ehframe terminator is usually in crtend, which is part of libgcc (not glibc or musl). LLVM's compiler-rt also provides crtbegin/crtend files. The gcc and clang drivers link a crtend object even for C programs. On Alpine, the gcc driver links a libgcc crtend object. It looks like rustc typically invokes the driver, but when it's targeting musl, it enters a mode where it provides the start files explicitly, and in this mode, it doesn't include crtbegin/crtend. For Alpine, I see , , , and .
Code change:
# riscv targets currently do not need a C compiler, as compiler_builtins # doesn't currently have it enabled, and the riscv gcc compiler is not # installed. <del> ENV CC_mipsel_unknown_linux_musl=mipsel-openwrt-linux-gcc  </del> <ins> ENV CFLAGS_armv5te_unknown_linux_musleabi="-march=armv5te -marm -mfloat-abi=soft"  CFLAGS_arm_unknown_linux_musleabi="-march=armv6 -marm"  CFLAGS_arm_unknown_linux_musleabihf="-march=armv6 -marm -mfpu=vfp"  CFLAGS_armv7_unknown_linux_musleabihf="-march=armv7-a"  CC_mipsel_unknown_linux_musl=mipsel-openwrt-linux-gcc  </ins> CC_mips_unknown_linux_musl=mips-openwrt-linux-gcc  CC_mips64el_unknown_linux_muslabi64=mips64el-linux-gnuabi64-gcc  CC_mips64_unknown_linux_muslabi64=mips64-linux-gnuabi64-gcc 

Related discussion:
text: For rustc/glibc, I don't see any of those flags, so the cc driver uses the default CRT begin/end/i/n/1 files. I see that rustc documents a lot of this at The unwinder needs the .ehframe terminator, because the .ehframehdr search table is optional, and because .ehframehdr has the start address of .ehframe, but not its size. ( / ). I don't think it's reasonable to open the ELF file indicated by dlpiname -- in principle, that duplicates the work done by the loader, and I can think of many specific things that wouldn't work. (e.g. the vdso, the executable w/glibc, Android's androiddlopen_ext and ability to map DSOs from zip files, unlinked files, etc).
Using self-contained mode is not generally recommended for serious work. If the compiler heuristics enable it by default, then it can be explicitly disabled with , then gcc will be used for linking without and will find all the necessary CRT objects by itself. Then it's important to make sure that gcc for the right target (musl in this case) is used by rustc.
If the compiler heuristics enable it by default Here's a FIXME for improving the heuristic for musl targets:
Thanks for that, very interesting. I think there are two separate use cases for musl-targeting builds: an environment where there's a full "native musl" toolchain (like on Alpine etc) where I think you're correct that we shouldn't use and should let the toolchain sort it out for us though I can't see an easy way to tell if a real toolchain is available a generic linux environment where the goal is fully static binaries (for easy of redistribution/embedding in thin container images/etc.)