[Patch] libgcov.c re-factoring

Andrew MacLeod amacleod@redhat.com
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
>>> those.
>>> 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 mailing list