Help with Warning on ARM

[Joel Sherrill]

On Mon, Aug 4, 2025 at 2:06 AM Jan Beulich <jbeulich@suse.com> wrote:

> On 01.08.2025 16:54, Joel Sherrill wrote:
> > Hi
> >
> > Over at RTEMS, we have this bit of code which is included with every
> > build of RTEMS on all architectures. It is a special section to
> > auto-load pretty printing scripts.
> >
> > asm( \
> >   ".pushsection \".debug_gdb_scripts\", \"MS\",@progbits,1\n" \
> >   ".byte 4\n" \
> >   ".ascii \"gdb.inlined-script\\n\"\n" \
> >   ".ascii \"import sys\\n\"\n" \
> >   ".ascii \"import os.path\\n\"\n" \
> >   ".ascii \"sys.path.append(os.path.join(gdb.PYTHONDIR,
> 'rtems'))\\n\"\n" \
> >   ".ascii \"import rtems.pprinter as pprinter\\n\"\n" \
> >   ".byte 0\n" \
> >   ".popsection\n" \
> >   );
> >
> > On all ARM builds but no other architecture, we get this message:
> >
> > /tmp/ccVjIfxL.s: Assembler messages:
> > /tmp/ccVjIfxL.s:19: missing merge / string entity size, 1 assumed
> >
> > Any suggestions on what isn't 100% right?
> >
> > Also, analyzing build logs, I have noticed that the assembler uses
> > Warning not warning like GCC. This was surprising when I noticed
> > that my scripts never reported warnings from as. And in this case,
> > it is just a message.  Isn't this a warning?
>
> Thing is that this particular diagnostic, from an assembler-internal pov,
> isn't a warning. While as_warn() and alike would emit "Warning: " as a
> prefix, it's as_tsktsk() here (the important difference here being that
> this way it doesn't "officially" count as a warning, and hence doesn't
> affect building with --fatal-warnings). Considering the comment ahead of
> it, making it also emit "Warning: " probably would be appropriate, though.
> Going through its uses (Arm in particular uses this a lot), I can spot a
> few which open-code the prefixing of "Warning: ", so some tidying would
> want doing at the same time (plus whatever testsuite fallout there might
> be).
>

The code that started this was added by a GSoC participant last year.
None of us noticed the "message" because it didn't follow the pattern
we expected. It's recent and not a surprise we missed it.

We have another case where "Warning" is present in some PowerPC
exception helpers. That code hasn't changed since 2008 according to
git blame. I have no idea how long "as" has given that Warning. Clearly
it has slipped through for a while.

I'm not blaming this on anyone. RTEMS has 18 architecture ports with
all using multilibs even for 32/64 bit RISC-V and PowerPC. Personally,
I switched RTEMS to GNU tools around 1991-2. None of us ever noticed
these different messages. Admittedly, the individual BSP logs are too
large to look for issues by hand. We usually grep for "warning:" and
clearly
that is insufficient. My point is that from a user perspective, it wasn't
clear
we should also look for Warning and message.

We do see that tool updates trigger new warnings and we only
find those via reporting tools. I have augmented the search pattern to
include Warning and "assembler message".

If this was a small code base with only a few targets, I am sure these
messages would be spotted by hand.

Is this variance in diagnostics that anyone else has had issues because
of before us?

--joel



> Jan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20250804/83839ea7/attachment.htm>