From: David Laight <David.Laight@ACULAB.COM> To: 'Adrian Bunk' <email@example.com>, Linus Torvalds <firstname.lastname@example.org> Cc: Tom Stellard <email@example.com>, Nick Desaulniers <firstname.lastname@example.org>, Masahiro Yamada <email@example.com>, "Nathan Chancellor" <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, clang-built-linux <firstname.lastname@example.org>, Fangrui Song <email@example.com>, Serge Guelton <firstname.lastname@example.org>, Sylvestre Ledru <email@example.com> Subject: RE: Very slow clang kernel config .. Date: Sun, 2 May 2021 11:35:19 +0000 [thread overview] Message-ID: <0eba31ea508f4ec491f56e3b8c85fb6c@AcuMS.aculab.com> (raw) In-Reply-To: <20210502093123.GC12293@localhost> From: Adrian Bunk > Sent: 02 May 2021 10:31 > > On Sat, May 01, 2021 at 09:32:25AM -0700, Linus Torvalds wrote: > >... > > Yes, it can save on disk use, but unless it's some very core library > > used by a lot of things (ie particularly things like GUI libraries > > like gnome or Qt or similar), the disk savings are often not all that > > big - and disk is cheap. And the memory savings are often actually > > negative (again, unless it's some big library that is typically used > > by lots of different programs at the same time). > >... > > I think people have this incorrect picture that "shared libraries are > > inherently good". They really really aren't. They cause a lot of > > problems, and the advantage really should always be weighed against > > those (big) disadvantages. > >... > > Disk and memory usage is not the biggest advantage. > > The biggest advantage of shared libraries is that they enable > distributions to provide security fixes. > > Distributions try hard to have only one place to patch and one package > to rebuild when a CVE has to be fixed. > > It is not feasible to rebuild all users of a library in a > distribution every time a CVE gets published for a library. Absolutely. You'd also need to rebuild every application that might include the static version of the broken function. Good luck finding all those on a big install. OTOH just splitting a compiler into multiple shared objects that have no other use is, as Linus said, stupid. Building shared libraries requires the same control as building the kernel. The user interface mustn't change. You can add new functions, but not change any existing ones. This is easy in C, difficult in C++. Since PLT lookups can only handle code, you really don't want data areas shared between the program and library. If the size ever changes 'horrid things (tm)' happen. We compile any shared libraries with -fvisibility=hidden and mark any entry points with __attribute__((visibility("protected"))). This means that calls with a library are simple PC-relative and only the entry points are visible outside. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2021-05-02 11:35 UTC|newest] Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-29 21:53 Linus Torvalds 2021-04-30 0:19 ` Nick Desaulniers 2021-04-30 2:22 ` Nick Desaulniers 2021-05-01 0:19 ` Nick Desaulniers 2021-05-01 0:23 ` Nick Desaulniers 2021-05-01 0:25 ` Nick Desaulniers 2021-05-01 0:40 ` Nick Desaulniers 2021-05-01 1:22 ` Linus Torvalds 2021-05-01 1:48 ` Nick Desaulniers 2021-05-01 2:16 ` Fangrui Song 2021-05-01 3:32 ` Tom Stellard 2021-05-01 16:32 ` Linus Torvalds 2021-05-01 19:57 ` Serge Guelton 2021-05-01 22:39 ` Linus Torvalds 2021-05-01 23:55 ` Fangrui Song 2021-05-01 21:58 ` David Laight 2021-05-02 9:31 ` Adrian Bunk 2021-05-02 11:35 ` David Laight [this message] 2021-05-02 16:12 ` Linus Torvalds 2021-05-02 16:45 ` Adrian Bunk 2021-05-02 16:49 ` Linus Torvalds 2021-05-02 17:55 ` Adrian Bunk 2021-05-02 17:59 ` Linus Torvalds 2021-05-02 21:48 ` Adrian Bunk 2021-05-04 22:02 ` Miguel Ojeda 2021-05-05 0:58 ` Theodore Ts'o 2021-05-05 17:21 ` Miguel Ojeda 2021-05-04 21:32 ` Miguel Ojeda 2021-05-05 11:05 ` David Laight 2021-05-05 13:53 ` Miguel Ojeda 2021-05-05 14:13 ` David Laight 2021-05-05 16:06 ` Miguel Ojeda 2021-05-05 16:25 ` David Laight 2021-05-05 17:55 ` Miguel Ojeda 2021-05-03 1:03 ` Maciej W. Rozycki 2021-05-03 14:38 ` Theodore Ts'o 2021-05-03 14:54 ` Theodore Ts'o 2021-05-03 17:14 ` Maciej W. Rozycki 2021-05-03 16:09 ` David Laight 2021-05-04 23:04 ` Greg Stark 2021-05-05 0:55 ` Theodore Ts'o 2021-05-01 23:37 ` Mike Hommey 2021-05-02 5:19 ` Dan Aloni 2021-05-03 16:48 ` Tom Stellard 2021-05-03 19:00 ` Fangrui Song 2021-04-30 0:52 ` Nathan Chancellor 2021-04-30 2:21 ` Nick Desaulniers
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=0eba31ea508f4ec491f56e3b8c85fb6c@AcuMS.aculab.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='RE: Very slow clang kernel config ..' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).