Re: committed [RISC-V]: Harden test scan patterns

[Joern Rennecke <joern.rennecke@embecosm.com>]

On Fri, 29 Sept 2023 at 14:54, Jeff Law <jeffreyalaw@gmail.com> wrote:

> So I recommend we go forward with Joern's approach (so consider that an
> ACK for the trunk).   Joern  can you post a follow-up manual twiddle so
> that other ports can follow your example and avoid this problem?

The manual... so not in the general web pages, but the stuff under gcc/doc ?
I see that we have a description of scan-assembler* directives in
sourcebuild.texi ,
so I suppose that it should go there.  I suppose the advice should also apply to
scan-assembler-dem(-not), but not to scan-symbol-section .

The more I think about this, the more it feels like we are providing the wrong
tools and then are telling users they're using it incorrectly
(like "You're holding it wrong.").
Quoting dots with \. is not much of an issue, but prepending \t or \m
impairs legibility.  I like the obsoleted word-start/end markers \< / \>
much better, as they don't blend in with text.
^ as start-of-line marker is nice for legibility, but it will generally not
work with common semantics, as it'll be thrown off by white space,
and even more, by labels.

Also, we might have different directives for not scanning in LTO sections -
or just ignoring .ascii .  Or maybe the other way round - you have to do
something special if you want to scan inside strings, and by default we
don't look inside strings?
LTO information uses ascii, and ISTR sometimes also a zero-terminated
variant (asciiz?); There might also some string constant outputs, or stabs
information.
One possible rule I think might work is: if the RE doesn't mention a quote,
don't scan what's quoted inside double quotes.  Although we might to have
to look out for backslash-escaped quotes to find the proper end of a quoted
string.

Or should we instead make assembly scans specific to sections in which
assembly output goes, like text sections?  The danger is that we might miss
a text section by another name.  We can give an error if we find no text
section, but there might be a recognizable text section which is a red
herring besides the one that's hidden by some unusual name.