cvut / QtMips

MIPS CPU emulator
https://github.com/cvut/QtMips
GNU General Public License v3.0
55 stars 12 forks source link

Development status #13

Closed TheEdward162 closed 2 years ago

TheEdward162 commented 3 years ago

Hi, I attend PAP course this year and I'm trying to build QtMips on my macbook from source. The newest available version of Qt is 6 and brew is weird so without thinking I installed that and quickly ran into compilation errors. Those errors weren't hard to fix so now I have a patch/PR that makes this project compile with both qt5 and qt6 (there are a few changes that require an #if, otherwise the changes are backwards compatible with latest qt5).

Anyway, I'm not sure which branch to target. I see master hasn't received much attention lately, then there's devel which has quite a few commits on top of master and I also see the very active fork that's going in the direction of risc-v. So my question is whether to target this repo's master, or if devel is going to get merged at some point or if I should just forget it and build with qt5?

By the way: There are also some libelf issues with the devel branch (missing elf.h header in homebrew libelf package) so maybe it would be worth including a local fallback the same way as the risc-v fork does and build libelf from source on macos?

ppisa commented 3 years ago

Hello Edward,

thanks for testing and update, compatibility with Qt6 is welcomed. As for the project, MIPS simulator version waits for some our or somebody other time.

Our actual main effort is RISC-V simulator QtRvSim. But that project has stuck on requirement to clean commits from @hollmmax bachelor theses. The state of his series is out of requirements for readable project history.

As for QtMIPS, there has been done significant preparatory work for RISC-V in MIPS project the first. @jdupak has rewritten memory model of the simulator which allows both big and little-endian support. These changes are included in QtMips devel branch. The change is not critical for use of MIPS version for our actual teaching but interesting side effect is that simulator can read little-endian MIPS ELF executables now and switch to EL mode for them. EL mode MIPS are used prevails today and it allows to use even OpwnWrt and Microchip PIC32 MIPS toolchains. So for QtMIPS codebase devel is the branch to target and test. But devel has not been tested enough by me yet to declare it as master. The reports that it works fine helps us to become confident and push that into master eventually.

As for the libelf, on GNU/Linux it is better to use full featured system provided libelf, but to allow Windows build without headaches and (more important) emscripten/wasm builds, the there is maintained libelf-included in the repo. It can be rebased above devel or included in devel, but it shodul be done such way, the default build is against system provided lib and local version is used only if requested.

As for build system, QtRvSim has switched to CMake and @jdupak has prepared clean packaging which has chance to be accepted by distributions. The work is in the VIP branch rv-packaging in QtRvSim VIP repo https://github.com/hollmmax/QtMips/commits/rv-packaging .

Summary: minor cleanups and ifdefs for comparability with Qt6 (but keeping Qt5 working) are welcomed for QtMips devel branch. Minor updates for packaging as well. Switch to CMake solution form QtRvSim is preferred if bigger upgrade of MIPS version is intended. As for libelf, it is not idel to include limited/old version in master and even devel branch, but it is possible if it is not used by default. I prefer separate branch with included libelf which is rebased above devel. Testing is welcome and goal is to propagate devel to QtMips master. Main effort, which worth to be done and people from more universities are waiting to it is clean of QtRvSim.

Best wishes,

Pavel Pisa

TheEdward162 commented 3 years ago

Thanks, I've opened a #14 to add support for qt6. I'll look into possible solutions for the outdated libelf on macos and open another PR if I find a good solution.

jdupak commented 3 years ago

@kchasialis backported my cmake to his QtMips fork, so if necessary, we can take the adjusted code from him. That build has automatic fallback to local libelf if dynlib is not found (or if explicitly requested). However the current libelf code is has problems with up to date glibc (on Arch/Manjaro). So I would like to replace it with better alternative (maybe from llvm).

ppisa commented 3 years ago

As for libelf ad Clang, there is progress,

For example elfutils which is an established alternative to GNU binutils
will also support building with Clang in its next release (v0.186).

from A tale of two toolchains and glibc