All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Mygaiev <Artem_Mygaiev@epam.com>
To: "sstabellini@kernel.org" <sstabellini@kernel.org>,
	"julien.grall.oss@gmail.com" <julien.grall.oss@gmail.com>
Cc: Andrii Anisov <Andrii_Anisov@epam.com>,
	"dgdegra@tycho.nsa.gov" <dgdegra@tycho.nsa.gov>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"andrii.anisov@gmail.com" <andrii.anisov@gmail.com>
Subject: Re: [Xen-devel] [RFC 6/7] arm: Introduce dummy empty functions for data only C files
Date: Thu, 14 Nov 2019 13:32:29 +0000	[thread overview]
Message-ID: <c2332971dece50cfdc75b0c71a8a20b9f29716bb.camel@epam.com> (raw)
In-Reply-To: <CAJ=z9a2ORW7NbPKTny=oNux0jSAY+vGkAWK1XQ+QS=gTQryPYQ@mail.gmail.com>

Hello Julien

On Thu, 2019-11-14 at 08:03 +0900, Julien Grall wrote:
> 
> 
> On Tue, 12 Nov 2019, 05:57 Stefano Stabellini, <
> sstabellini@kernel.org> wrote:
> > On Wed, 6 Nov 2019, Andrii Anisov wrote:
> > > From: Andrii Anisov <andrii_anisov@epam.com>
> > > 
> > > ARM Compiler 6 has a proven bug: it compiles data only C files
> > with
> > > SoftVFP attributes. This leads to a failed linkage afterwards
> > with
> > > an error:
> > > 
> > > Error: L6242E: Cannot link object built_in.o as its attributes
> > are incompatible with the image attributes.
> > > ... A64 clashes with SoftVFP.
> > > 
> > > The known workaround is introducing some code into the affected
> > file,
> > > e.g. an empty (non-static) function is enough.
> > 
> > Oh man, this is truly horrible.
> > 
> > If we really have to do this please:
> > 
> > - use the same dummy function name in all files
> > - the function should be static
> > - hiding the function within a #ifdef ARMCC block
> > - potentially hide the whole horrible hack behind a #define so that
> > it
> >   would become at the call site:
> > 
> >  +ARMCC_DUMMY_FUNC_HACK()
> 
> 
> The risk here is we may introduce new file in the future possibly in
> common code with similar issues. So I would prefer if we can find an
> automatic way to do this. Some ideas:
>     - Add the function at compile time (via makefile). This would be
> done for all the files but that's should not be a major issues.
>     - Force disable softfvp either via command line, new line in the
> code or rewriting the attribute of the object.
> 
> But before spending time trying to workaround a buggy compiler.
> What's the plan with it? Is it going to be used in production or just
> a demo?

This is not intended for a production program at the moment, and it
obviously require lot of further work. I would not try to upstream ugly
workarounds for issues like the one above, it would be much better to
somehow persuade Arm tools team to properly fix them.

This RFC series has following goals:
1) prove that we can use safety-certified tools for Xen and avoid
possible arguments on compiler/linker certification path
2) research possible issues when using non-standard compiler/linker and
try to see if it is easy to adjust Xen to use them

In the end, it would be great to make Xen build system flexible enough
to use with non-standard compilers without overcomplicating it or changing it significantly, causing too much disruption to community.

> Cheers,
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> 
> https://urldefense.com/v3/__https://lists.xenproject.org/mailman/listinfo/xen-devel__;!K6dmGCEab4ueJg!kCpXu2prtUxCHZV8aCvxYk9E82KnsHuNftyCeG745Ei3vhO2VP_SYXDnItHeZZCwdw$
>  
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-11-14 13:33 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06  9:19 [Xen-devel] [RFC 0/7] Build XEN with ARM Compiler 6.6.3 Andrii Anisov
2019-11-06  9:19 ` [Xen-devel] [RFC 1/7] xen: clang: Support correctly cross-compile Andrii Anisov
2019-11-06 11:07   ` Wei Liu
2019-11-06 15:24   ` Jan Beulich
2019-11-18  6:08   ` Julien Grall
2019-11-06  9:19 ` [Xen-devel] [RFC 2/7] WIP: Compilation with ARM DS-6 compiler Andrii Anisov
2019-11-06 15:28   ` Jan Beulich
2019-11-06 22:08     ` Artem Mygaiev
2019-11-07  7:31       ` Jan Beulich
2019-11-13 17:15         ` Artem Mygaiev
2019-11-13 23:19           ` Julien Grall
2019-11-14 14:12             ` Artem Mygaiev
2019-11-18  6:18               ` Julien Grall
2019-11-19 15:16                 ` Artem Mygaiev
2019-11-19 16:13                   ` Julien Grall
2019-11-06  9:19 ` [Xen-devel] [RFC 3/7] arm64:armds: ARM Compiler 6.6 does not accept `rx` registers naming for AArch64 Andrii Anisov
2019-11-06 15:32   ` Jan Beulich
2019-11-11 20:49     ` Stefano Stabellini
2019-11-13  5:56   ` Julien Grall
2019-11-06  9:19 ` [Xen-devel] [RFC 4/7] arm/gic: Drop pointless assertions Andrii Anisov
2019-11-11 20:52   ` Stefano Stabellini
2019-11-13  1:14     ` Julien Grall
2019-11-20 22:15       ` Stefano Stabellini
2019-11-06  9:19 ` [Xen-devel] [RFC 5/7] WIP:arm64:armds: Build XEN with ARM Compiler 6.6 Andrii Anisov
2019-11-11 21:26   ` Stefano Stabellini
2019-11-13  5:50     ` Julien Grall
2019-11-14 11:31       ` Andrii Anisov
2019-11-18  7:03         ` Julien Grall
2019-11-14 11:14     ` Andrii Anisov
2019-11-20 22:56       ` Stefano Stabellini
2019-11-06  9:19 ` [Xen-devel] [RFC 6/7] arm: Introduce dummy empty functions for data only C files Andrii Anisov
2019-11-11 20:57   ` Stefano Stabellini
2019-11-13 16:41     ` Andrii Anisov
2019-11-13 23:03     ` Julien Grall
2019-11-14 13:32       ` Artem Mygaiev [this message]
2019-11-20 22:20         ` Stefano Stabellini
2019-11-13  5:51   ` Julien Grall
2019-11-13 17:07     ` Andrii Anisov
2019-11-06  9:19 ` [Xen-devel] [RFC 7/7] arm/gic-v3: add GIC version suffix to iomem range variables Andrii Anisov
2019-11-11 20:59   ` Stefano Stabellini
2019-11-13  1:25     ` Julien Grall
2019-11-14  8:35     ` Andrii Anisov
2019-11-20 22:23       ` Stefano Stabellini
2019-11-21  9:05         ` Andrii Anisov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c2332971dece50cfdc75b0c71a8a20b9f29716bb.camel@epam.com \
    --to=artem_mygaiev@epam.com \
    --cc=Andrii_Anisov@epam.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrii.anisov@gmail.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=julien.grall.oss@gmail.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.