[PATCH v2] coverage: filter out libfdt.o and libelf.o

[PATCH v2] coverage: filter out libfdt.o and libelf.o

[Viktor Mitin]

The patch resolves 'xencov' crashes in case of Aarch64.

All the .init.* sections are stripped after boot,
it means that anything in .init.data cannot be accessed anymore.
The build system explicitly compiles any .init binary without gcov option.
The problem is coming from libfdt and libelf.
The entire library is moved to .init using:
$(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
So we need to tell the top Makefile to filter out libfdt and libelf.

Reported-by: Viktor Mitin <viktor.mitin.19@gmail.com>
Suggested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Viktor Mitin <viktor.mitin.19@gmail.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Tested-by: Viktor Mitin <viktor.mitin.19@gmail.com>

---

Changes from v1:

 - coverage: filtered out libelf as well
---
 xen/common/libelf/Makefile | 1 +
 xen/common/libfdt/Makefile | 1 +
 2 files changed, 2 insertions(+)

diff --git a/xen/common/libelf/Makefile b/xen/common/libelf/Makefile
index 5bf8f764f1..3d9e38f27e 100644
--- a/xen/common/libelf/Makefile
+++ b/xen/common/libelf/Makefile
@@ -1,4 +1,5 @@
 obj-bin-y := libelf.o
+nocov-y += libelf.o
 
 SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
 
diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
index d81f54b6b8..c075bbf546 100644
--- a/xen/common/libfdt/Makefile
+++ b/xen/common/libfdt/Makefile
@@ -3,6 +3,7 @@ include Makefile.libfdt
 SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
 
 obj-y += libfdt.o
+nocov-y += libfdt.o
 
 CFLAGS += -I$(BASEDIR)/include/xen/libfdt/
 
-- 
2.17.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2] coverage: filter out libfdt.o and libelf.o

[Viktor Mitin]

The patch resolves 'xencov' crashes in case of Aarch64.

All the .init.* sections are stripped after boot,
it means that anything in .init.data cannot be accessed anymore.
The build system explicitly compiles any .init binary without gcov option.
The problem is coming from libfdt and libelf.
The entire library is moved to .init using:
$(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
So we need to tell the top Makefile to filter out libfdt and libelf.

Reported-by: Viktor Mitin <viktor.mitin.19@gmail.com>
Suggested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Viktor Mitin <viktor.mitin.19@gmail.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Tested-by: Viktor Mitin <viktor.mitin.19@gmail.com>

---

Changes from v1:

 - coverage: filtered out libelf as well
---
 xen/common/libelf/Makefile | 1 +
 xen/common/libfdt/Makefile | 1 +
 2 files changed, 2 insertions(+)

diff --git a/xen/common/libelf/Makefile b/xen/common/libelf/Makefile
index 5bf8f764f1..3d9e38f27e 100644
--- a/xen/common/libelf/Makefile
+++ b/xen/common/libelf/Makefile
@@ -1,4 +1,5 @@
 obj-bin-y := libelf.o
+nocov-y += libelf.o
 
 SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
 
diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
index d81f54b6b8..c075bbf546 100644
--- a/xen/common/libfdt/Makefile
+++ b/xen/common/libfdt/Makefile
@@ -3,6 +3,7 @@ include Makefile.libfdt
 SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
 
 obj-y += libfdt.o
+nocov-y += libfdt.o
 
 CFLAGS += -I$(BASEDIR)/include/xen/libfdt/
 
-- 
2.17.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2] coverage: filter out libfdt.o and libelf.o

[Julien Grall]

Hi Viktor,

Thank you for the quick respin. I have some comments below regarding the commit 
message and process.

On 16/05/2019 14:20, Viktor Mitin wrote:
> The patch resolves 'xencov' crashes in case of Aarch64.
> 
> All the .init.* sections are stripped after boot,
> it means that anything in .init.data cannot be accessed anymore.
> The build system explicitly compiles any .init binary without gcov option.
> The problem is coming from libfdt and libelf.

