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

Cross testing against a naïve implementation #1108

Closed
BerryYoghurt opened this issue May 16, 2022 · 2 comments
Closed

Cross testing against a naïve implementation #1108

BerryYoghurt opened this issue May 16, 2022 · 2 comments

Comments

@BerryYoghurt
Copy link

Hi. I am an SoB intern working with @real-or-random as my mentor.

After reading #691 and going through the links provided there, I thought I could pick up where #641 left off.
In particular, I am planning to transpile the Rust library to C.

I know of two approaches to transpile Rust to C:

  1. Emit LLVM using rustc then use llvm-cbe to generate C.
  2. Use mrustc to generate C directly.

The LLVM approach seems not to work (neither clang nor gcc are happy with the generated C). So mrustc seems to be the way to go.

If anybody knows of a third way, I'd be happy to explore it too, just in case mrustc fails midway

@BerryYoghurt
Copy link
Author

mrustc has some parsing issues, but I haven't given up on it yet.

But I was thinking I could also emit assembly from cargo and then decompile this assembly to C, but I am not sure how feasible this is. I'd appreciate it if somebody could suggest tools or readings that might help with this.

@BerryYoghurt
Copy link
Author

It turns out that using mrustc to transpile ecc-scep356k1 is not feasible.
In order to use mrustc's transpiled output, we have to:

  1. Either vendor the transpiled version of libstd along with the transpiled ecc-scep356k1 (and this transpiled code is not cross-platform at that). This would bloat up the code added for cross-testing, and wouldn't be a very clean or maintainable solution.
  2. Or we have to re-write ecc-scep356k1 to not use anything from libcore. And I don't think the (machine-dependent and unreadable) end result would incentivize such an endeavor.

So, @elichai, thank you for promptly removing the GMP dependency, but unfortunately I've reached a dead-end and will not continue using ecc-scep356k1.

Moving forward, I am now planning on using libecc for cross-testing directly in C.

@real-or-random real-or-random closed this as not planned Won't fix, can't repro, duplicate, stale Apr 10, 2024
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

No branches or pull requests

2 participants