Undefined symbols __start_linkm2_*, __start_linkme_*, __stop_linkm2_*, __stop_linkme_*

[douglas-raillard-arm]

The following symbols are not defined:
__start_linkm2_*, __start_linkme_*, __stop_linkm2_*, __stop_linkme_*

The build is a static archive for a freestanding custom target with rust-lld with rust 1.85.0. The issue seems identical to the one reported at #88 .
I'm not sure if the issue is supposed to be fixed or not, but none of the workarounds seems to work:

• -Clink-arg=-Wl,-z,nostart-stop-gc
• -Clink-dead-code is broken for my setup (-Zbuild-std) so I cannot test it
• used_linker feature

The resulting .a file contains:

• linkme_* and linkm2_* sections:

[12] linkme_FEATURES   PROGBITS        0000000000000000 00dd28 000000 00  WA  0   0  1
[13] linkm2_FEATURES   PROGBITS        0000000000000000 00dd28 000008 00   A  0   0  8
[130] linkme_FEATURES  PROGBITS        0000000000000000 016881 000002 00   A  0   0  1

• a global undefined symbol for each of __start_linkm2_*, __start_linkme_*, __stop_linkm2_*, __stop_linkme_*:

565: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT   UND __stop_linkm2_FEATURES
566: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT   UND __start_linkm2_FEATURES
567: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT   UND __start_linkme_FEATURES
568: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT   UND __stop_linkme_FEATURES

• and relocations mentioning them:

0000000000007804  0000023700000113 R_AARCH64_ADR_PREL_PG_HI21 0000000000000000 __start_linkme_FEATURES + 0

But no definition anywhere.

Using rust-lld is important here so I don't depend on the platform linker, as this build is done dynamically along some C code, with a wide range of C toolchains. Relying on the user-provided linker would be a recipe for build failure in exotic configurations. OTH rust-lld provides me with the same linker everywhere for the Rust part of the code. If rust-lld is not supported at the moment, it may be a good idea to mention it in the documentation.

[douglas-raillard-arm]

Actually after more digging it seems that the environment is at fault: the context is a Linux kernel module, where the Rust code gets prelinked into a single object file, which is then linked to the rest of the C module. It seems that the kernel module never gets linked in a DSO or an executable file, so all the build system does is a final linking to an object file, then some post processing and here is the .ko file.

Unfortunately, the encapsulation symbols __start_ and __stop_ are created in the final linking to exe or DSO step, and there does not seem to be any CLI option to make GNU ld or LLD add the symbols when the output is an object file.

The only workaround I can think of is a script looking at nm output and generate a linker script with the appropriate __start_ and __stop_ symbols.

[douglas-raillard-arm]

So I made the build system generate a linker script snippet for each __start_* and __stop_* symbol it finds in the prelinked object coming from Rust (by scanning the nm -gj output):

import textwrap

def make_lds(section):
    return textwrap.dedent(f'''
        SECTIONS {{
            {section} : {{
                PROVIDE(__start_{section} = .);
                KEEP(*({section}));
                PROVIDE(__stop_{section} = .);
            }}
        }}
    ''')

And then the object file is prelinked again with that linker script (along with some --gc-sections and other CLI flags to describe the custom entry points) and everything works ok now.

This also has the advantage of avoiding the need for -znostart-stop-gc linker flag by using the KEEP() directive.

Maybe it would make sense to add in the documentation that it relies on the Rust project being linked into an executable or DSO, i.e. staticlib crate type is only supported depending on what happens to the resulting files. It is a bit of a fringe use case, but considering linkme supports no-std, I wouldn't be surprised if someone else hit a similar issue when working on embedded things, especially considering the __start_* and __stop_* symbol automatic generation by the linker is apparently widespread in the Linux ecosystem but also not well documented in details.