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

[Julien Grall <julien.grall@xxxxxxx>]

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