Message ID | 20190516132016.8032-1-viktor.mitin.19@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v2] coverage: filter out libfdt.o and libelf.o | expand |
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,
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
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,
> > 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
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,
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/