Hi Gabriel. One big reason not to use shared libraries is performance,
although that doesn't mean the idea is without merit. In the long term, I
would like to give gem5 a kconfig like configuration mechanism, where you
could specify things to be built into gem5 itself, things to be excluded,
and things that would be loadable at run time. Things get a bit complicated
with gem5's python integration and SimObjects, but I'm hoping it will be
doable. There are a lot of steps between here and there and some things
need to be prioritized over others, but this is something I'm hoping to
improve in the long run.
Gabe
On Thu, Apr 15, 2021 at 4:05 AM gabriel.busnot--- via gem5-users <
gem5-users@gem5.org> wrote:
> 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
>
___
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