This is not entirely correct, libelf is not built for Arm so it can't cause a 
crash. However libelf exposes the same problem as libfdt.

> The entire library is moved to .init using:

The sentence here...

> $(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@

... does not match the command here. $(SECTIONS) only contain a subset of all 
the sections. For instance, BSS is not renamed.

This is the reason why the issues is not seen on x86. Libelf seems to have all 
GCOV variables in region not renamed.

> So we need to tell the top Makefile to filter out libfdt and libelf.

How about the following commit message:

"coverage: filter out libfdt.o libelf.o

While the build system explicitly compiles any .init object without gcov option, 
this does not cover the libraries libfdt and libelf. This is because the two
libraries are built normally and then some sections will have .init append.

As coverage will be enabled for libfdt, some of the GCOV counters may be stored 
in a section that will be stripped after init. On Arm64, this will reliably 
result to a crash when 'xencov' will ask to reset the counters.

Interestingly, on x86, all the counters for libelf seems to be in sections that 
will not be renamed so far. Hence, why this was not discovered before. But this 
is a latent bug.

As the two libraries can only be used at boot, it is fine to disable coverage 
for the entire library.
"

> 
> Reported-by: Viktor Mitin <viktor.mitin.19@gmail.com>
> Suggested-by: Julien Grall <julien.grall@arm.com>
> Signed-off-by: Viktor Mitin <viktor.mitin.19@gmail.com>
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Reviewed-by: Wei Liu <wei.liu2@citrix.com>

Reviewed-by tag mean the person has carefully reviewed your code and is happy 
with it. As you extend the purpose of the patch, it is custom to either remove 
the tag or ask the person is happy with the change. For this time, I have asked 
Wei on IRC and he is still happy with it.

> Tested-by: Viktor Mitin <viktor.mitin.19@gmail.com>

You are the author of the patch, so it is not necessary. If you send a patch you 
usually test it and therefore the meaning sort of carried in signed-off-by :).

No need to resend the patch, I can do the modification when I will commit the patch.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] coverage: filter out libfdt.o and libelf.o

[Julien Grall]

Hi Viktor,

Thank you for the quick respin. I have some comments below regarding the commit 
message and process.

On 16/05/2019 14:20, Viktor Mitin wrote:
> The patch resolves 'xencov' crashes in case of Aarch64.
> 
> All the .init.* sections are stripped after boot,
> it means that anything in .init.data cannot be accessed anymore.
> The build system explicitly compiles any .init binary without gcov option.
> The problem is coming from libfdt and libelf.

This is not entirely correct, libelf is not built for Arm so it can't cause a 
crash. However libelf exposes the same problem as libfdt.

> The entire library is moved to .init using:

The sentence here...

> $(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@

... does not match the command here. $(SECTIONS) only contain a subset of all 
the sections. For instance, BSS is not renamed.

This is the reason why the issues is not seen on x86. Libelf seems to have all 
GCOV variables in region not renamed.

> So we need to tell the top Makefile to filter out libfdt and libelf.

How about the following commit message:

"coverage: filter out libfdt.o libelf.o

While the build system explicitly compiles any .init object without gcov option, 
this does not cover the libraries libfdt and libelf. This is because the two
libraries are built normally and then some sections will have .init append.

As coverage will be enabled for libfdt, some of the GCOV counters may be stored 
in a section that will be stripped after init. On Arm64, this will reliably 
result to a crash when 'xencov' will ask to reset the counters.

Interestingly, on x86, all the counters for libelf seems to be in sections that 
will not be renamed so far. Hence, why this was not discovered before. But this 
is a latent bug.

As the two libraries can only be used at boot, it is fine to disable coverage 
for the entire library.
"

> 
> Reported-by: Viktor Mitin <viktor.mitin.19@gmail.com>
> Suggested-by: Julien Grall <julien.grall@arm.com>
> Signed-off-by: Viktor Mitin <viktor.mitin.19@gmail.com>
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Reviewed-by: Wei Liu <wei.liu2@citrix.com>

Reviewed-by tag mean the person has carefully reviewed your code and is happy 
with it. As you extend the purpose of the patch, it is custom to either remove 
the tag or ask the person is happy with the change. For this time, I have asked 
Wei on IRC and he is still happy with it.

> Tested-by: Viktor Mitin <viktor.mitin.19@gmail.com>

You are the author of the patch, so it is not necessary. If you send a patch you 
usually test it and therefore the meaning sort of carried in signed-off-by :).

