Re: [PATCH 2/2] symbols/x86: don't use symbols-dummy

["Roger Pau Monné" <roger.pau@citrix.com>]

On Wed, Nov 26, 2025 at 07:21:09AM +0100, Jan Beulich wrote:
> On 25.11.2025 18:36, Roger Pau Monné wrote:
> > On Tue, Nov 25, 2025 at 03:14:27PM +0100, Jan Beulich wrote:
> >> In particular when linking with lld, which converts hidden symbols to
> >> local ones, the ELF symbol table can change in unhelpful ways between the
> >> first two linking passes, resulting in the .rodata contributions to change
> >> between the 2nd and 3rd pass. That, however, renders our embedded symbol
> >> table pretty much unusable; the recently introduced self-test may then
> >> also fail. (Another difference between compiling a C file and assembling
> >> the generated ones is that - with -fdata-sections in use - the .rodata
> >> contributions move between passes 1 and 2, when we'd prefer them not to.)
> >>
> >> Make tools/symbols capable of producing an "empty" assembly file, such
> >> that unwanted differences between passes 1 and 2 go away when then using
> >> the corresponding objects in place of common/symbols-dummy.o.
> >>
> >> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >> Reported-by: Roger Pau Monné <roger.pau@citrix.com>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > LGTM, not sure whether you want to extend to other arches in this
> > same patch, or simply guard the build of symbols-dummy.o for non-x86
> > arches.
> 
> I think I'd prefer to mirror it to other arch-es, but in separate
> patches (so they can go in independently). Then once all are in, ...

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

> >> ---
> >> May want mirroring to other arch-es.
> >>
> >> --- a/xen/arch/x86/Makefile
> >> +++ b/xen/arch/x86/Makefile
> >> @@ -134,8 +134,10 @@ $(TARGET): $(TARGET)-syms $(efi-y) $(obj
> >>  CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
> >>  
> >>  $(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) \
> >> -	    $(objtree)/common/symbols-dummy.o -o $(dot-target).0
> > 
> > It would be good if we could now stop building symbols-dummy.o as part
> > of extra-y.  Maybe you could guard it with ifneq ($(CONFIG_X86),y) in
> > the Makefile?
> > 
> > Or otherwise remove this from all arches thus removing
> > common/symbols-dummy.c.
> 
> ... I'd remove symbols-dummy altogether. I don't think there's a need
> to transiently disable building of symbols-dummy.o for just some of the
> arch-es (like foe x86 right here).

OK, as long as those other patches don't get stuck that's fine for me.

> >> --- a/xen/tools/symbols.c
> >> +++ b/xen/tools/symbols.c
> >> @@ -672,7 +672,10 @@ int main(int argc, char **argv)
> >>  				warn_dup = true;
> >>  			else if (strcmp(argv[i], "--error-dup") == 0)
> >>  				warn_dup = error_dup = true;
> >> -			else if (strcmp(argv[i], "--xensyms") == 0)
> >> +			else if (strcmp(argv[i], "--empty") == 0) {
> >> +				write_src();
> >> +				return 0;
> > 
> > Oh, that was easier than I was expecting for symbols to generate a
> > working empty assembly file.
> 
> Yeah, I also expected it to be more intrusive. The file isn't exactly,
> though - two of the tables (the ones with 256 entries) are emitted
> nevertheless. I didn't consider this an issue, though.

As long as it builds and has the same symbols defined, it's all fine.
IMO,  We don't care about the sizes at this point, just using the same
sections for the defined symbols.

Thanks, Roger.