Skip to content
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

Closed
shepmaster opened this issue Aug 12, 2016 · 4 comments · Fixed by #29
Closed

Add the dumbest implementation of mem{cpy,move,set} #28

shepmaster opened this issue Aug 12, 2016 · 4 comments · Fixed by #29

Comments

@shepmaster
Copy link
Member

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.

@Amanieu
Copy link
Member

Amanieu commented Aug 12, 2016

I think the solution we decided on was to leave those to rlibc. So you would need to link to that crate in addition to rustc-builtins.

@japaric
Copy link
Member

japaric commented Aug 13, 2016

@shepmaster We actually tried to add them before (see #14 #15 #16) but there was a problem when using LTO to build an executable (memcpy got misoptimized to a recursive call). There problem has been reported upstream as rust-lang/rust#35540. Once that's fixed we'll add memcpy et al here as weak symbols.

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 core to AVR, is that correct?

needed for the AVR work

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.

@shepmaster
Copy link
Member Author

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 core to AVR, is that correct?

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...

a list of the intrinsics that are needed to build AVR programs

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.

@japaric
Copy link
Member

japaric commented Aug 13, 2016

I've just run into one or two as I've tried to compile more things.

That would be the list I'm talking about 😄. We are adding them as we find out we need them (at least for no_std targets).

Amusingly, compiler-rt doesn't even implement some of them!

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).

I have that one intrinsic in a local branch though, I'd be happy to send a PR for it.

We'll be happy to take it (with tests)!

japaric pushed a commit that referenced this issue Aug 13, 2016
japaric pushed a commit that referenced this issue Aug 13, 2016
japaric pushed a commit that referenced this issue Aug 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants