Re: KEEP Re: [PATCH 2/2] xen: Add CONFIG_GC_SECTIONS

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.12.2025 16:48, Jason Andryuk wrote:
> On 2025-12-12 08:22, Jan Beulich wrote:
>> On 12.12.2025 02:34, Jason Andryuk wrote:
>>> The alternative is section groups?  I'm trying that, and it kinda works
>>> sometimes, but .attach_to_group fails when .init.text is involved.
>>>
>>> Here's an example that I think would work, I could make it to
>>> --gc-sectrions:
>>> group section [    3] `.group' [.text.vpmu_do_msr] contains 5 sections:
>>>      [Index]    Name
>>>      [   43]   .text.vpmu_do_msr
>>>      [   44]   .rela.text.vpmu_do_msr
>>>      [   45]   .altinstructions..text.vpmu_do_msr
>>>      [   46]   .rela.altinstructions..text.vpmu_do_msr
>>>      [   47]   .altinstr_replacement..text.vpmu_do_msr
>>>
>>> But I don't make it that far.  Other files blow up with tons of:
>>> {standard input}:9098: Warning: dwarf line number information for
>>> .init.text ignored
>>> and
>>> {standard input}:50083: Error: leb128 operand is an undefined symbol:
>>> .LVU4040
>>>
>>> Line 9098 of apic.s is .loc below:
>>> """
>>>           .section        .init.text
>>>           .globl  setup_boot_APIC_clock
>>>           .hidden setup_boot_APIC_clock
>>>           .type   setup_boot_APIC_clock, @function
>>> setup_boot_APIC_clock:
>>> .LFB827:
>>>           .loc 1 1150 1 is_stmt 1 view -0
>>>           .cfi_startproc
>>>           pushq   %rbp
>>> """
>>>
>>> diff below.  Any ideas?
>>
>> I haven't looked into this in detail yet, but ...
>>
>>> --- a/xen/arch/x86/include/asm/alternative.h
>>> +++ b/xen/arch/x86/include/asm/alternative.h
>>> @@ -90,25 +90,31 @@ extern void alternative_instructions(void);
>>>    /* alternative assembly primitive: */
>>>    #define ALTERNATIVE(oldinstr, newinstr, feature)                      \
>>>            OLDINSTR_1(oldinstr, 1)                                       \
>>> -        ".pushsection .altinstructions, \"a\", @progbits\n"           \
>>> +        ".attach_to_group %%S\n"                                      \
>>> +        ".pushsection .altinstructions.%%S, \"a?\", @progbits\n"      \
>>
>> ... wouldn't you need another .attach_to_group here and ...
>>
>>>            ALTINSTR_ENTRY(feature, 1)                                    \
>>> -        ".section .discard, \"a\", @progbits\n"                       \
>>> +        ".popsection\n"                                               \
>>> +        ".pushsection .discard, \"a\", @progbits\n"                   \
>>>            ".byte " alt_total_len "\n" /* total_len <= 255 */            \
>>>            DISCARD_ENTRY(1)                                              \
>>> -        ".section .altinstr_replacement, \"ax\", @progbits\n"         \
>>> +        ".popsection\n"                                               \
>>> +        ".pushsection .altinstr_replacement.%%S, \"ax?\", @progbits\n"\
>>
>> ... here? Or alternatively use the 'G' section flag to the specify the group
>> name?
> 
> The '?' flag puts the new section in the previous group, so it doesn't 
> have to be specified.  I have used 'G' and %%S with similar results. 
> The example vpmu output above shows that is working.  I can't get to 
> linking with --gc-sections yes to see if %%S is no longer necessary with 
> proper groups.

Oh, sorry - I had managed to overlook the use of '?' above.

> The problem is "the current function" needs to be assigned to the same 
> group, and that is what I hoped to address with .attach_to_group.  From 
> what I can tell, the function-section is not assigned to a group without 
> .attach_to_group.
> 
>> As to debug info, I wonder whether playing with groups behind the back of the
>> compiler is going to work well. Iirc it groups sections itself, too. Did you
>> look at the generated assembly with this in mind?
> 
> The generated assembly differs only by the presence of .attach_to_group 
> for build vs. doesn't build.  Is the debug information expected to 
> differ according to groups?  (This is all new to me).  I have more to 
> look into, I figured I'd post what I have in case anyone had seen it before.

Hmm, looking at a random example, .debug_info (and other Dwarf sections) is
still monolithic with -ffunction-sections. I'm having a hard time seeing
how that would work nicely. And while I'm sure I saw gcc emit section
groups in certain cases (e.g. while building tools/), I can't observe it
doing so there, so that must also depend on something I haven't figured out
yet.

Jan