Audit dependencies of libcore

[eefriedman]

Current output of objdump -t libcore-7e44814b.rlib | grep UND on x86-64 Linux:

0000000000000000         *UND*  0000000000000000 __morestack
0000000000000000         *UND*  0000000000000000 __powidf2
0000000000000000         *UND*  0000000000000000 __powisf2
0000000000000000         *UND*  0000000000000000 ceil
0000000000000000         *UND*  0000000000000000 ceilf
0000000000000000         *UND*  0000000000000000 exp
0000000000000000         *UND*  0000000000000000 exp2
0000000000000000         *UND*  0000000000000000 exp2f
0000000000000000         *UND*  0000000000000000 expf
0000000000000000         *UND*  0000000000000000 floor
0000000000000000         *UND*  0000000000000000 floorf
0000000000000000         *UND*  0000000000000000 fma
0000000000000000         *UND*  0000000000000000 fmaf
0000000000000000         *UND*  0000000000000000 fmod
0000000000000000         *UND*  0000000000000000 fmodf
0000000000000000         *UND*  0000000000000000 log
0000000000000000         *UND*  0000000000000000 log10
0000000000000000         *UND*  0000000000000000 log10f
0000000000000000         *UND*  0000000000000000 log2
0000000000000000         *UND*  0000000000000000 log2f
0000000000000000         *UND*  0000000000000000 logf
0000000000000000         *UND*  0000000000000000 memcmp
0000000000000000         *UND*  0000000000000000 memcpy
0000000000000000         *UND*  0000000000000000 memset
0000000000000000         *UND*  0000000000000000 pow
0000000000000000         *UND*  0000000000000000 powf
0000000000000000         *UND*  0000000000000000 round
0000000000000000         *UND*  0000000000000000 roundf
0000000000000000         *UND*  0000000000000000 rust_begin_unwind
0000000000000000         *UND*  0000000000000000 rust_eh_personality
0000000000000000         *UND*  0000000000000000 trunc
0000000000000000         *UND*  0000000000000000 truncf

rust_eh_personality and rust_begin_unwind are lang-items expected to be defined by the user. __morestack, __powidf2, and __powisf2 are defined by libgcc. memcpy, memset, and memcmp (?) have to be defined somewhere because LLVM can insert calls to them implicitly.

The various floating-point functions are a bit dubious; it probably doesn't make sense to require freestanding environments to define log2().

We should make sure this list is appropriate, and have an automated test to make sure it doesn't change accidentally.

[alexcrichton]

Note that this is why we strongly recommend linking with --gc-sections, that way you don't actually need to provide any of these that you don't use.

[Ericson2314]

--gc-sections is definitely a good idea. But I'd presume on platforms where such float operations are not provided, it would be much more convenient to rule out their use altogether with a cfg, rather than catch it at link time---at the end of a potentially lengthy build process.

[alexcrichton]

Yeah we may just want to move a bunch of these to std instead of trying to put them in core. All of these float functions correspond to LLVM intrinsics, but I've only ever seen them lower to a function call so there's no much benefit to being in core.

Some like fmodf probably can't be avoided, but having a few small dependencies here and there isn't really the end of the world.

[Ericson2314]

I'm a bit confused. So these float intrinsics sometimes can be generated by LLVM directly, but other times fall back on function definitions with compilerrt, right? Are they used (e.g. in numeric trait impls) or just exposed in libcore today?

Also, wouldn't moving them to std prevents doing such float operations in freestanding environments where they are available? That seems bad.

Gatekeeping them with a cfg! and/or target JSON would offer the most flexibility---and early-catching convenience if these intrinsics are used trait impls---right?

[arielb1]

We may want a -C no-floating-point for implementations that don't want to deal with these (e.g. kernels that don't bother saving FP registers), or at least a better-documented way of disabling it.

[alexcrichton]

I believe this was basically appropriately dealt with in #27823, the only remaining dependencies are:

• compiler-rt intrinsics the compiler provides
• functions the compiler guarantees will become available (e.g. unwinding/personality)
• very well known functions with common implementations (memcpy, memmove, etc.)
• very well known functions that aren't used so commonly but have a canonical implementation if they are (fmod, fmodf)

The first three categories I think are fine (e.g. use Rust + rlibc and you're fine), the last of which is unfortunate but coherence kinda ties our hands. As a result I'm going to close this for now in favor of #27701