Re: [PATCH v1] xen/riscv: make calculation of stack address PC-relative

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/03/2023 7:59 am, Jan Beulich wrote:
> On 14.03.2023 21:16, Oleksii wrote:
>> I checked in Linux binary how 'la' instruction is transformed, and it
>> looks like it is translated as I expect to auipc/addi pair:
>> ffffffe000001066: 00027517 auipc a0,0x27
>> ffffffe00000106a: f9a50513 addi a0,a0,-102 # ffffffe000028000
>> <early_pg_dir>
>>
>> I checked compiler flags between Xen and Linux. The difference is in-
>> fno-PIE (Linux also adds -mabi and -march to AFLAGS):
>>
>> 1. Linux build command of head.S: riscv64-linux-gnu-gcc -Wp,-
>> MD,arch/riscv/kernel/.head.o.d -nostdinc -isystem /usr/lib/gcc-
>> cross/riscv64-linux-gnu/9/include -I./arch/riscv/include -
>> I./arch/riscv/include/generated -I./include -I./arch/riscv/include/uapi
>> -I./arch/riscv/include/generated/uapi -I./include/uapi -
>> I./include/generated/uapi -include ./include/linux/kconfig.h -
>> D__KERNEL__ -D__ASSEMBLY__ -fno-PIE -mabi=lp64 -march=rv64imafdc -c -o
>> arch/riscv/kernel/head.o arch/riscv/kernel/head.S
>>
>> 2. Xen build command of head.S:riscv64-linux-gnu-gcc -MMD -MP -MF
>> arch/riscv/riscv64/.head.o.d -D__ASSEMBLY__ -Wa,--noexecstack -
>> DBUILD_ID -fno-strict-aliasing -Wall -Wstrict-prototypes -Wdeclaration-
>> after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs
>> -O1 -fno-omit-frame-pointer -nostdinc -fno-builtin -fno-common -Werror
>> -Wredundant-decls -Wno-pointer-arith -Wvla -pipe -D__XEN__ -include
>> ./include/xen/config.h -Wa,--strip-local-absolute -g -mabi=lp64 -
>> I./include -I./arch/riscv/include -march=rv64gc -mstrict-align -
>> mcmodel=medany - -c arch/riscv/riscv64/head.S -o
>> arch/riscv/riscv64/head.o
> Looking into why you see different code generated than I: Nothing in
> here directs gcc to pass -fpic to gas; in upstream gcc (consistent
> from gcc7 through gcc12, which are the versions I've checked; the
> actual range may be wider) there is
>
> #define ASM_SPEC "\
> %(subtarget_asm_debugging_spec) \
> %{" FPIE_OR_FPIC_SPEC ":-fpic} \
> ...
>
> Can you check whether your gcc passes -fpic to gas even when there's
> no -fPIC / -fPIE (or alike) on the gcc command line? Or whether your
> gas (unlike upstream's) defaults to PIC mode? (For .S files ASM_SPEC
> is all that counts. For .c files gcc is redundantly passing -fpic
> along with also emitting ".option pic" or, in the opposite case, it
> is omitting -fpic along with emitting ".option nopic".)
>
> You gcc may have been configured with --enable-default-pie, while I
> know mine hasn't been (simply because that's the default).

>From the thread, the difference is clearly around the pie option, but I
have to admit that I'm confused.

With GCC 10 from Debian repos and current staging (modulo the build
fix), we end up with:

0000000080200000 <_start>:
    80200000:   10401073                csrw    sie,zero
    80200004:   00002117                auipc   sp,0x2
    80200008:   00413103                ld      sp,4(sp) # 80202008
<_GLOBAL_OFFSET_TABLE_+0x8>
    8020000c:   6285                    lui     t0,0x1
    8020000e:   9116                    add     sp,sp,t0
    80200010:   7f10206f                j       80203000 <start_xen>

In this case, the auipc/ld pair makes a PC-relative reference into the
GOT, but the pointer spilled into the GOT is the link time address of
cpu0_boot_stack.

For the executable as a whole, we've got:

[ 6] .got              PROGBITS        0000000080202000 003000 000010
08  WA  0   0  8
[ 7] .got.plt          PROGBITS        0000000080202010 003010 000010
08  WA  0   0  8

i.e. both nonzero in size, so presumably with expectations of something
else to fix up the references.

I suspect we want to extend the x86 section asserts into the other
architectures too, alongside figuring out how exactly to disable code
generation of this form.

~Andrew