[Patch] libgcov.c re-factoring
Mon Jan 6 14:49:00 GMT 2014
On 01/06/2014 09:37 AM, Jan Hubicka wrote:
>> On 12/22/2013 01:27 PM, Jan Hubicka wrote:
>>> I believe when the code was created by moving it from elsehwre, the copyright should say
>>> original date of gcov-io.h.
>>>> +#include "tconfig.h"
>>>> +#include "tsystem.h"
>>>> +#include "coretypes.h"
>>>> +#include "tm.h"
>>>> +#include "libgcc_tm.h"
>>> I would really like someone working on header restructuring to comment on
>>> I am not 100% sure what our best practices currently are in respect of
>>> including headers within headers and specially after good amount of
>>> defines like gcov-io.h gets included.
>> Just back..
>> For the moment the goal with headers is to completely flatten them..
> OK. Seems sensible. I will push IPA/cgraph/symtab in this direction
> next stage1.
>> ie, we do not want to include header files from header files. Once
>> there is a sensible restructuring of things in place, we are likely
>> to reintroduce them in a controlled and sensible manner.
>> So at the moment, I'd like to not include any additional .h files
>> from within .h files...
> The situation here is slightly more slipperly than in other cases, since we
> have headers (gcov-io.h.h) that is shared across GCC coverage code and runtime
> (libgcov) and stand alone tools (gcov-tool and gcov).
> The header has several ifdefs that makes it to do the right thing in all 3 contexts
> that are different.
> The change in question is to pull out a lot of mess that is specific into runtime
> to libgcov specific header file that includes gcov-io.h later in game. In a way
> I see this as an improvement, since runtime bits are localized to place where
> rest of libgcov is (that is for some reason libgcc and not libgcov directory)
> rather than hidding it in geenral purpose header.
> I suppose it will also make easier to make libgcov portable to non-stdio based
> environments, like in kernel, that is google's desire.
> What would be preferred solution here?
Yeah, this isnt only a compiler header file, so what makes the most
sense may be different. The rationale for flattening the compiler
header files is to get a grasp on what is coming from where, regroup
things in a more logical manner, then possibly reintroduce a more
sensible include hierarchy.
If this is improving the locality of the runtime then I wouldnt worry
about it. we haven't gotten anywhere near that yet :-) I didnt
realize on first glance that it was a libgcc file. if we ever do get
that far, we can deal with it then :-) It isn't undoing anything we've
done so far.
More information about the Gcc-patches