Thanks for bringing this up, Daniel!

I don't have a strong opinion, personally. I see how this makes things a
little easier for developers. No longer would we have to teach people that
to add a new debug flag you both declare it in the SConscript file and
include the named header file. Given that I've worked with gem5 for a long
time, I don't see that as much overhead, though.

This would increase the compile time (though, hopefully only rarely). And,
we recently found from the gem5 survey that people don't care that much
about the compile time (more info coming soon).

I think the biggest downside would be for those that use gem5 in teaching.
Students in architecture classes are the most likely to have underpowered
computers building gem5, and they are also likely to be adding debug flags.

Cheers,
Jason

On Fri, Jan 15, 2021 at 5:47 PM Daniel Carvalho via gem5-dev <
[email protected]> wrote:

> Hello all,
>
> I've uploaded a commit that re-joins the debug header files into a single
> one: https://gem5-review.googlesource.com/c/public/gem5/+/39255. This
> means that instead of having to include a different header for each and
> every debug flag used in a file, only one is needed. For example, in
> src/arch/arm/kvm/arm_cpu.cc
>
>     #include "debug/Kvm.hh"
>     #include "debug/KvmContext.hh"
>     #include "debug/KvmInt.hh"
>
> would be replaced by
>
>     #include "debug/flags.hh"
>
> Finally, since most of the code using these flags will use DPRINTF or a
> similar macro, this include could be added to base/trace.hh, so that most
> of the times it would be included transitively.
>
> The advantage of this change is that debugging becomes easier/faster: this
> file would behave as a library of supported flags and very few header
> files would suffice for all debugging needs. The disadvantage is that
> every time a commit introduces or removes a debug flag debug/flags.hh will
> be recompiled, which will cause an almost complete build. Luckily, debug
> flags are not frequently modified.
>
> Performance-wise both approaches are similar.
>
> What are your opinions in this matter?
>
> Cheers,
> Daniel
> _______________________________________________
> gem5-dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________
gem5-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Reply via email to