All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Julien Grall" <julien@xen.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Anthony PERARD" <anthony.perard@vates.tech>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Roger Pau Monné" <roger@xenproject.org>,
	"Alistair Francis" <alistair.francis@wdc.com>,
	"Connor Davis" <connojdavis@gmail.com>
Subject: Re: [PATCH v2 3/7] RISC-V: split xen-syms linking rule
Date: Thu, 27 Aug 2026 17:56:23 +0200	[thread overview]
Message-ID: <f0510fd7-32fc-4fbd-834e-68bba14150b9@gmail.com> (raw)
In-Reply-To: <6f4b26ce-2797-4c17-bfdf-8effd2026a6a@suse.com>



On 8/26/26 2:01 PM, Jan Beulich wrote:
> Doing so, besides (hopefully) adding clarity (not the least by way of
> [re-]using pattern rules where possible), also avoids explicit recursive
> $(MAKE) invocations.
> 
> By re-using the generic rules introduced when the respective x86 rule was
> split,
> - the .map file now isn't created after the final binary anymore,
> - --strip-debug is passed to $(LD) during early linking passes (for
>    consistency the option is also explicitly added to the optional linking
>    pass rule),
> - CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are
>    now properly respected.
> Orphan section checking, otoh, is getting suppressed for now, until the
> about a dozen warnings which would result have been taken care of.
> 
> While the 4th linking step continues to be avoided when possible, a
> redundant invocation of $(NM) and tools/symbols (plus the assembling of
> the resulting .S file) is hopefully deemed acceptable.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/riscv/Makefile
> +++ b/xen/arch/riscv/Makefile
> @@ -31,40 +31,12 @@ obj-y += vtimer.o
>   $(TARGET): $(TARGET)-syms
>   	$(OBJCOPY) -O binary -S $< $@
>   
> -$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
> -	$(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
> -	$(MAKE) $(build)=$(@D) $(dot-target).0.o
> -	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
> -	      $(dot-target).0.o -o $(dot-target).0
> -	$(NM) -pa --format=sysv $(dot-target).0 \
> -		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
> -		> $(dot-target).1.S
> -	$(MAKE) $(build)=$(@D) $(dot-target).1.o
> -	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
> -	    $(dot-target).1.o -o $(dot-target).1
> -	$(NM) -pa --format=sysv $(dot-target).1 \
> -		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
> -		> $(dot-target).2.S
> -	$(MAKE) $(build)=$(@D) $(dot-target).2.o
> -	if ! { $(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o) >/dev/null; }; \
> -	then \
> -		set -e; \
> -		$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
> -		    $(dot-target).2.o -o $(dot-target).2; \
> -		$(NM) -pa --format=sysv $(dot-target).2 \
> -			| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
> -			> $(dot-target).3.S; \
> -		$(MAKE) $(build)=$(@D) $(dot-target).3.o; \
> -		$(call compare-symbol-tables, $(dot-target).2.o, $(dot-target).3.o); \
> -	else \
> -		ln -sf $(dot-target).2.o $(dot-target).3.o; \
> -	fi
> -	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
> -	    $(dot-target).3.o -o $@
> -	$(NM) -pa --format=sysv $@ \
> -		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
> -		> $@.map
> -	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
> +LAST_LINKING_PASS := 3
> +
> +include scripts/Makefile.link
> +
> +# Suppress orphan section checking for the time being.
> +orphan-handling-y :=

This works, but I think it's worth reconsidering the shape of it.

It works only by virtue of deferred expansion: $(orphan-handling-y) is
referenced solely inside the recipe of the final-pass rule in 
Makefile.link, so the value that matters is the one in effect when that
recipe is expanded, not when the rule was defined. Nothing states that
requirement, and nothing enforces it.

What makes me uneasy is that the ordering is not merely undocumented,
it's inverted with respect to the obvious reading. Makefile.link has

   orphan-handling-$(call ld-option,--orphan-handling=warn) := 
--orphan-handling=warn

i.e. an unconditional := to orphan-handling-y whenever the linker
supports the option. So an arch that sets orphan-handling-y *before*
the include has its setting silently discarded and ends up with orphan
checking enabled after all: no warning, no error, just a dozen new
linker diagnostics appearing at some later point. And "before the
include" is exactly where one would naturally put it: right next to
LAST_LINKING_PASS, which is the one knob the arch Makefile does set up
front.

I am not insisting on reworking but probably a small comment (in the 
commit mesage at least?) somewhere about that "+orphan-handling-y :=" 
should go after include will be useful.


Thanks.

~ Oleksii


  reply	other threads:[~2026-08-27 15:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-26 11:57 [PATCH v2 0/7] build: split and unify linking of final image(s) Jan Beulich
2026-08-26 12:00 ` [PATCH v2 1/7] x86: split xen-syms/xen.efi linking rules Jan Beulich
2026-09-02 14:52   ` Anthony PERARD
2026-09-03  7:26     ` Jan Beulich
2026-08-26 12:00 ` [PATCH v2 2/7] Arm: split xen-syms linking rule Jan Beulich
2026-09-02 16:32   ` Anthony PERARD
2026-09-03  7:35     ` Jan Beulich
2026-08-26 12:01 ` [PATCH v2 3/7] RISC-V: " Jan Beulich
2026-08-27 15:56   ` Oleksii Kurochko [this message]
2026-08-27 16:01     ` Jan Beulich
2026-08-27 16:12       ` Oleksii Kurochko
2026-08-26 12:01 ` [PATCH v2 4/7] PPC: " Jan Beulich
2026-09-03 11:50   ` Anthony PERARD
2026-08-26 12:02 ` [PATCH v2 5/7] build: move $(all-symbols-*) Jan Beulich
2026-09-03 11:54   ` Anthony PERARD
2026-08-26 12:03 ` [PATCH v2 6/7] build: move $(compare-symbol-tables) Jan Beulich
2026-09-03 11:55   ` Anthony PERARD
2026-08-26 12:04 ` [PATCH v2 7/7] RISC-V: place .sdata / .srodata / .riscv.attributes Jan Beulich
2026-08-27 15:40   ` Oleksii Kurochko
2026-08-27 15:53     ` Andrew Cooper
2026-08-27 15:56     ` Jan Beulich
2026-08-27 16:07       ` Oleksii Kurochko
2026-09-01  7:52         ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f0510fd7-32fc-4fbd-834e-68bba14150b9@gmail.com \
    --to=oleksii.kurochko@gmail.com \
    --cc=alistair.francis@wdc.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=connojdavis@gmail.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=roger@xenproject.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.