[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 3/3] livepatch: correctly handle altinstruction sections
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |