-
Notifications
You must be signed in to change notification settings - Fork 143
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
[Bluesim] Simulation executable fails with undefined symbol: _Z21vcd_write_scope_startP9tSimStatePKc
#704
Comments
In my experience, this error occurs when you are using a BSC that was compiled with different C++ compiler version (or different C++ compiler flags) than you are currently using. When you use BSC to generate a Bluesim executable, BSC generates C++ code, compiles that code, and then links it with the Bluesim kernel library in BSC. The error occurs when the C++ compiler you are currently using is unable to find the symbols in the pre-compiled Bluesim kernel library, because the kernel library was encoded with a different ABI version than what your current C++ compiler is expecting. This can happen when you compile BSC with GCC v3 and then try to run BSC with GCC v4 (for example). Or it can happen if you've given a flag to GCC to tell it to use a different ABI than its default (either when compiling BSC or when running BSC). For example, the following flag:
My suggestion is to double-check that you are using a BSC that was compiled in the same environment that you are running in, and check that the above flag has not been provided. I don't believe that GHC packages like |
I've done some further investigation that points to a The environment is always consistent between compilation and testing the issue. Updating, rebuilding, reinstalling, and rebooting didn't help. The flag you are pointing to seems to be for compatibility, so I don't think that's enabled on Arch, which generally uses the latest features available. The Anyway, seems to be an Arch specific packaging issue, therefore I'm closing this. |
Yep, that update enabled LTO by default. Disabling LTO fixes the issue.
I guess LTO falls under different ABI. To make this compatible with LTO, |
If you want to pass additional flags to the C or C++ compiler, you can do so by setting However, I'm still unclear why there's a mismatch between the build of BSC and your execution of BSC. If LTO was enabled by default, it should apply to both the build of BSC and the execution of BSC, and no additional flag would be needed. If BSC was built with an explicit |
BSC will also consult |
Checking out your suggestions, none fixed the issue. I don't think there's a problem with the environment. The section I opened an issue that might be related over at pacman/pacman#150. Packages get stripped of debug symbols, maybe that also removes necessary functions. The environmentBy convention, Arch packages are built in a clean chroot. It's not enforced, but it's best practice. This is done for reproducibility and repeatability as the build environment is always the same between builds and between systems, solely depending on the build instructions within the PKGBUILD. Additionally, this means the packager should ensure that the resulting package works no matter the environment on the final machine; The package only installs files and dependencies. The user is of course free to do whatever if the program allows it. During testing, I have installed the package (and FibOne.bsv) into the chroot and run the tests there, so the environment is exactly identical. This is a bit hacky, but it works. It has to work for debugging purposes. After testing, the chroot is easily cleaned again. So, running this
results in:
Notably, *FLAGS contains
Even with proof that |
@quark17 The solution is to add |
If I understand, from reading someone else's issue here, the |
I've done some benchmarking and building with |
Hi,
compiling a BSV program using
bsc
and thebluesim
backend, the following error occurs:Solution
The GCC option
-ffat-lto-objects
needs to be added when building with LTO enabled (See also here).Investigation
From my testing, the issue occurs consistently and is repeatable. The missing symbol is also always the same for the given example, though it does vary depending on the program (e.g. with a different program,
_ZN8WideDataD1Ev
was missing, error is otherwise identical).Using
c++filt
to decode the symbols yieldsvcd_write_scope_start(tSimState*, char const*)
andWideData::~WideData()
This only affects the BlueSim backend, the Verilog backend works as expected.
The issue seems correlated with asyb
upgrade.Are you able to reproduce the error when building with
syb 0.7.2.4
?Edit: Further investigation points to LTO (Link-Time-Optimisation) being an issue. Disabling LTO via the
!lto
option in thePKGBUILD
fixes the issue.Steps to reproduce
bsc -u -sim -simdir . -bdir . -info-dir . -keep-fires -p %/Libraries -g mkFibOne FibOne.bsv
bsc -e mkFibOne -sim -o ./out -simdir . -p %/Libraries -bdir . -keep-fires
./out
System information
OS: Arch Linux
Kernel: 6.7.4.arch1-1
GHC: 9.0.2-3
GCC: 13.2.1-5
glibc: 2.39-1
haskell-split: 0.2.5
bsc: e6f95a7 (current master)
Appendix
error.log
The text was updated successfully, but these errors were encountered: