GNU assembler will consider '/' as the start of comment marker on some
platforms. This is incorrect with Xen's usage, which does use '/' in
assembly files as a mathematical operator.
The behavior of the assembler can be altered by passing the --divide
option; unconditionally pass this option when available to force the
expected behavior.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
xen/Makefile | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/xen/Makefile b/xen/Makefile
index 31352d4cd260..eee0262933a7 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -405,6 +405,11 @@ $(call cc-option-add,CFLAGS,CC,-Winit-self)
CFLAGS += -pipe -D__XEN__ -include $(srctree)/include/xen/config.h
CFLAGS-$(CONFIG_DEBUG_INFO) += -g
+# The GNU assembler will interpret '/' as a comment start marker instead of a
+# divide on some platforms. Pass --divide when when available to signal '/' is
+# always used as an operator in assembly.
+$(call cc-option-add,CFLAGS,CC,-Wa$$(comma)--divide)
+
ifneq ($(CONFIG_CC_IS_CLANG),y)
# Clang doesn't understand this command line argument, and doesn't appear to
# have a suitable alternative. The resulting compiled binary does function,
--
2.51.0
Hi Roger, > On 10 Feb 2026, at 16:11, Roger Pau Monne <roger.pau@citrix.com> wrote: > > GNU assembler will consider '/' as the start of comment marker on some > platforms. This is incorrect with Xen's usage, which does use '/' in > assembly files as a mathematical operator. > > The behavior of the assembler can be altered by passing the --divide > option; unconditionally pass this option when available to force the > expected behavior. This is solving the issue and I can build for arm with what and further for x86 on mac os but it fails on check-endbr.sh: /bin/sh ../tools/check-endbr.sh xen-syms stat: illegal option -- c Cheers Bertrand > > Reported-by: Jan Beulich <jbeulich@suse.com> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> > --- > xen/Makefile | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/xen/Makefile b/xen/Makefile > index 31352d4cd260..eee0262933a7 100644 > --- a/xen/Makefile > +++ b/xen/Makefile > @@ -405,6 +405,11 @@ $(call cc-option-add,CFLAGS,CC,-Winit-self) > CFLAGS += -pipe -D__XEN__ -include $(srctree)/include/xen/config.h > CFLAGS-$(CONFIG_DEBUG_INFO) += -g > > +# The GNU assembler will interpret '/' as a comment start marker instead of a > +# divide on some platforms. Pass --divide when when available to signal '/' is > +# always used as an operator in assembly. > +$(call cc-option-add,CFLAGS,CC,-Wa$$(comma)--divide) > + > ifneq ($(CONFIG_CC_IS_CLANG),y) > # Clang doesn't understand this command line argument, and doesn't appear to > # have a suitable alternative. The resulting compiled binary does function, > -- > 2.51.0 >
On Tue, Feb 10, 2026 at 03:44:33PM +0000, Bertrand Marquis wrote: > Hi Roger, > > > On 10 Feb 2026, at 16:11, Roger Pau Monne <roger.pau@citrix.com> wrote: > > > > GNU assembler will consider '/' as the start of comment marker on some > > platforms. This is incorrect with Xen's usage, which does use '/' in > > assembly files as a mathematical operator. > > > > The behavior of the assembler can be altered by passing the --divide > > option; unconditionally pass this option when available to force the > > expected behavior. > > This is solving the issue and I can build for arm with what and further > for x86 on mac os but it fails on check-endbr.sh: > > /bin/sh ../tools/check-endbr.sh xen-syms > stat: illegal option -- c Yeah, I know. I've fixed the stat issue, but there's a further one about an illegal bit sequence in grep. I'm looking into that. Thanks, Roger.
Hi Roger > On 10 Feb 2026, at 16:55, Roger Pau Monné <roger.pau@citrix.com> wrote: > > On Tue, Feb 10, 2026 at 03:44:33PM +0000, Bertrand Marquis wrote: >> Hi Roger, >> >>> On 10 Feb 2026, at 16:11, Roger Pau Monne <roger.pau@citrix.com> wrote: >>> >>> GNU assembler will consider '/' as the start of comment marker on some >>> platforms. This is incorrect with Xen's usage, which does use '/' in >>> assembly files as a mathematical operator. >>> >>> The behavior of the assembler can be altered by passing the --divide >>> option; unconditionally pass this option when available to force the >>> expected behavior. >> >> This is solving the issue and I can build for arm with what and further >> for x86 on mac os but it fails on check-endbr.sh: >> >> /bin/sh ../tools/check-endbr.sh xen-syms >> stat: illegal option -- c > > Yeah, I know. I've fixed the stat issue, but there's a further one > about an illegal bit sequence in grep. I'm looking into that. LC_ALL=C grep is fixing that one on my side with that and stat -c replaced with wc -c < xx I can fully compile x86 on Mac os. Cheers Bertrand > > Thanks, Roger.
On Tue, Feb 10, 2026 at 03:57:17PM +0000, Bertrand Marquis wrote: > Hi Roger > > > On 10 Feb 2026, at 16:55, Roger Pau Monné <roger.pau@citrix.com> wrote: > > > > On Tue, Feb 10, 2026 at 03:44:33PM +0000, Bertrand Marquis wrote: > >> Hi Roger, > >> > >>> On 10 Feb 2026, at 16:11, Roger Pau Monne <roger.pau@citrix.com> wrote: > >>> > >>> GNU assembler will consider '/' as the start of comment marker on some > >>> platforms. This is incorrect with Xen's usage, which does use '/' in > >>> assembly files as a mathematical operator. > >>> > >>> The behavior of the assembler can be altered by passing the --divide > >>> option; unconditionally pass this option when available to force the > >>> expected behavior. > >> > >> This is solving the issue and I can build for arm with what and further > >> for x86 on mac os but it fails on check-endbr.sh: > >> > >> /bin/sh ../tools/check-endbr.sh xen-syms > >> stat: illegal option -- c > > > > Yeah, I know. I've fixed the stat issue, but there's a further one > > about an illegal bit sequence in grep. I'm looking into that. > > LC_ALL=C grep is fixing that one on my side I haven't tested that one yet, but yes, might be a way to solve. Would you like to send the fix for grep? > with that and stat -c replaced with wc -c < xx I can fully compile x86 on Mac os. Yeah, the problem with using wc is that you have to read the file. I prefer $(($(du <file> |cut -w -f1) << 9)) because that avoids reading the actual data to count. Thanks, Roger.
Hi Roger, > On 10 Feb 2026, at 17:09, Roger Pau Monné <roger.pau@citrix.com> wrote: > > On Tue, Feb 10, 2026 at 03:57:17PM +0000, Bertrand Marquis wrote: >> Hi Roger >> >>> On 10 Feb 2026, at 16:55, Roger Pau Monné <roger.pau@citrix.com> wrote: >>> >>> On Tue, Feb 10, 2026 at 03:44:33PM +0000, Bertrand Marquis wrote: >>>> Hi Roger, >>>> >>>>> On 10 Feb 2026, at 16:11, Roger Pau Monne <roger.pau@citrix.com> wrote: >>>>> >>>>> GNU assembler will consider '/' as the start of comment marker on some >>>>> platforms. This is incorrect with Xen's usage, which does use '/' in >>>>> assembly files as a mathematical operator. >>>>> >>>>> The behavior of the assembler can be altered by passing the --divide >>>>> option; unconditionally pass this option when available to force the >>>>> expected behavior. >>>> >>>> This is solving the issue and I can build for arm with what and further >>>> for x86 on mac os but it fails on check-endbr.sh: >>>> >>>> /bin/sh ../tools/check-endbr.sh xen-syms >>>> stat: illegal option -- c >>> >>> Yeah, I know. I've fixed the stat issue, but there's a further one >>> about an illegal bit sequence in grep. I'm looking into that. >> >> LC_ALL=C grep is fixing that one on my side > > I haven't tested that one yet, but yes, might be a way to solve. > Would you like to send the fix for grep? > >> with that and stat -c replaced with wc -c < xx I can fully compile x86 on Mac os. > > Yeah, the problem with using wc is that you have to read the file. I > prefer $(($(du <file> |cut -w -f1) << 9)) because that avoids reading > the actual data to count. Both fixes should be included in the same patch. Will submit one once we agree on the solution for stat -c. I suggested: wc -c < "$TEXT_BIN" Tell me if that works for you. Cheers Bertrand > > Thanks, Roger.
On 10.02.2026 17:09, Roger Pau Monné wrote: > On Tue, Feb 10, 2026 at 03:57:17PM +0000, Bertrand Marquis wrote: >> Hi Roger >> >>> On 10 Feb 2026, at 16:55, Roger Pau Monné <roger.pau@citrix.com> wrote: >>> >>> On Tue, Feb 10, 2026 at 03:44:33PM +0000, Bertrand Marquis wrote: >>>> Hi Roger, >>>> >>>>> On 10 Feb 2026, at 16:11, Roger Pau Monne <roger.pau@citrix.com> wrote: >>>>> >>>>> GNU assembler will consider '/' as the start of comment marker on some >>>>> platforms. This is incorrect with Xen's usage, which does use '/' in >>>>> assembly files as a mathematical operator. >>>>> >>>>> The behavior of the assembler can be altered by passing the --divide >>>>> option; unconditionally pass this option when available to force the >>>>> expected behavior. >>>> >>>> This is solving the issue and I can build for arm with what and further >>>> for x86 on mac os but it fails on check-endbr.sh: >>>> >>>> /bin/sh ../tools/check-endbr.sh xen-syms >>>> stat: illegal option -- c >>> >>> Yeah, I know. I've fixed the stat issue, but there's a further one >>> about an illegal bit sequence in grep. I'm looking into that. >> >> LC_ALL=C grep is fixing that one on my side > > I haven't tested that one yet, but yes, might be a way to solve. > Would you like to send the fix for grep? > >> with that and stat -c replaced with wc -c < xx I can fully compile x86 on Mac os. > > Yeah, the problem with using wc is that you have to read the file. I > prefer $(($(du <file> |cut -w -f1) << 9)) because that avoids reading > the actual data to count. But shifting by hardcoded 9 doesn't look very portable. The size not being exact may be okay for the purposes here, but wouldn't it then be better to use (standardized) ls output? Jan
Hi, > On 10 Feb 2026, at 17:15, Jan Beulich <jbeulich@suse.com> wrote: > > On 10.02.2026 17:09, Roger Pau Monné wrote: >> On Tue, Feb 10, 2026 at 03:57:17PM +0000, Bertrand Marquis wrote: >>> Hi Roger >>> >>>> On 10 Feb 2026, at 16:55, Roger Pau Monné <roger.pau@citrix.com> wrote: >>>> >>>> On Tue, Feb 10, 2026 at 03:44:33PM +0000, Bertrand Marquis wrote: >>>>> Hi Roger, >>>>> >>>>>> On 10 Feb 2026, at 16:11, Roger Pau Monne <roger.pau@citrix.com> wrote: >>>>>> >>>>>> GNU assembler will consider '/' as the start of comment marker on some >>>>>> platforms. This is incorrect with Xen's usage, which does use '/' in >>>>>> assembly files as a mathematical operator. >>>>>> >>>>>> The behavior of the assembler can be altered by passing the --divide >>>>>> option; unconditionally pass this option when available to force the >>>>>> expected behavior. >>>>> >>>>> This is solving the issue and I can build for arm with what and further >>>>> for x86 on mac os but it fails on check-endbr.sh: >>>>> >>>>> /bin/sh ../tools/check-endbr.sh xen-syms >>>>> stat: illegal option -- c >>>> >>>> Yeah, I know. I've fixed the stat issue, but there's a further one >>>> about an illegal bit sequence in grep. I'm looking into that. >>> >>> LC_ALL=C grep is fixing that one on my side >> >> I haven't tested that one yet, but yes, might be a way to solve. >> Would you like to send the fix for grep? >> >>> with that and stat -c replaced with wc -c < xx I can fully compile x86 on Mac os. >> >> Yeah, the problem with using wc is that you have to read the file. I >> prefer $(($(du <file> |cut -w -f1) << 9)) because that avoids reading >> the actual data to count. > > But shifting by hardcoded 9 doesn't look very portable. The size not being > exact may be okay for the purposes here, but wouldn't it then be better to > use (standardized) ls output? Suggesting this: wc -c < "$TEXT_BIN" Bertrand
On 10.02.2026 16:11, Roger Pau Monne wrote: > GNU assembler will consider '/' as the start of comment marker on some > platforms. This is incorrect with Xen's usage, which does use '/' in > assembly files as a mathematical operator. > > The behavior of the assembler can be altered by passing the --divide > option; unconditionally pass this option when available to force the > expected behavior. I'm fine with this in principle, but I wonder: What about Clang? If it's properly compatible, it ought to also take '/' as a comment char for those same targets (in particular for the plain "x86_64-elf" one). According to godbolt it can't deal with -Wa,--divide, yet there I also can't control what exact target the toolchain supports (i.e. this may be only a weak indication of lack of support / compatibility). > --- a/xen/Makefile > +++ b/xen/Makefile > @@ -405,6 +405,11 @@ $(call cc-option-add,CFLAGS,CC,-Winit-self) > CFLAGS += -pipe -D__XEN__ -include $(srctree)/include/xen/config.h > CFLAGS-$(CONFIG_DEBUG_INFO) += -g > > +# The GNU assembler will interpret '/' as a comment start marker instead of a > +# divide on some platforms. Could I talk you into s/on some platforms/for some ELF targets/ ? A more fundamental question is: Do we really mean to support (allow) building with arbitrary-target toolchains? There are other subtle differences, which may be hard to evaluate as to them possibly affecting the Xen build. > Pass --divide when when available to signal '/' is > +# always used as an operator in assembly. > +$(call cc-option-add,CFLAGS,CC,-Wa$$(comma)--divide) I don't think this should be done here: --divide is an x86-specific option. Jan
On Tue, Feb 10, 2026 at 04:27:33PM +0100, Jan Beulich wrote: > On 10.02.2026 16:11, Roger Pau Monne wrote: > > GNU assembler will consider '/' as the start of comment marker on some > > platforms. This is incorrect with Xen's usage, which does use '/' in > > assembly files as a mathematical operator. > > > > The behavior of the assembler can be altered by passing the --divide > > option; unconditionally pass this option when available to force the > > expected behavior. > > I'm fine with this in principle, but I wonder: What about Clang? If it's > properly compatible, it ought to also take '/' as a comment char for > those same targets (in particular for the plain "x86_64-elf" one). > According to godbolt it can't deal with -Wa,--divide, yet there I also > can't control what exact target the toolchain supports (i.e. this may be > only a weak indication of lack of support / compatibility). Hm, I'm unsure I can get such a Clang build to properly test it. Note the checking for the presence of the option would also be done in Clang. I would like to think if Clang integrated assembler has this behavior the option to select our expected behavior will also be --divide. I think that's the best I can do ATM. > > --- a/xen/Makefile > > +++ b/xen/Makefile > > @@ -405,6 +405,11 @@ $(call cc-option-add,CFLAGS,CC,-Winit-self) > > CFLAGS += -pipe -D__XEN__ -include $(srctree)/include/xen/config.h > > CFLAGS-$(CONFIG_DEBUG_INFO) += -g > > > > +# The GNU assembler will interpret '/' as a comment start marker instead of a > > +# divide on some platforms. > > Could I talk you into s/on some platforms/for some ELF targets/ ? Yes, that's fine IMO. > A more fundamental question is: Do we really mean to support (allow) > building with arbitrary-target toolchains? There are other subtle > differences, which may be hard to evaluate as to them possibly affecting > the Xen build. Hm, TBH I wasn't aware of such subtle and annoying differences until today, so I'm not sure what to reply here. I haven't tested the x86 image yet, as I'm still attempting to resolve some non-POSIX options usage in check-endbr.sh. We might want to state which ELF targets we do explicitly support for production usage. TBH I doubt anyone would use a Darwin build for production. > > Pass --divide when when available to signal '/' is > > +# always used as an operator in assembly. > > +$(call cc-option-add,CFLAGS,CC,-Wa$$(comma)--divide) > > I don't think this should be done here: --divide is an x86-specific > option. Oh, that wasn't clear from the output of as. I can make it x86-specific then. However, is there any chance of this behavior escaping outside of x86, and hence would we like to ensure this behavior on all possible arches? Or is it possible that other arches re-use the --divide option for some other functionality? Thanks, Roger.
On 10.02.2026 16:53, Roger Pau Monné wrote: > On Tue, Feb 10, 2026 at 04:27:33PM +0100, Jan Beulich wrote: >> On 10.02.2026 16:11, Roger Pau Monne wrote: >>> Pass --divide when when available to signal '/' is >>> +# always used as an operator in assembly. >>> +$(call cc-option-add,CFLAGS,CC,-Wa$$(comma)--divide) >> >> I don't think this should be done here: --divide is an x86-specific >> option. > > Oh, that wasn't clear from the output of as. I can make it > x86-specific then. However, is there any chance of this behavior > escaping outside of x86, and hence would we like to ensure this > behavior on all possible arches? > > Or is it possible that other arches re-use the --divide option for > some other functionality? It is equally possible for that to happen (if some target needs to support '/' as a comment char) as it is for such a target to then use an entirely different command line option. Furthermore, --divide may mean something else on another arch. Jan
© 2016 - 2026 Red Hat, Inc.