'undefined reference to __morestack' when compiling with -O #15108
Comments
|
Interesting! It turns out that LLVM got real smart recently (or it always has been!) $ rustc foo.rs -O --emit=ir -o -
; ModuleID = '-.rs'
target datalayout = "e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Function Attrs: nounwind readnone uwtable
define internal void @_ZN4main20hbfcbec594e62aee2eaa4v0.0E() unnamed_addr #0 {
entry-block:
ret void
}
define i64 @main(i64, i8**) unnamed_addr #1 {
top:
%2 = tail call i64 @_ZN10lang_start20h53a1e3fe8c23b585vme11v0.11.0.preE(i8* bitcast (void ()* @_ZN4main20hbfcbec594e62aee2eaa4v0.0E to i8*), i64 %0, i8** %1)
ret i64 %2
}
declare i64 @_ZN10lang_start20h53a1e3fe8c23b585vme11v0.11.0.preE(i8*, i64, i8**) unnamed_addr #1
attributes #0 = { nounwind readnone uwtable "split-stack" }
attributes #1 = { "split-stack" }Basically, this comment is not quite accurate. |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Jun 23, 2014
It was previously assumed that the object file generated by LLVM would always require the __morestack function, but that assumption appears to be incorrect, as outlined in rust-lang#15108. This commit forcibly tells the linker to include the entire archive, regardless of whether it's currently necessary or not. Closes rust-lang#15108
lnicola
pushed a commit
to lnicola/rust
that referenced
this issue
Jan 3, 2024
…r=Veykril fix: rewrite code_action `generate_delegate_trait` I've made substantial enhancements to the "generate delegate trait" code action in rust-analyzer. Here's a summary of the changes: #### Resolved the "Can’t find [email protected] in AstIdMap" error Fix rust-lang#15804, fix rust-lang#15968, fix rust-lang#15108 The issue stemmed from an incorrect application of PathTransform in the original code. Previously, a new 'impl' was generated first and then transformed, causing PathTransform to fail in locating the correct AST node, resulting in an error. I rectified this by performing the transformation before generating the new 'impl' (using make::impl_trait), ensuring a step-by-step transformation of associated items. #### Rectified generation of `Self` type `generate_delegate_trait` is unable to properly handle trait with `Self` type. Let's take the following code as an example: ```rust trait Trait { fn f() -> Self; } struct B {} impl Trait for B { fn f() -> B { B{} } } struct S { b: B, } ``` Here, if we implement `Trait` for `S`, the type of `f` should be `() -> Self`, i.e. `() -> S`. However we cannot automatically generate a function that constructs `S`. To ensure that the code action doesn't generate delegate traits for traits with Self types, I add a function named `has_self_type` to handle it. #### Extended support for generics in structs and fields within this code action The former version of `generate_delegate_trait` cannot handle structs with generics properly. Here's an example: ```rust struct B<T> { a: T } trait Trait<T> { fn f(a: T); } impl<T1, T2> Trait<T1> for B<T2> { fn f(a: T1) -> T2 { self.a } } struct A {} struct S { b$0 : B<A>, } ``` The former version will generates improper code: ```rust impl<T1, T2> Trait<T1, T2> for S { fn f(&self, a: T1) -> T1 { <B as Trait<T1, T2>>::f( &self.b , a) } } ``` The rewritten version can handle generics properly: ```rust impl<T1> Trait<T1> for S { fn f(&self, a: T1) -> T1 { <B<A> as Trait<T1>>::f(&self.b, a) } } ``` See more examples in added unit tests. I enabled support for generic structs in `generate_delegate_trait` through the following steps (using the code example provided): 1. Initially, to prevent conflicts between the generic parameters in struct `S` and the ones in the impl of `B`, I renamed the generic parameters of `S`. 2. Then, since `B`'s parameters are instantiated within `S`, the original generic parameters of `B` needed removal within `S` (to avoid errors from redundant parameters). An important consideration here arises when Trait and B share parameters in `B`'s impl. In such cases, these shared generic parameters cannot be removed. 3. Next, I addressed the matching of types between `B`'s type in `S` and its type in the impl. Given that some generic parameters in the impl are instantiated in `B`, I replaced these parameters with their instantiated results using PathTransform. For instance, in the example provided, matching `B<A>` and `B<T2>`, where `T2` is instantiated as `A`, I replaced all occurrences of `T2` in the impl with `A` (i.e. apply the instantiated generic arguments to the params). 4. Finally, I performed transformations on each assoc item (also to prevent the initial issue) and handled redundant where clauses. For a more detailed explanation, please refer to the code and comments. I welcome suggestions and any further questions!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: