Re: fixing "libtool -module" for C++

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Sun, Mar 23, 2025 at 20:21:27 +0100, Jörg Sonnenberger wrote:

> On 3/22/25 8:19 AM, Martin Husemann wrote:
> > I don't know anything about libtool, but not linking with -lgcc *might*
> > work on some modules on some platforms, but might fail on others
> > due to CPU differences.
> 
> More specifically, there is something like millicode on some CPU which is
> never shared. I'm not 100% sure from memory right now if any of those are
> left with code in libgcc or if we provide a libc implementation at all times
> now, but that was a real concern in the past at least.

"Provide a _libc_ implementation" is a bit unfortunate way to word
this, I think, as millicode cannot, by design, be provided in some
other library.  Millicode is large enough so it's "better" to have it
as a function instead of emitting it inline, but you want to avoid the
full overhead of a function call w.r.t. clobbered registers.

Since millicode "functions" don't follow function call ABI, they
cannot be called across DSOs, b/c dynamic linker safely assumes that
the full function call ABI gives it licesne to clobber the
corresponding registers.

Hence, on platforms that use millicode, a copy of required millicode
needs to be linked statically in every DSO.

We do have independently written GCC millicode in sys/lib/libkern/arch
so that we can compile the kernel with GCC (that emits millicode
calls) but don't link it with libgcc.  Here's an example of a
millicode function for sh3:

https://cvsweb.netbsd.org/bsdweb.cgi/src/sys/lib/libkern/arch/sh3/udivsi3_i4i.S?rev=HEAD

-uwe