Help with Warning on ARM

[Jan Beulich]

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.)

Jan