[PATCH 01/17] ld/PE: adjust .reloc and .edata section flags

Jan Beulich jbeulich@suse.com
Wed Aug 6 12:10:27 GMT 2025


On 06.08.2025 13:59, Richard Earnshaw (lists) wrote:
> On 04/08/2025 10:13, Jan Beulich wrote:
>> Both really want to be SEC_DATA, even if _bfd_XXi_swap_scnhdr_out()
>> makes sure that IMAGE_SCN_CNT_INITIALIZED_DATA is set in the final
>> section header. Otoh, .reloc - being IMAGE_SCN_MEM_DISCARDABLE at least
>> by default - shouldn't have SEC_ALLOC set.
>>
>> In an early form of the patch I also dropped SEC_ALLOC for .reloc. While
>> I've undone that, I think the then necessary testsuite adjustments still
>> want retaining:
>>
>> 1) I can't explain why the removal of _both_ SEC_ALLOC and SEC_LOAD for
>> .reloc causes ld-scripts/provide-8 to XPASS on PE targets. Placing a
>> symbol outside of the image isn't well-defined in PE anyway though, so
>> convert the xfail-s to notarget-s.
>>
>> 2) Similarly it's not quite clear why ld-pe/pe-aarch64 fails due to the
>> SEC_LOAD removal; the expectation of ___tls_end__ where _start should
>> appear was pretty likely bogus, though. If, due to multiple symbols
>> sitting at the same address, unpredictable behavior can result, the
>> expectation needs to be relaxed accordingly. Assuming it's random what
>> the disassembler picks, allow (about) any symbol to appear there, as
>> further symbols are at the same address as per the symbol table.
> 
> Agreed.  Perhaps in this case we could change the source slightly too, to have:
> 
>   .section .text
> 
> +     nop	// Ensure no other symbol can alias _start
>   _start:
>       mov x1, 20
>       b foo
>   foo:
>       ret
> 
> The nop would ensure that the expected symbol would always appear, though we'd need to adjust the .d file accordingly.  Can we also use '.type' on PE files to make sure _start is correctly typed as a code symbol; or .global?  Both of these would probably preference the disassembler towards using that symbol rather than some other with the same value.

Both sound plausible to me, but (obviously) I can't say why this wasn't done
like that in the first place. If I'm to make the adjustments, I guess I may
better split this out into a separate patch.

Jan


More information about the Binutils mailing list