On 11.03.2022 09:12, Roger Pau Monné wrote:
> On Fri, Mar 11, 2022 at 08:35:18AM +0100, Jan Beulich wrote:
>> On 10.03.2022 16:08, Roger Pau Monne wrote:
>>> --- a/common.c
>>> +++ b/common.c
>>> @@ -249,19 +249,22 @@ int is_text_section(struct section *sec)
>>> (sec->sh.sh_flags & SHF_EXECINSTR));
>>> }
>>>
>>> +#define SEC_MATCH(n) !strncmp(sec->name, n, strlen(n) - 1)
>>> int is_rodata_section(struct section *sec)
>>> {
>>> return sec->sh.sh_type == SHT_PROGBITS &&
>>> !(sec->sh.sh_flags & (SHF_EXECINSTR | SHF_WRITE)) &&
>>> - !strncmp(sec->name, ".rodata", 7);
>>> + (SEC_MATCH(".rodata") || SEC_MATCH(".data.ro_after_init"));
>>> }
>>>
>>> int is_init_section(struct section *sec)
>>> {
>>> return sec->sh.sh_type == SHT_PROGBITS &&
>>> (sec->sh.sh_flags & SHF_ALLOC) &&
>>> - !strncmp(sec->name, ".init", 5);
>>> + (SEC_MATCH(".init") || SEC_MATCH(".text.startup") ||
>>> + SEC_MATCH(".altinstr") || SEC_MATCH(".ctors"));
>>
>> Having dealt with this recently - what about .init_array? Modern gcc
>> prefers that over .ctors. Of course the question is whether either
>> really needs dealing with here - these sections, to my knowledge,
>> appear only with gcov support enabled. Not sure that's a case where
>> livepatching is actually expected to be used.
>
> .init_array will match the .init comparison, and thus is already
> handled.
Oh, I guess I should have looked at what SEC_MATCH() actually does.
> Regarding .ctors, it's certainly an .init section, so it doesn't hurt
> to get added here in any case? (regardless of us only knowing it being
> used for code coverage so far)
It certainly doesn't hurt, sure.
Jan
