[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort



Hi Wei,

On 5/3/19 12:08 PM, Wei Liu wrote:
On Thu, May 02, 2019 at 09:43:17PM +0100, Julien Grall wrote:
(+ Wei)

On 5/2/19 5:55 PM, Viktor Mitin wrote:
Hi Julien,

Hi,

Please find trace log below:

root@h3ulcb:~# xencov reset
(XEN) Data Abort Trap. Syndrome=0x7
(XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
So this is a data abort when trying to access VA 0x361700 (it is part of Xen
itself). I misread the Arm Arm before, while ISV is 0 DFSC will still
provide a correct value. So here we have a "Translation fault, level 3".

Which makes sense because ...


(XEN) 0TH[0x0] = 0x0000000078265f7f
(XEN) 1ST[0x0] = 0x0000000078262f7f
(XEN) 2ND[0x1] = 0x004000007825ff7f
(XEN) 3RD[0x161] = 0x00600000781e1f7e

the 3rd entry is not valid. I managed to reduce the error and it looks like
gcov is trying to access a counter in the section init.data.

As all the .init.* sections are stripped after boot, it means that anything
in .init.data cannot be accessed anymore.

Wei, how do you deal with counters in init.data on x86?

The build system explicitly compile any .init binary without gcov
option. So maybe some file was not correctly added?

Thank you for the pointer. The problem is coming from libfdt. 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. The patch below should do the job:

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/

While looking at the code, I noticed libelf is also built with coverage but in .init section. So I would expect the same error on x86, did you try "xencov reset" on x86?

Cheers,

--
Julien Grall

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.