This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Generate coverage informations in different sections.
- From: Frediano Ziglio <frediano dot ziglio at citrix dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 17 Jun 2013 16:41:13 +0100
- Subject: Re: Generate coverage informations in different sections.
- References: <4BE945389935F64490EB1C02F3502F630253D7 at LONPEX01CL01 dot citrite dot net> <20130617153227 dot GI2605 at atrey dot karlin dot mff dot cuni dot cz>
On Mon, 2013-06-17 at 17:32 +0200, Jan Hubicka wrote:
> > Hi,
> > I'm a Xen developer. We have coverage support (lcov replacement) in
> > order to extract coverage information. However would be very helpful to
> > have a way to put counters, structures and strings (file names) related
> > to coverage in different section. Actually there are no such options (it
> > would be better for us to separate counters and structures/strings).
>
> You mean to have something like .text.gcov/.data.gcov etc to place the counters?
> I suppose it is not that hard to implement, but I wonder how it is going to help
> you?
>
> Honza
If you put all gcov info in a section of memory (say an array of bytes)
you can then dump them and pass the base pointer for fixup and split the
tool that parse this blob.
In this case the problem is that Xen have no file system support so
currently there is some code in Xen itself that build a blob based on
all gcov information to get exported. If data are contiguous in memory
and in a specific area you can just dump this memory section as raw data
without having to worry about gcc chnages in the future (supposing the
sections are still the same).
Actually you could even share the memory between Xen and userspace in
order to achieve it.
Frediano
> >
> > I tried to change generated .s files in order to separate these
> > informations but without success (I'm not so expert with gas, last gcc
> > require common section).
> >
> > Is it difficult to implement such a feature in next gcc?
> >
> > Do somebody have a better idea?
> >
> > Frediano
> >