With version 2.7 I'm observing support for binary searches, but
unreliable results: Only a subset of the supposed matches is actually
reported; for our pattern I've never observed any match. This same
version works fine when handing it a Perl regexp using hex or octal
escapes. Probe for support of -P and prefer that over the original
approach.

Fixes: 4d037425dccf ("x86: Build check for embedded endbr64 instructions")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
If we were to fear -P having a different meaning elsewhere, we may need
to switch to the respective long option (--perl-regexp).

--- a/xen/tools/check-endbr.sh
+++ b/xen/tools/check-endbr.sh
@@ -24,6 +24,11 @@ BAD=$D/bad-addrs
 echo "X" | grep -aob "X" -q 2>/dev/null ||
     { echo "$MSG_PFX Warning: grep can't do binary searches" >&2; exit 0; }
 
+# Check whether grep supports Perl regexps. Older GNU grep doesn't reliably
+# find binary patterns otherwise.
+perl_re=true
+echo "X" | grep -aobP "\130" -q 2>/dev/null || perl_re=false
+
 #
 # First, look for all the valid endbr64 instructions.
 # A worst-case disassembly, viewed through cat -A, may look like:
@@ -60,8 +65,12 @@ eval $(${OBJDUMP} -j .text $1 -h |
     awk '$2 == ".text" {printf "vma_hi=%s\nvma_lo=%s\n", substr($4, 1, 8), substr($4, 9, 16)}')
 
 ${OBJCOPY} -j .text $1 -O binary $TEXT_BIN
-grep -aob "$(printf '\363\17\36\372')" $TEXT_BIN |
-    awk -F':' '{printf "%s%x\n", "'$vma_hi'", int(0x'$vma_lo') + $1}' > $ALL
+if $perl_re
+then
+    LC_ALL=C grep -aobP '\363\17\36\372' $TEXT_BIN
+else
+    grep -aob "$(printf '\363\17\36\372')" $TEXT_BIN
+fi | awk -F':' '{printf "%s%x\n", "'$vma_hi'", int(0x'$vma_lo') + $1}' > $ALL
 
 # Wait for $VALID to become complete
 wait

On 24/02/2022 10:14, Jan Beulich wrote:
> With version 2.7 I'm observing support for binary searches, but
> unreliable results: Only a subset of the supposed matches is actually
> reported; for our pattern I've never observed any match. This same
> version works fine when handing it a Perl regexp using hex or octal
> escapes. Probe for support of -P and prefer that over the original
> approach.
>
> Fixes: 4d037425dccf ("x86: Build check for embedded endbr64 instructions")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Looks plausible.  Tentative ack, but this definitely needs a full run
through CI before committing.  Let me kick something off.

> ---
> If we were to fear -P having a different meaning elsewhere, we may need
> to switch to the respective long option (--perl-regexp).

We can probably get away with -P.

~Andrew

On 24/02/2022 10:21, Andrew Cooper wrote:
> On 24/02/2022 10:14, Jan Beulich wrote:
>> With version 2.7 I'm observing support for binary searches, but
>> unreliable results: Only a subset of the supposed matches is actually
>> reported; for our pattern I've never observed any match. This same
>> version works fine when handing it a Perl regexp using hex or octal
>> escapes. Probe for support of -P and prefer that over the original
>> approach.
>>
>> Fixes: 4d037425dccf ("x86: Build check for embedded endbr64 instructions")
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Looks plausible.  Tentative ack, but this definitely needs a full run
> through CI before committing.  Let me kick something off.

Started now:

https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/478508459
https://cirrus-ci.com/build/6255196018835456

We're getting chronic networking problems in gitlab right now so that
might require a lot of persuasion to be useful.

~Andrew

On 24/02/2022 11:22, Andrew Cooper wrote:
> On 24/02/2022 10:21, Andrew Cooper wrote:
>> On 24/02/2022 10:14, Jan Beulich wrote:
>>> With version 2.7 I'm observing support for binary searches, but
>>> unreliable results: Only a subset of the supposed matches is actually
>>> reported; for our pattern I've never observed any match. This same
>>> version works fine when handing it a Perl regexp using hex or octal
>>> escapes. Probe for support of -P and prefer that over the original
>>> approach.
>>>
>>> Fixes: 4d037425dccf ("x86: Build check for embedded endbr64 instructions")
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Looks plausible.  Tentative ack, but this definitely needs a full run
>> through CI before committing.  Let me kick something off.
> Started now:
>
> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/478508459
> https://cirrus-ci.com/build/6255196018835456

Everything is green.  Good to commit.

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

~Andrew