[PATCH 10/17] bfd / PE/COFF / arm: permit SEC_READONLY

[Jan Beulich]

On 06.08.2025 14:20, Richard Earnshaw (lists) wrote:
> On 04/08/2025 10:22, Jan Beulich wrote:
>> Without this, even the default .text section would end up with the
>> IMAGE_SCN_MEM_WRITE flag, which is clearly wrong. (Afaict the flag,
>> oddly enough, doesn't affect the final linked binary, so there likely
>> are more anomalies.)
>>
>> This is just so the target won't need excluding in a forthcoming new
>> testcase, which uses the .rva directive.
>>
>> --- a/bfd/coff-arm.c
>> +++ b/bfd/coff-arm.c
>> @@ -2562,7 +2562,8 @@ coff_arm_final_link_postscript (bfd * ab
>>  
>>  #ifndef EXTRA_S_FLAGS
>>  #ifdef COFF_WITH_PE
>> -#define EXTRA_S_FLAGS (SEC_CODE | SEC_LINK_ONCE | SEC_LINK_DUPLICATES)
>> +#define EXTRA_S_FLAGS (SEC_CODE | SEC_LINK_ONCE | SEC_LINK_DUPLICATES \
>> +		       | SEC_READONLY)
>>  #else
>>  #define EXTRA_S_FLAGS SEC_CODE
>>  #endif
>>
> 
> It looks like this might be a common thing for all PE files.  So why not force this in bfd/coffcode.h?  Something like
> 
> #ifdef COFF_WITH_PE
> #define PE_EXTRA_S_FLAGS SEC_READONLY
> #else
> #define PE_EXTRA_S_FLAGS 0
> #endif
> 
> and then use this directly in CREATE_(BIG|LITTLE)_COFF_TARGET_VEC
> 
> ?

Possible in principle. Yet as soon as I start doing so, I will end up asking
about other differences. Why's SEC_CODE here, for example, rather than also
being forced in uniformly? Why's SEC_DATA _not_ used here? A few more of
these question might in the end lead me questioning why this
CREATE_{BIG,LITTLE}_COFF_TARGET_VEC() parameter exists in the first place
(albeit I think in practice I'd find that at least some use for that remains).

The other thing here is the "#ifndef EXTRA_S_FLAGS" around the entire
construct in coff-arm.c. There must be a reason for that, even if I can't
spot what that might be. Or maybe there was a past reason to have this, and
it's now stale? Hmm, indeed, looks like there once were epoc-pe{,i}-arm.c,
removed in 2018.

Jan