| Message ID | 2a9061de-3d68-20f7-75b9-b1b9491342f8@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86: also discard .fini_array in linker script | expand |
On Fri, Mar 04, 2022 at 08:49:39AM +0100, Jan Beulich wrote: > This simply parallels .dtors. Both section types can reference > .text.exit, which requires them to be discarded together with that one. > Compilers, depending on their findings during the configure phase, may > elect to use either model. While .{init,fini}_array look to be > preferred, cross compilers apparently have this guessed, likely > resulting in a fallback to .{c,d}tors. Hence we need to support both > sets. Do we also need to consider discarding .fini? Or that's guaranteed to not be used by the compiler? Thanks, Roger.
On 04.03.2022 09:57, Roger Pau Monné wrote: > On Fri, Mar 04, 2022 at 08:49:39AM +0100, Jan Beulich wrote: >> This simply parallels .dtors. Both section types can reference >> .text.exit, which requires them to be discarded together with that one. >> Compilers, depending on their findings during the configure phase, may >> elect to use either model. While .{init,fini}_array look to be >> preferred, cross compilers apparently have this guessed, likely >> resulting in a fallback to .{c,d}tors. Hence we need to support both >> sets. > > Do we also need to consider discarding .fini? Or that's guaranteed to > not be used by the compiler? I'm not aware of it being used anymore; if it was used, we'd also need to deal with .init (which - logically, but not technically - would conflict with our own section of this same name in xen.efi). Jan
On Fri, Mar 04, 2022 at 10:17:22AM +0100, Jan Beulich wrote: > On 04.03.2022 09:57, Roger Pau Monné wrote: > > On Fri, Mar 04, 2022 at 08:49:39AM +0100, Jan Beulich wrote: > >> This simply parallels .dtors. Both section types can reference > >> .text.exit, which requires them to be discarded together with that one. > >> Compilers, depending on their findings during the configure phase, may > >> elect to use either model. While .{init,fini}_array look to be > >> preferred, cross compilers apparently have this guessed, likely > >> resulting in a fallback to .{c,d}tors. Hence we need to support both > >> sets. > > > > Do we also need to consider discarding .fini? Or that's guaranteed to > > not be used by the compiler? > > I'm not aware of it being used anymore; if it was used, we'd also need > to deal with .init (which - logically, but not technically - would > conflict with our own section of this same name in xen.efi). We would realize if having the orphaned check (or like here would get missing references. Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Thanks, Roger.
--- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -415,6 +415,8 @@ SECTIONS *(.eh_frame) *(.dtors) *(.dtors.*) + *(.fini_array) + *(.fini_array.*) #ifdef EFI *(.comment) *(.comment.*)
This simply parallels .dtors. Both section types can reference .text.exit, which requires them to be discarded together with that one. Compilers, depending on their findings during the configure phase, may elect to use either model. While .{init,fini}_array look to be preferred, cross compilers apparently have this guessed, likely resulting in a fallback to .{c,d}tors. Hence we need to support both sets. Fixes: 4b7fd8153ddf ("x86: fold sections in final binaries") Reported-by: Andrew Cooper <Andrew.Cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> --- As mentioned elsewhere, I don't think init_constructors() is correct for the .ctors variant. But that's a separate issue.