On Thu, Oct 13, 2016 at 03:15:09AM -0600, Jan Beulich wrote:
> >>> On 13.10.16 at 10:49, wrote:
> > On Thu, Oct 13, 2016 at 02:29:08AM -0600, Jan Beulich wrote:
> > [...]
> >> >> >> ... this structure's trailing fields actually getting used by the
> >> >> >> code
> >> >> >> won't work well when c
>>> On 13.10.16 at 10:49, wrote:
> On Thu, Oct 13, 2016 at 02:29:08AM -0600, Jan Beulich wrote:
> [...]
>> >> >> ... this structure's trailing fields actually getting used by the code
>> >> >> won't work well when changing compiler versions without cleaning
>> >> >> the tree. I think instead you n
On Thu, Oct 13, 2016 at 02:29:08AM -0600, Jan Beulich wrote:
[...]
> >> >> ... this structure's trailing fields actually getting used by the code
> >> >> won't work well when changing compiler versions without cleaning
> >> >> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
> >> >> #d
>>> On 12.10.16 at 19:07, wrote:
> On Wed, Oct 12, 2016 at 09:42:17AM -0600, Jan Beulich wrote:
>> >>> On 12.10.16 at 17:33, wrote:
>> > On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
>> >> >>> On 11.10.16 at 12:31, wrote:
>> >> > --- /dev/null
>> >> > +++ b/xen/common/gcov/gcc_4_7
On 12.10.2016 18:21, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 12, 2016 at 04:17:57PM +0200, Martin Pohlack wrote:
On 12.10.2016 15:44, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
On 12.10.16 at 15:23, wrote:
And then - how is all of this suppose
On Wed, Oct 12, 2016 at 09:42:17AM -0600, Jan Beulich wrote:
> >>> On 12.10.16 at 17:33, wrote:
> > On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> >> >>> On 11.10.16 at 12:31, wrote:
> >> > --- /dev/null
> >> > +++ b/xen/common/gcov/gcc_4_7.c
> >> > @@ -0,0 +1,205 @@
> >> > +/*
>
On Wed, Oct 12, 2016 at 04:17:57PM +0200, Martin Pohlack wrote:
> On 12.10.2016 15:44, Konrad Rzeszutek Wilk wrote:
> > On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
> > > > > > On 12.10.16 at 15:23, wrote:
> > > > > And then - how is all of this supposed to be working in conjucnti
>>> On 12.10.16 at 17:33, wrote:
> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
>> >>> On 11.10.16 at 12:31, wrote:
>> > --- /dev/null
>> > +++ b/xen/common/gcov/gcc_4_7.c
>> > @@ -0,0 +1,205 @@
>> > +/*
>> > + * This code provides functions to handle gcc's profiling data format
On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> >>> On 11.10.16 at 12:31, wrote:
> > --- /dev/null
> > +++ b/xen/common/gcov/gcc_4_7.c
> > @@ -0,0 +1,205 @@
> > +/*
> > + * This code provides functions to handle gcc's profiling data format
> > + * introduced with gcc 4.7.
> > + *
On 12.10.2016 15:44, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
On 12.10.16 at 15:23, wrote:
And then - how is all of this supposed to be working in conjucntion
with live patching, where the patch may have been created by yet
another compiler ver
>>> On 12.10.16 at 15:44, wrote:
> On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
>> >>> On 12.10.16 at 15:23, wrote:
>> >> And then - how is all of this supposed to be working in conjucntion
>> >> with live patching, where the patch may have been created by yet
>> >> another compi
On 12/10/16 14:34, Andrew Cooper wrote:
> On 12/10/16 14:26, George Dunlap wrote:
>> On 12/10/16 14:24, George Dunlap wrote:
>>> On 12/10/16 14:06, Wei Liu wrote:
On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
On 11.10.16 at 12:31, wrote:
>> --- /dev/null
>> +++
On Wed, Oct 12, 2016 at 09:46:51AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 12, 2016 at 02:40:08PM +0100, Wei Liu wrote:
> > On Wed, Oct 12, 2016 at 09:29:04AM -0400, Konrad Rzeszutek Wilk wrote:
> > [...]
> > > >
> > > > Wouldn't it be just as easy, and more useful, to set a "has been
>
On Wed, Oct 12, 2016 at 02:40:08PM +0100, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 09:29:04AM -0400, Konrad Rzeszutek Wilk wrote:
> [...]
> > >
> > > Wouldn't it be just as easy, and more useful, to set a "has been
> > > livepatched" flag, and return errors for all gcov hypercalls if its' set?
> >
On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
> >>> On 12.10.16 at 15:23, wrote:
> >> And then - how is all of this supposed to be working in conjucntion
> >> with live patching, where the patch may have been created by yet
> >> another compiler version?
> >
> > Uh, I hope one doe
On 12/10/16 14:41, George Dunlap wrote:
> On 12/10/16 14:34, Andrew Cooper wrote:
>> On 12/10/16 14:26, George Dunlap wrote:
>>> On 12/10/16 14:24, George Dunlap wrote:
On 12/10/16 14:06, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> On 11.10.16 at
On Wed, Oct 12, 2016 at 09:29:04AM -0400, Konrad Rzeszutek Wilk wrote:
[...]
> >
> > Wouldn't it be just as easy, and more useful, to set a "has been
> > livepatched" flag, and return errors for all gcov hypercalls if its' set?
> >
> > I would expect most users to want to build a single hyperviso
On 12/10/16 14:26, George Dunlap wrote:
> On 12/10/16 14:24, George Dunlap wrote:
>> On 12/10/16 14:06, Wei Liu wrote:
>>> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
>>> On 11.10.16 at 12:31, wrote:
> --- /dev/null
> +++ b/xen/common/gcov/gcc_4_7.c
> @@ -0,0 +1,20
>>> On 12.10.16 at 15:26, wrote:
> On 12/10/16 14:24, George Dunlap wrote:
>> I would expect most users to want to build a single hypervisor that can
>> be used for both gcov testing and live patching (under different
>> circumstances).
>
> I mean software provider, not user, of course. That's w
On Wed, Oct 12, 2016 at 02:26:26PM +0100, George Dunlap wrote:
[...]
> >>
> >> There is a version field in gcov_info, so we can compare that and reject
> >> incompatible version.
> >>
> >> We need to use hooks in livepatching to call the constructor /
> >> destructor when applying / reverting a liv
>>> On 12.10.16 at 15:23, wrote:
>> And then - how is all of this supposed to be working in conjucntion
>> with live patching, where the patch may have been created by yet
>> another compiler version?
>
> Uh, I hope one does not create a livepatch patch with another compiler
> version!
>
> Let
On Wed, Oct 12, 2016 at 02:24:51PM +0100, George Dunlap wrote:
> On 12/10/16 14:06, Wei Liu wrote:
> > On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> > On 11.10.16 at 12:31, wrote:
> >>> --- /dev/null
> >>> +++ b/xen/common/gcov/gcc_4_7.c
> >>> @@ -0,0 +1,205 @@
> >>> +/*
> >>>
On 12/10/16 14:24, George Dunlap wrote:
> On 12/10/16 14:06, Wei Liu wrote:
>> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
>> On 11.10.16 at 12:31, wrote:
--- /dev/null
+++ b/xen/common/gcov/gcc_4_7.c
@@ -0,0 +1,205 @@
+/*
+ * This code provides funct
On 12/10/16 14:06, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> On 11.10.16 at 12:31, wrote:
>>> --- /dev/null
>>> +++ b/xen/common/gcov/gcc_4_7.c
>>> @@ -0,0 +1,205 @@
>>> +/*
>>> + * This code provides functions to handle gcc's profiling data format
>>> +
> And then - how is all of this supposed to be working in conjucntion
> with live patching, where the patch may have been created by yet
> another compiler version?
Uh, I hope one does not create a livepatch patch with another compiler version!
Let me put on the TODO to make livepatch-build-tools
>>> On 12.10.16 at 15:06, wrote:
> But I have no idea how useful it would be to use gcov and livepatching
> together. For now the easiest thing to do is to
>
>depends on !LIVEPATCH
>
> in Kconfig.
I agree.
Jan
___
Xen-devel mailing list
Xen-de
On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> >>> On 11.10.16 at 12:31, wrote:
> > --- /dev/null
> > +++ b/xen/common/gcov/gcc_4_7.c
> > @@ -0,0 +1,205 @@
> > +/*
> > + * This code provides functions to handle gcc's profiling data format
> > + * introduced with gcc 4.7.
> > + *
>>> On 11.10.16 at 12:31, wrote:
> --- /dev/null
> +++ b/xen/common/gcov/gcc_4_7.c
> @@ -0,0 +1,205 @@
> +/*
> + * This code provides functions to handle gcc's profiling data format
> + * introduced with gcc 4.7.
> + *
> + * This file is based heavily on gcc_3_4.c file.
> + *
> + * For a bette
A new sysctl interface for passing gcov data back to userspace. The new
interface uses a customised record file format. The new sysctl reuses
original sysctl number but renames the op to gcov_op.
Both gcc 3.4 and 4.7 format are supported. The code is rewritten so that
a new format can be easily ad
29 matches
Mail list logo