Help with Warning on ARM

[Christophe Lyon]

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