svn commit: r368789 - head/libexec/rtld-elf/rtld-libc

[Ryan Libby]

On Sat, Dec 19, 2020 at 7:23 PM John Baldwin <jhb at freebsd.org> wrote:
>
> On 12/19/20 12:38 AM, Ryan Libby wrote:
> > Author: rlibby
> > Date: Sat Dec 19 08:38:31 2020
> > New Revision: 368789
> > URL: https://svnweb.freebsd.org/changeset/base/368789
> >
> > Log:
> >   rtld-elf: link udivmoddi4 from compiler_rt
> >
> >   This fixes the gcc9 build of rtld-elf32 on amd64, which needed an
> >   implementation of udivmoddi4.
> >
> >   rtld-elf uses certain functions normally found in libc, and so it
> >   includes certain files from libc in its own build.  It has two
> >   mechanisms to include files from libc: one that rebuilds source files in
> >   the rtld-elf environment, and one that extracts object files from a
> >   purpose-built no-SSP PIC archive.
> >
> >   In addition to libc functions, rtld-elf may need to link functions
> >   normally found in libcompiler_rt (formerly libgcc).  Now, add an ability
> >   to rebuild libcompiler_rt source files in the rtld-elf environment.  We
> >   don't yet have a need for an object file extraction mechanism.
> >
> >   libcompiler_rt could also supply udivdi3 and umoddi3, but leave them
> >   alone for now.
> >
> >   Reviewed by:        arichardson, kib
> >   Sponsored by:       Dell EMC Isilon
> >   Differential Revision:      https://reviews.freebsd.org/D27665
>
> Hmm, I had just linked against libcompiler_rt directly as we do on arm:
>
> https://reviews.freebsd.org/D26199
>
> It was stuck waiting for review feedback.
>
> Given libcompiler_rt is a static archive, we could probably safely link
> against it directly unlike libc where we have to pick specific object
> files.
>
> --
> John Baldwin

Sorry, I wasn't aware of your review.  Do you want this backed out?

I did see the arm path.  I think it is not quite right, because
libcompiler_rt is compiled with -fstack-protector-strong, which is not
compatible with rtld.  However, it will work in practice if stack
protection doesn't actually get used on any linked function.

We could build a special libcompiler_rt with no stack protection like we
do just for rtld with libc, but since we'd only want this no-SSP library
for rtld, that's not much different from just rebuilding its source
files in rtld.  In addition, by rebuilding specific files we avoid
overlinking--although that may not be a big deal (?), and there may be
other cleaner ways to avoid that (?).

On a tangent, it might be neat to split out an rtld_bootstrap
(everything through init_rtld()) so that only the bootstrap code needs
to be compiled and linked with no-SSP.  I looked at this some but I
figured there might not be appetite for a bunch of reorganization of
rtld just to enable SSP.  Anyway the bootstrap code would still need
these particular libcompiler_rt functions to be no-SSP, as they get used
in the printf procedure, which I am guessing the bootstrap may need.

Ryan