On Wed, 24 Aug 2022 11:38:46 -0700
Nick Desaulniers [off-list ref] wrote:

Another idea I had, and Ard mentioned to me this morning that efistub
does something similar:

I think objcopy can rename symbol references.  So instead of calling
foo, I think you can use objcopy to call bar instead.

To avoid the case of Rust core refering to symbols typically provided
by the --rtlib={libgcc|compiler-rt}, what if we:
1. build core.o (with reference to the unfavorable symbols)
2. use objcopy to rename references in core.o to the symbols listed in
this file; maybe prepend them with `rust_core_` or something.
3. provide this crate with panic'ing definitions, but for the renamed
symbols.

That way, enabling CONFIG_RUST=y won't hide the case where C code is
triggering such libcalls from the C compiler?

To restate the concern, I don't want CONFIG_RUST=y to hide that fact
that someone wrote `float x, y; if (x != y) ...` in C code, where the
C compiler will likely lower that to a libcall to __nesf2 since with
the current approach in this patch, linkage would proceed. The current
behavior is to intentionally fail to link.  I think what I describe
above may work to keep this intended behavior of the kernel's build
system.

Ah, looks like there's objcopy flags:
       --redefine-sym old=new
           Change the name of a symbol old, to new.  This can be
useful when one is trying link
           two things together for which you have no source, and there
are name collisions.

       --redefine-syms=filename
           Apply --redefine-sym to each symbol pair "old new" listed
in the file filename.
           filename is simply a flat file, with one symbol pair per
line.  Line comments may be
           introduced by the hash character.  This option may be given
more than once.

So probably could start with my diff from above, but use
--redefine-syms=filename instead of --strip-symbols=.

--
Thanks,
~Nick Desaulniers

This is the approach we are about to take, see
https://github.com/Rust-for-Linux/linux/pull/779.

It's easy for just one symbol that is known to be not defined, but it
can be more complex as some of these symbols can be defined on a
platform but not another, so we would have to generate a dynamic list
of what symbols to "hijack" depending on the config. Currently we
avoid this issue by having all symbols in compiler_builtins
crate weak, but we couldn't weakly redefine a symbol.

It's certainly doable, though, but it require some effort. I am
not quite available recently so hadn't further extend and polish my
patch.

Best,
Gary