This is a hard problem to solve. The existing "unit" tests, ie the ones found in src/unittest/, were generally not unit tests in the sense that they had all of gem5 built into them, and they drove it to do something in particular. There are multiple problems with that that you've pointed out, including that the size of the binaries really adds up, and that all those dependencies means you're not testing a single thing, you're focusing on a single thing but exercising large portions of gem5. Code you're not trying to test might make the code you are trying to test fail. That makes it harder to use the tests to identify where the bad code is and how it's bad, in my mind one of the primary benefits of having unit tests.
I think writing a test in that style isn't great generally speaking, but it's a way you could write the tests you're trying to write today. Trying to break those dependencies (with a mock for instance, like you suggested) would really help make things much more unit-test-able and is probably a good idea in the long term. All these testing techniques are something I'm learning about myself so I don't have a lot of great insight to offer, but to me it sounds like the most viable long term solution, if a bit painful to implement. Gabe On Tue, Sep 4, 2018 at 8:16 AM Nikos Nikoleris <[email protected]> wrote: > Hi folks, > > I would like to create a couple of unit tests in gem5 using the included > google test library. Some of these unit test instantiate objects which > inherit from SimObject and as a result the code depends on a lot of > other classes. > > The dependency tree proved to be quite big and instead of trying to > specify of all of the dependencies one by one, I decided to link all > object files that we typically link for the gem5 binary. That worked but > the result was a 700MB (opt) binary, obviously not good for just one of > the many unit tests we would like to have. By stripping it (fast target) > I can get it down to 30MB, definitely an improvement but still not > ideal. Then I was checking if there is a way to tell the linker to > discard unused code and tried adding the compiler options > -ffunction-sections and -fdata-sections linker option -gc-sections but > it didn't seem to work even when I tried disabling partial linking. Does > any of you know, if there is a way to do this? > > An easy solution would be to build gem5 as a shared lib and dynamically > link all gtests against it. Alternatively we could have mock versions of > base classes such as SimObject to link with but I am a bit worried that > this wouldn't be simple and in some cases it wouldn't exercise the same > code as gem5. > > Any thoughts or ideas? > > Thanks, > > Nikos > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
