[PATCH] gas: Add pushuniquesection and --unique-pushsection

Zhiyuan Lv zhiyuan.lv@linux.intel.com
Mon May 19 00:34:15 GMT 2025


On Fri, May 16, 2025 at 09:19:43AM +0200, Jan Beulich wrote:
> On 16.05.2025 09:00, H.J. Lu wrote:
> > On Fri, May 16, 2025 at 2:49 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 16.05.2025 08:15, H.J. Lu wrote:
> >>> Linker kernel uses .pushsection directive extensively.  But when
> >>> -ffunction-sections is used to build kernel, for
> >>>
> >>> __attribute__((always_inline))
> >>> static void inline
> >>> test_section(void)
> >>> {
> >>>   asm goto("jmp 1f\n"
> >>>    "\t.pushsection .alt_section, \"ax\"\n"
> >>
> >> If you pass --sectname-subst to the assembler and use
> >>
> >>     "\t.pushsection .alt_section%S, \"ax\"\n"

Thanks Jan! I tried this and it worked perfectly for my case!

> > 
> > This isn't very programmer friendly.  One needs to change
> > the source and add a new assembler option.
> 
> The source needs changing with your proposal, too. And the assembler

H.J.'s patch provides two approaches: add option or change the source
code, either one can address the issue. The option-change-only approach
is especially helpful.

> option change isn't a difficult one. Plus one can use this with a
> range of already released versions, whereas your handling of a sub-case
> thereof would be available only with future releases. I think the

Indeed. Meanwhile, the code change to existing open source projects
might also be a consideration factor? It is not an issue to my case
right now as I can freely do change as needed, but considering Linux
kernel upstream to adopt it for any use cases, we have to think of
kernel changes not to break LLVM as well. Then one approach is to push
LLVM assembler to support "--sectname-subst", which I did not see it
there yet, another approach is to use new option when available, which
sounds easier as the source code is always compatible. Thanks!

Regards,
-Zhiyuan

> benefit of adding special-case handling for something where a more
> generic solution already exists needs to be a bit wider than just the
> avoiding of the need to add a command line option (typically somewhere
> in a central place in a make system).
> 
> Jan


More information about the Binutils mailing list