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

Uninitialized data written to dependency file, if executable is found from PATH #1385

Closed
veripoolbot opened this issue Jan 4, 2019 · 3 comments
Assignees
Labels
resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor


Author Name: Al Grant
Original Redmine Issue: 1385 from https://www.veripool.org

Original Assignee: Wilson Snyder (@wsnyder)


The Perl script (i.e. "verilator") tries various ways to find the executable ("verilator_bin") one of which is to fall back to PATH:

$bin = $basename;  # Find in PATH

When this happens, verilator_bin is called with argv[0] set to just "verilator_bin". This adds "verilator_bin" as a dependency and then when V3FileDependImp::writeTimes() is called, loadStats() will try to stat("verilator_bin") and fail (stat doesn't search PATH), but this failure isn't checked and writeTimes() will write data from uninitialized memory to the dependency file.

It's simple enough to check for failure but it would be good to write the correct dependency. One way would be to do the PATH lookup explicitly, either in the Perl wrapper or in the executable, but a neater solution under Linux might be to ignore argv[0] and use readlink("/proc/self/exe") to get the actual executable name.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Al Grant
Original Date: 2019-01-04T11:12:13Z


Also the same thing happens if you bypass the Perl script and use

verilator_bin --cc mytop.v

Everything seems to work except it puts some uninitialized data in Vmytop__verFiles.dat.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-01-05T09:58:17Z


Uninit problem fixed in git towards 4.010.

I tried a patch using the exe name, but this causes a problem in that generated makefiles use the whole pathname which breaks some distributed build systems with differing paths. It's also not easily portable to windows.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-01-28T12:32:28Z


In 4.010.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution: fixed Closed; fixed
Projects
None yet
Development

No branches or pull requests

2 participants