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
> indepen
> 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
"Joseph S. Myers" 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
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
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 mor