rev.ng Blog

rev.ng | Frontend Software Engineer | Milan HQ or remote | https://rev.ng rev.ng is building the next-generation LLVM-based decompiler. We're looking for a developer with experience in modern C++ and/or Qt, (including QtQuick and QML). We're developing an interactive UI for our decompiler, based on QtCreator, the Qt IDE. Topics you will work on: * Development of the user-facing API for the our analysis engine backend * Development of the Qt-based GUI for our decompiler * Joint effort with professional UX designers to build a great user experience for the GUI * Graph layout and rendering, on graphs representing large-scale programs * Handling of a custom, YAML-based RPC mechanism to offload long computations rev.ng is a dish best served static. [email protected]

A cool company fueled by one of the best PLT books out there: https://link.springer.com/book/10.1007/978-3-662-03811-6 "He also met a partner in crime, Pietro. Romantically enough, he met him thanks to a book which will turn out to be foundational for company." https://rev.ng/about Congrats on the launch.

This is neat. I recall not long ago seeing a presentation on rev.ng [1] [2], which has some similarity to RetDec. [1] https://rev.ng/ [2] http://llvm.org/devmtg/2016-11/Slides/DiFederico-rev.ng.pdf

I think this finally answers a question I've had since I started learning programming. All my life I've been told "you can't convert a shared library to a static library". When you try to probe for more details, all you get is some mumbling about how a shared library is already prelinked for mapping into memory so the relocation table is lost. When you press further about the precise information loss that prevents you from reconstructing it, you get the equivalent of "you just can't ok!". That was never satisfying to me because recompilation (decompiling to source code or IR that can be recompiled for another platform) is an academic field of study [1], so the problem of converting a shared library to a static one should be easier. After all, you have all the assembly and symbol information right there, it seemed like all you needed to do was massage it the right way. [1] https://rev.ng/

As others have said, the standardization of metrics is still something debated, but at the same time, this space has been explored by various top-tier papers that your paper did not cite. For example, DREAM [1], evaluated using the classic metric of goto-emittence. Rev.ng [2], evaluated using Cyclomatic Complexity and gotos. SAILR [3], evaluated using the previous metrics and a Graph Edit Distance score for the structure of the code. I feel that without a justification for dropping previously established metrics by the peer review process, you weaken your new metrics. However, I still think this is an interesting paper. It just could be made more legit by thoroughly reading/citing previous work in the area and building an argument for why you may go against it. [1]: https://net.cs.uni-bonn.de/fileadmin/ag/martini/Staff/yakdan/dream_nds… [2]: https://rev.ng/downloads/asiaccs-2020-paper.pdf [3]: https://www.usenix.org/system/files/sec23winter-prepub-301-basque.pdf

Checking the team about: https://rev.ng/about And looking at the code contributions: https://github.com/revng/revng/graphs/contributors Isn't it a bit weird that the CEO (aleclearmind) has most commits, even much more than the CTO (pfez)? I often hear the complaints from other CEOs that they don't really find any time anymore to code... Even the CTO usually is more on the managing side and less active in actual coding. Anyway, if this works, then I guess it's a lot of fun for them. Edit Ah right, I didn't check the timeline.

You can do a lot with just bash + pipes + unix tools. It can get messy as your pipeline grows though, and there are a lot of edge cases. Relevant: "bashML: Why Spark when you can Bash?" (https://rev.ng/blog/bashml/post.html), aka how to deduplicate git repositories using `comm` + `awk`.