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

Richard Earnshaw (lists) Richard.Earnshaw@arm.com
Wed Aug 6 12:50:58 GMT 2025


On 06/08/2025 13:42, Jan Beulich wrote:
> 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.
> 

Because at one time there were pe-coff variants to support EPOC (symbian) that had different settings (There are references to it in the ChangeLog files.  Those ports were removed, but the code here was never simplified.

R.
> Jan



More information about the Binutils mailing list