No need to resend the patch, I can do the modification when I will commit the patch.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2] coverage: filter out libfdt.o and libelf.o

[Viktor Mitin]

On Thu, May 16, 2019 at 06:40:14PM +0100, Julien Grall wrote:
> 
> No need to resend the patch, I can do the modification when I will commit the patch.
> 

Hi Julien,

Thank you for detailed description provided. 
Will take into consideration all the notes.

Thanks


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] coverage: filter out libfdt.o and libelf.o

[Viktor Mitin]

On Thu, May 16, 2019 at 06:40:14PM +0100, Julien Grall wrote:
> 
> No need to resend the patch, I can do the modification when I will commit the patch.
> 

Hi Julien,

Thank you for detailed description provided. 
Will take into consideration all the notes.

Thanks


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2] coverage: filter out libfdt.o and libelf.o

[Julien Grall]

On 17/05/2019 07:47, Viktor Mitin wrote:
> On Thu, May 16, 2019 at 06:40:14PM +0100, Julien Grall wrote:
>>
>> No need to resend the patch, I can do the modification when I will commit the patch.
>>
> 
> Hi Julien,

Hi,

> 
> Thank you for detailed description provided.
> Will take into consideration all the notes.

Does it mean you are happy with the commit message I suggested?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] coverage: filter out libfdt.o and libelf.o

[Julien Grall]

On 17/05/2019 07:47, Viktor Mitin wrote:
> On Thu, May 16, 2019 at 06:40:14PM +0100, Julien Grall wrote:
>>
>> No need to resend the patch, I can do the modification when I will commit the patch.
>>
> 
> Hi Julien,

Hi,

> 
> Thank you for detailed description provided.
> Will take into consideration all the notes.

Does it mean you are happy with the commit message I suggested?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2] coverage: filter out libfdt.o and libelf.o

[Viktor Mitin]

> > Thank you for detailed description provided.
> > Will take into consideration all the notes.
>
> Does it mean you are happy with the commit message I suggested?

Yes, I'm happy with the commit message you suggested.
Please let me know if I should resend the updated patch.

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] coverage: filter out libfdt.o and libelf.o

[Viktor Mitin]

> > Thank you for detailed description provided.
> > Will take into consideration all the notes.
>
> Does it mean you are happy with the commit message I suggested?

Yes, I'm happy with the commit message you suggested.
Please let me know if I should resend the updated patch.

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2] coverage: filter out libfdt.o and libelf.o

[Julien Grall]

Hi,

On 20/05/2019 12:09, Viktor Mitin wrote:
>>> Thank you for detailed description provided.
>>> Will take into consideration all the notes.
>>
>> Does it mean you are happy with the commit message I suggested?
> 
> Yes, I'm happy with the commit message you suggested.
> Please let me know if I should resend the updated patch.

No need to resend it. I will commit it with the updates I mentioned in my e-mail.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] coverage: filter out libfdt.o and libelf.o

[Julien Grall]

Hi,

On 20/05/2019 12:09, Viktor Mitin wrote:
>>> Thank you for detailed description provided.
>>> Will take into consideration all the notes.
>>
>> Does it mean you are happy with the commit message I suggested?
> 
> Yes, I'm happy with the commit message you suggested.
> Please let me know if I should resend the updated patch.

No need to resend it. I will commit it with the updates I mentioned in my e-mail.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel