On 01.03.2022 09:55, Jan Beulich wrote: > --- a/xen/arch/x86/xen.lds.S > +++ b/xen/arch/x86/xen.lds.S > @@ -194,6 +194,7 @@ SECTIONS > #endif > _sinittext = .; > *(.init.text) > + *(.text.startup) > _einittext = .; > /* > * Here are the replacement instructions. The linker sticks them > @@ -258,9 +259,10 @@ SECTIONS > > . = ALIGN(8); > __ctors_start = .; > - *(.ctors) > + *(SORT_BY_INIT_PRIORITY(.init_array.*)) > + *(SORT_BY_INIT_PRIORITY(.ctors.*)) > *(.init_array) > - *(SORT(.init_array.*)) > + *(.ctors) > __ctors_end = .; > } PHDR(text)
While I did commit the change with Roger's R-b, on the basis that it's not going to make things worse, I don't think what we have here and what we do in init_constructors() is quite right: For one .init_array and .ctors are supposed to be processed in, respectively, opposite order - the former forwards, the latter backwards. See e.g. gcc's libgcc/gbl-ctors.h. And then both variants also shouldn't be intermixed; we ought to expect only one of the two kinds, and aiui for now it's always going to be .ctors. The processing in wrong order looks to not be a problem in the builds I can check, as there's only ever a single priority used. But we're at risk of this breaking down the road ... Finally, if we consider .init_array might appear, we ought to also discard (rather than leaving orphaned) .fini_array. Jan
