BaseTools/GenFw: Fix LoongArch ELF-to-PE RVA conversion

GenFw converts linked ELF images to PE/COFF images using a new section
layout. The generated PE/COFF section RVAs are not required to match the
linked ELF section addresses, so relocation fixups that rewrite section
contents must use the generated PE/COFF RVA space.

A linker script layout change can expose this on LoongArch64 when .text
and .data are linked with 0x1000 alignment while .hii still keeps a
0x4000 alignment. GenFw then keeps a 0x4000 PE/COFF section alignment
because of .hii, producing different ELF and PE/COFF layouts.

Fix two LoongArch relocation paths exposed by this layout mismatch.
R_LARCH_64 entries stored in section contents, such as switch jump
tables, must be translated from the linked ELF section address space to
the generated PE/COFF RVA space. R_LARCH_PCALA_* and R_LARCH_GOT_PC_*
must also convert the referenced symbol to its generated PE/COFF RVA
before calculating the PC-relative offset.

The LoongArch ELF ABI defines PCALA/GOT_PC relocations as page-based,
but this GenFw path rewrites the HI/LO pair to PCADDU12I plus ADDI.D.
After that rewrite, the offset split must be based on the generated
PE/COFF instruction-relative offset.

For example, in the failing LogoDxe image, _gUefiDriverRevision is at
ELF address 0x5400 in .text, and the relocation referencing it is at ELF
address 0x104c. With ELF .text at 0x1000 and PE/COFF .text at 0x4000,
the generated PE/COFF RVAs are 0x8400 for the symbol and 0x404c for the
relocation site. Mixing the ELF symbol address with the PE/COFF
relocation-site RVA makes the entry wrapper read PE/COFF RVA 0x5400
instead of 0x8400, causing EFI_INCOMPATIBLE_VERSION.

Use PE/COFF RVAs consistently when rewriting LoongArch absolute and
PC-relative references during WriteSections64(). The existing
WriteRelocations64() base relocation emission is kept for load-time
image rebasing.

Reported-by: Chao Li <lichao@loongson.cn>
Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
Signed-off-by: Chao Li <lichao@loongson.cn>
Tested-by: Dongyan Qian <qiandongyan@loongson.cn>

0 files changed, 0 insertions, 0 deletions