Re: [PATCH v2] arm32: Avoid using solaris syntax for .section directive

[Julien Grall <julien@xxxxxxx>]

Hi Jan,

On 02/08/2023 09:01, Jan Beulich wrote:
> On 02.08.2023 09:54, Julien Grall wrote:
> > On 02/08/2023 08:22, Jan Beulich wrote:
> > > On 01.08.2023 23:02, Julien Grall wrote:
> > > > Title: This patch is not arm32 specific anymore. So I would replace
> > > > 'arm32' with 'arm'. This can be done on commit.
> > > >
> > > > On 01/08/2023 18:49, Khem Raj wrote:
> > > > > Assembler from binutils 2.41 rejects [1] this syntax
> > > > >
> > > > > .section "name"[, flags...]
> > > > >
> > > > > where flags could be #alloc, #write, #execinstr, #exclude, and #tls [2]
> > > > >
> > > > > It is almost like a regression compared to 2.40 or older release,
> > > > The next word after ',' start with an uppercase. Did you intend to use
> > > > '.' rather than ','?
> > > >
> > > > That said, the documentation has the following:
> > > >
> > > > For SPARC ELF targets, the assembler supports another type of .section
> > > > directive for compatibility with the Solaris assembler:"
> > > But note that "SPARC" was added there only by the commit introducing the
> > > perceived regression.
> > Yes, I noticed it while replying yesterday. I still would not describe
> > it as a regression mainly because I am not convinced binutils will
> > revert the change and it feels like a good move.
> I agree as to it being unlikely that the change is going to be (partly)
> reverted, unless someone strongly advocated for it. It also wouldn't be
> of much use to us, unless a 2.41.1 was cut very soon.
>
> > Also, regarding your point about older tree on the bug report. I don't
> > think we guarantee that stable works all new toolchain without any change.
> We don't guarantee that, no, but I think it is in our own interest to
> keep things building with the newest tool chains. When build-testing
> stable tree commits before pushing, I don't want to always have to
> remember to force the build to use an older tool chain, when normally
> my build rune would default to a pretty up-to-date one.
This is where gitlab would definitely help because we can keep 
containers around to build older Xen versions.
>  This is also
> why for this specific class of changes I typically prefer to see them
> also go onto the security-only stable trees.
I am ok if this is backported to older tree. This is trivial enough.

Cheers,

--
Julien Grall