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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, May 03, 2019 at 03:16:52PM +0100, Julien Grall wrote:
> > > 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.
> 

Thanks for the analysis.

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

Sounds good to me.

Wei.

> 
> Cheers,
> 
> -- 
> Julien Grall
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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