Help with Warning on ARM

[Joel Sherrill]

I have no complaints about changing this one character in that assembly
code that is intended to be target independent. I appreciate the quick
answer.
Honestly, even if this had changed in the last binutils release, I wouldn't
complain. :)

My long whine was a reflection that I have been working to reduce
warnings in RTEMS source code. I accidentally found we have had
a few warnings/messages from as for a long time and no one noticed.
I attribute that to us looking for "warning:" not "Warning:" or "message".

I was just wondering if this is just us or a broader usability issue? We
can't
be the only ones not looking for the as diagnostic patterns in log files.

--joel

On Mon, Aug 4, 2025 at 9:46 AM Christophe Lyon <christophe.lyon@arm.com>
wrote:

>
>
> On 8/4/25 16:01, Jan Beulich wrote:
> > On 04.08.2025 15:53, Joel Sherrill wrote:
> >> On Mon, Aug 4, 2025 at 2:06 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>> On 01.08.2025 16:54, Joel Sherrill wrote:
> >>>> 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?
> >
> > I fear I don't quite understand the question; it almost feels as if a
> word
> > or two were missing somewhere. (From what I can guess, the main part of
> my
> > reply might end up being that I don't know very much of the history of
> > this, and that sadly old commit messages also usually aren't of much
> help.)
> >
>
> I think this was introduced earlier this year by:
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=6427e777b99ec6505509a68de6d460ff772bee6a
>
> and IIRC there was some discussion before / after, and some fallouts...
>
> Thanks,
>
> Christophe
>
> > Jan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20250804/183c69d1/attachment-0001.htm>