On 16.03.2023 10:52, Oleksii wrote:
>>>
>>> Could you please explain what is x86 section asserts?
>>
>> If you look at the bottom of x86's xen.lds.S you'll find a number of
>> assertions, among them one towards .got being empty. Some of the
>> sections checked there may indeed not be applicable on arbitrary
>> architectures, but I think .got is sufficiently universal. So I agree
>> with Andrew that it may be worthwhile making some of this generic.
> 
> I have question about 'SIZEOF(.got.plt) == 3 * 8':
> 
> #ifndef EFI
> ASSERT(!SIZEOF(.got),      ".got non-empty")
> /*
>  * At least GNU ld 2.30 and earlier fail to discard the generic part of
>  * .got.plt when no actual entries were allocated. Permit this case
> alongside
>  * the section being empty.
>  */
> ASSERT(!SIZEOF(.got.plt) || SIZEOF(.got.plt) == 3 * 8,
>        "unexpected .got.plt size")
> ASSERT(!SIZEOF(.igot.plt), ".igot.plt non-empty")
> ASSERT(!SIZEOF(.iplt),     ".iplt non-empty")
> ASSERT(!SIZEOF(.plt),      ".plt non-empty")
> ASSERT(!SIZEOF(.rela),     "leftover relocations")
> #endif
> 
> I assume that the check 'SIZEOF(.got.plt) == 3 * 8' was added to verify
> the case when no real entries in .got.plt are needed but .got.plt still
> has 3 entries.
> 
> I commented the code where got entries are produced now:
> --- a/xen/arch/riscv/riscv64/head.S
> +++ b/xen/arch/riscv/riscv64/head.S
> @@ -20,6 +20,7 @@ ENTRY(start)
>          csrc    CSR_SSTATUS, t0
>  
>          /* Clear the BSS */
> +/*
>          la      t3, __bss_start
>          la      t4, __bss_end
>  .L_clear_bss:
> @@ -30,5 +31,6 @@ ENTRY(start)
>          la     sp, cpu0_boot_stack
>          li      t0, STACK_SIZE
>          add     sp, sp, t0
> +*/
>  
>          tail    start_xen
> 
> And I can't see .got.plt with 3 entries:
>   $ riscv64-linux-gnu-objdump -x xen/xen-syms | grep -i got
> 
> What am I doing wrong? Or my understanding of the idea of the check is
> wrong?

Did you read the comment next to it as to only older binutils being
affected? I assume you use something newer than 2.30. Furthermore that
specific behavior may very well have been x86-specific in the first
place. So ...

> And I assume that add !SIZEOF(.got) and !SIZEOF(.got.plt) would be
> enough to RISC-V's xen.lds.S?

... quite likely: Yes.

Jan

Reply via email to