| Message ID | ceaae3c8-0c35-efc1-c7bc-f44364ce29e4@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86: make embedded endbr64 check compatible with older GNU grep | expand |
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
--- 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
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).