tum-ei-eda / etiss

Extendable Translating Instruction Set Simulator
https://tum-ei-eda.github.io/etiss/
Other
29 stars 36 forks source link

fix windows build #130

Closed rafzi closed 1 year ago

rafzi commented 1 year ago

see: https://github.com/tum-ei-eda/etiss/pull/126#issuecomment-1422913016

it seems like we had a little patch in simpleini.h that avoided to include windows.h

https://github.com/tum-ei-eda/etiss/commit/f53752f66621b07583ff64efd6d236af550b17d5#diff-46b3be838bc4b17ea1d3f87af7b24c5b5951af73dd5f08bc76dfbc4feedfdefdL3175

we now have to work around this issue after including simpleini.

rafzi commented 1 year ago

nevermind, this issue is already fixed by https://github.com/tum-ei-eda/etiss/pull/128

we could still think about adding the undef there so that we may use our ReturnCode::NOERROR there as well.

JoGei commented 1 year ago

nevermind, this issue is already fixed by #128

we could still think about adding the undef there so that we may use our ReturnCode::NOERROR there as well.

endif

https://github.com/tum-ei-eda/etiss/blob/52650d03e6ca332f9cfc63242a501fda818f3e1b/include_c/etiss/jit/ReturnCode.h#L155-L164

I am not sure what the problem is exactly. But I understand it as follows: The defineReturnCode(NOERROR, 0, "No error."); macro is defining a new preprocessor macro ETISS_RETURNCODE_NOERROR only if it's not C++, so for example in the JIT code?

In C++, e.g., ETISS main loop a class is generated something like: ReturnCode::NOERROR which would result in the same symbol NOERROR that the Windows header introduces through simpleini?

Do the namespaces not help to distinguish between the two symbols?

github-actions[bot] commented 1 year ago

Performance Statistics

Status for the gcc Just-In-Time Engine (for commit eb6f5d2c): No significant performance change Current dhrystone MIPS for gcc JIT : 98.0 Previous best for gcc JIT (recorded in commit 4d2d26fb): 108.31, difference -9.51%

Status for the llvm Just-In-Time Engine (for commit eb6f5d2c): Regressed since commit 78716e7f Current dhrystone MIPS for llvm JIT : 23.26 Previous best for llvm JIT (recorded in commit 940dbdd7): 36.11, difference -35.60%

Status for the tcc Just-In-Time Engine (for commit eb6f5d2c): No significant performance change Current dhrystone MIPS for tcc JIT : 57.35 Previous best for tcc JIT (recorded in commit 4d2d26fb): 58.28, difference -1.60%

This comment was created automatically, please do not change!

rafzi commented 1 year ago

@JoGei Yes, the issue is about the C++ case. Unfortunately the namespaces do not help, because windows.h defines it as macro.

E.g. #define NOERROR somejunk would result ReturnCode::NOERROR to be compiled as ReturnCode::somejunk.

See: https://github.com/tum-ei-eda/etiss/actions/runs/4125557770/jobs/7126271826#step:10:11

JoGei commented 1 year ago

Ok, now https://github.com/tum-ei-eda/etiss/blob/52650d03e6ca332f9cfc63242a501fda818f3e1b/include_c/etiss/jit/ReturnCode.h#L157-L160

works, because the simpleini include, which could reintroduce this windows include, is not invoked everytime something includes ETISS.h?

rafzi commented 1 year ago

Yeah, but I still added the undef for when we ever wanted to use NOERROR in ETISS.cpp: https://github.com/tum-ei-eda/etiss/commit/6af172add7b38e5ccf3137618b27b1aab06e110f