>>> On 20.09.16 at 20:00, <daniel.ki...@oracle.com> wrote:
> OK, I did some more tests and found out that after patch "efi: build
> xen.gz with EFI code" we have following xen ELF file:
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x000080 0x00100000 0x00100000 0x20c120 0x3ff00000 RWE 0x40
> because "nm -nr xen/xen-syms" emits:
> ffff82d0c0000000 A ALT_START
> ffff82d08034d000 A __2M_rwdata_end
> ffff82d08034cc00 A _end
> ffff82d08034cc00 B __per_cpu_data_end
> ffff82d08034cc00 B __bss_end
So it is your own change that breaks this.
> ALT_START lives in xen/arch/x86/efi/relocs-dummy.S. relocs-dummy.S
> provides __base_relocs_start and __base_relocs_end symbols which
> are referenced in xen/arch/x86/efi/efi-boot.h:efi_arch_relocate_image().
> Of course one can argue that maybe we should do some changes in
> efi_arch_relocate_image() and/or xen/arch/x86/efi/relocs-dummy.S.
> This is true. However, this is separate issue and we should consider
> it as such.
> "efi: build xen.gz with EFI code" patch clearly shows that current
> method used to calculate <final-exec-addr> mkelf32 argument is based
> on bogus assumptions and very fragile. So, IMO, it should be changed
> to something which is more reliable. And my proposal looks quite good.
What about the alternative of simply stripping ALT_START (and then
also VIRT_START) from the image? They're getting screwed up in
xen.efi already anyway (due to not being representable in a COFF
symbol table entry), and hence can't possibly be useful to retain.
But no matter what route we go: Such a change needs to have a
description that properly explains the issue. Vague statements are
And btw, vaguely recalling earlier issues (long ago) with awk usage
(on non-Linux platforms) I'd also prefer if such an adjustment would
get away without introducing another use of awk. I think what you
want could easily be achieved by using sed.
Xen-devel mailing list