Re: [PATCH] x86: also discard .fini_array in linker script

2022-03-04 Thread Roger Pau Monné
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é 

Thanks, Roger.



Re: [PATCH] x86: also discard .fini_array in linker script

2022-03-04 Thread Jan Beulich
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




Re: [PATCH] x86: also discard .fini_array in linker script

2022-03-04 Thread Roger Pau Monné
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.



[PATCH] x86: also discard .fini_array in linker script

2022-03-03 Thread Jan Beulich
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 
Signed-off-by: Jan Beulich 
---
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.*)