[build] Move libgcov support to toplevel libgcc

And another easy one: moving libgcov over to libgcc.

Bootstrapped without regressions on i386-pc-solaris2.11 and
x86_64-unknown-linux-gnu.

Ok for mainline?

After this one, and once the problems with the unwinder move are sorted
out, I've got a few more:

* gthr is just in the planning stage

* fp-bit is almost ready

* soft-fp just started to investigate

* libgcc_tm_file only an idea

	Rainer


2011-07-02  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	gcc:
	* Makefile.in (LIBGCOV): Remove.
	(libgcc.mvars): Remove LIBGCOV.
	* libgov.c: Move to ../libgcc.

	libgcc:
	* Makfile.in (LIBGCOV): New variable.
	($(libgcov-objects)): Use $(srcdir) to refer to libgcov.c.
	* libgcov.c: New file.

diff --git a/gcc/libgcov.c b/libgcc/libgcov.c
rename from gcc/libgcov.c
rename to libgcc/libgcov.c

On 07/08/2011 01:31 PM, Rainer Orth wrote:
> And another easy one: moving libgcov over to libgcc.
>
> Bootstrapped without regressions on i386-pc-solaris2.11 and
> x86_64-unknown-linux-gnu.
>
> Ok for mainline?
>
> After this one, and once the problems with the unwinder move are sorted
> out, I've got a few more:
>
> * gthr is just in the planning stage
>
> * fp-bit is almost ready
>
> * soft-fp just started to investigate
>
> * libgcc_tm_file only an idea
>
> 	Rainer
>

Ok!

Paolo

On Fri, 8 Jul 2011, Rainer Orth wrote:

> And another easy one: moving libgcov over to libgcc.

Do you have any specific plans regarding gcov-io.c and gcov-io.h?  Because 
they are genuinely used on both the host and the target they are a 
trickier case; I wonder if they should end up in their own toplevel 
directory like libdecnumber, building a proper library that exports 
different functions when configured for the host than for the target, that 
for the target gets included in libgcov and that for the host gets linked 
into cc1, gcov and gcov-dump rather than having files do the present 
'#include "gcov-io.c"'.

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> On Fri, 8 Jul 2011, Rainer Orth wrote:
>
>> And another easy one: moving libgcov over to libgcc.
>
> Do you have any specific plans regarding gcov-io.c and gcov-io.h?  Because 

None so far: the issues outlined in the libgcov submission are currently
the end of what I plan to do on this front.

	Rainer

> On Fri, 8 Jul 2011, Rainer Orth wrote:
> 
> > And another easy one: moving libgcov over to libgcc.
> 
> Do you have any specific plans regarding gcov-io.c and gcov-io.h?  Because 
> they are genuinely used on both the host and the target they are a 
> trickier case; I wonder if they should end up in their own toplevel 
> directory like libdecnumber, building a proper library that exports 
> different functions when configured for the host than for the target, that 
> for the target gets included in libgcov and that for the host gets linked 
> into cc1, gcov and gcov-dump rather than having files do the present 
> '#include "gcov-io.c"'.

I would also preffer libgcov to go into its own toplevel directory,
especially because there are plans to add non-stdlib i/o into it i.e.
for kernel profiling.  that way it would be handy to have libgcov
as a toplevel library with its own configure that allows it to be build
independently of rest of GCC.

Honza
> 
> -- 
> Joseph S. Myers
> joseph@codesourcery.com

Jan,

> I would also preffer libgcov to go into its own toplevel directory,
> especially because there are plans to add non-stdlib i/o into it i.e.
> for kernel profiling.  that way it would be handy to have libgcov
> as a toplevel library with its own configure that allows it to be build
> independently of rest of GCC.

I'm probably not going to try that.  There's so much cleanup possible in
the toplevel libgcc move as is that will keep me busy for some time
(provided that I can testing and approval for the parts I can't easily
test myself ;-).

	Rainer