Hi all,
I would like to know what is your favorite way to run the ECD cycle with this
gem5.debug beast of a binary.
I am currently developing a pretty large Ruby protocol and use 2 build
configurations: debug and fasta for "fast with asserts". I've defined the fasta
build target myself and detail it bellow.
I've carefully seasoned my code with asserts in order to catch as many bugs as
possible without relying on gdb. I catch about 2/3 of the bugs that way I would
say.
The rest of the time, which is often more than 20 times a day, I must fall back
to the debug target to have gem5 debug flags enabled and usable gdb information.
So, what is the fasta target? It is the regular fast target...
- with asserts (because segfault-based debugging sucks)
- without LTO and stripping (for much faster link time)
- without -Werror (because I don't want "unused variable errors" while
developing).
How does it perform? 20s compile time and close-ish to "fast" binary speeds.
Now, why not use only the debug target? 1'40" compile time, 10" uncompressible
platform elaboration time, 20" to load symbols in gdb: 2'+ uncompressible time
to compile and run gem5 under GDB.
Why not use the opt target instead? ~3min compile time due to LTO and unusable
gdb due to optimization, anyway.
This brings me to the question: why doesn't gem5 make use of shared libraries,
at least to speedup build time in debug mode?
Ideally, one could even specify which modules need debug info and which don't.
In my case, I would only include ruby-related debug info for instance.
"Compile+Run in GDB" time could shrink down to less than 5s total that way.
What do you think of it?
I don't know much about SCons but with a few pointers to start, I could take a
look at it and eventually submit a patch if I am happy with the results.
Cheers,
Gabriel Busnot
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
