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.

--- 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.*)

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.