On 15.07.2022 12:43, Andrew Cooper wrote:
> 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.
Why does text alignment matter here? All we care about are offsets
into the Xen image. An I guess we aren't really at risk of going
beyond 256M in image size ...
> I know it's disgusting, but how about a BUILD_BUG_ON(XEN_VIRT_START &
> (1u << 31)) ?
In the worst case, why not. But that would be an odd restriction on
changes to the memory layout (which we've done in the past).
Jan
