-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the dumbest implementation of mem{cpy,move,set} #28
Comments
I think the solution we decided on was to leave those to |
@shepmaster We actually tried to add them before (see #14 #15 #16) but there was a problem when using LTO to build an executable ( In the meantime, as @Amanieu said, you can use the rlibc crate. My understanding is that you should only need that crate when building an executable (or staticlib) and not for e.g. cross compiling an rlib like
I was about to contact you about this 😄. Do you have a list of the intrinsics that are needed to build AVR programs? I'd love to prioritize porting those to Rust. |
I am indeed attempting to compile into an executable. I haven't even tried to actually cross-compile libcore in a usable way. I just have a Cargo.toml that points at a copy of the libcore code and I edit everything to have references to it (which is quite annoying). I should investigate getting that to be available...
Not a list, no. I've just run into one or two as I've tried to compile more things. Amusingly, compiler-rt doesn't even implement some of them! It actually expects to link against something from gcc, I suppose. I have that one intrinsic in a local branch though, I'd be happy to send a PR for it. |
That would be the list I'm talking about 😄. We are adding them as we find out we need them (at least for
You mean in upstream compiler-rt? Our compiler-rt is pretty outdated I think. Perhaps upstream doesn't have them because the AVR fork hasn't been totally merged yet (or has it? I'm not following closely).
We'll be happy to take it (with tests)! |
I have these (needed for the AVR work), would you like to add them in here for now?
I know we don't have the weak linking situation well-understood, so one (terrible?) possibility is that we could simply
include!('mem.rs')
in the architectures that need it.The text was updated successfully, but these errors were encountered: