[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,

On 03/05/2019 14:41, Wei Liu wrote:
On Fri, May 03, 2019 at 02:35:08PM +0100, Julien Grall wrote:
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?

I did. It worked. Though at this point I'm not sure why it worked. :-/

I think I know why, only the sections .text and .data are prefixed with .init. In the case of libelf, none of the GCOV symbols seems to be located in .data.

For libfdt, some of them are located in .data (renamed to .init.data). Hence the difference in behavior.

We should probably fixed the two libraries as this is quite fragile for libelf as well.

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®.