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...@gmail.com>
Suggested-by: Julien Grall <julien.gr...@arm.com>
Signed-off-by: Viktor Mitin <viktor.mitin...@gmail.com>
Acked-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Wei Liu <wei.l...@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...@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
