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
