On 15/07/2022 11:14, Jan Beulich wrote:
> On 14.07.2022 16:39, Anthony PERARD wrote:
>> --- a/xen/tools/check-endbr.sh
>> +++ b/xen/tools/check-endbr.sh
>> @@ -78,7 +78,7 @@ then
>> else
>> grep -aob -e "$(printf '\363\17\36\372')" -e "$(printf
>> '\363\17\36\373')" \
>> -e "$(printf '\146\17\37\1')" $TEXT_BIN
>> -fi | awk -F':' '{printf "%s%x\n", "'$vma_hi'", int(0x'$vma_lo') + $1}' >
>> $ALL
>> +fi | awk -F':' '{printf "%s%x\n", "'$vma_hi'", int('$((0x$vma_lo))') + $1}'
>> > $ALL
> I'm afraid that's not portable to environments where sizeof(long) < 8.
> The shell isn't required to use wider than long for the evaluation.
Yuck. This works at the moment in 32 bit builds because:
++ objdump -j .text xen-syms -h
++ awk '$2 == ".text" {printf "vma_hi=%s\nvma_lo=%s\n", substr($4, 1,
8), substr($4, 9, 16)}'
+ eval vma_hi=ffff82d0 vma_lo=40200000
++ vma_hi=ffff82d0
++ vma_lo=40200000
so the top bit isn't set.
And going from an 8/8 split to a 9/7 split doesn't work either because
that uses 4 bits and we've only got 2 to play with given .text's 1G
alignment.
I know it's disgusting, but how about a BUILD_BUG_ON(XEN_VIRT_START &
(1u << 31)) ?
~Andrew
