public inbox for discuss@lists.illumos.org (since 2011-08)
 help / color / mirror / Atom feed
* [discuss] whats the /lib/libc.so.1 mount for ?
@ 2025-01-31 16:43 Enrico Weigelt, metux IT consult
  2025-01-31 16:45 ` Udo Grabowski (IMKASF)
  0 siblings, 1 reply; 5+ messages in thread
From: Enrico Weigelt, metux IT consult @ 2025-01-31 16:43 UTC (permalink / raw)
  To: illumos-discuss

Hi folks,

I'm wondering what the /lib/libc.so.1 mount is actually for.

Are there different libc versions that might be mounted ?
Where and how exactly is the decision made ? Who mounts it ?


thx
--mtx


--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287


------------------------------------------
illumos: illumos-discuss
Permalink: https://illumos.topicbox.com/groups/discuss/T9811b44617503fdd-M09e26da71c3934cf352381de
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [discuss] whats the /lib/libc.so.1 mount for ?
  2025-01-31 16:43 [discuss] whats the /lib/libc.so.1 mount for ? Enrico Weigelt, metux IT consult
@ 2025-01-31 16:45 ` Udo Grabowski (IMKASF)
  2025-01-31 16:55   ` Udo Grabowski (IMKASF)
  0 siblings, 1 reply; 5+ messages in thread
From: Udo Grabowski (IMKASF) @ 2025-01-31 16:45 UTC (permalink / raw)
  To: discuss


[-- Attachment #1.1: Type: text/plain, Size: 841 bytes --]



On 31-01-2025 17:43, Enrico Weigelt, metux IT consult wrote:
> Hi folks,
> 
> I'm wondering what the /lib/libc.so.1 mount is actually for.
> 
> Are there different libc versions that might be mounted ?
> Where and how exactly is the decision made ? Who mounts it ?
> 
It depends on the hardware capabilities of the processor, for
Intel it's usually libc_hwcap1.so.1, for AMD I have
libc_hwcap2.so.1, and there's a libc_hwcap3.so.1 (ARM?) too.

/lib/libc.so.1 on /usr/lib/libc/libc_hwcap2.so.1 
read/write/setuid/devices/dev=4c50002 on Mon Dec 16 12:29:34 2024

-- 
Dr.Udo Grabowski  Inst.of Meteorology & Climate Research IMKASF-SAT
https://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology          https://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 6041 bytes --]

[-- Attachment #2: Type: text/plain, Size: 248 bytes --]


------------------------------------------
illumos: illumos-discuss
Permalink: https://illumos.topicbox.com/groups/discuss/T9811b44617503fdd-Ma37cea5943384a665e308681
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [discuss] whats the /lib/libc.so.1 mount for ?
  2025-01-31 16:45 ` Udo Grabowski (IMKASF)
@ 2025-01-31 16:55   ` Udo Grabowski (IMKASF)
  2025-01-31 17:09     ` Jason King
  0 siblings, 1 reply; 5+ messages in thread
From: Udo Grabowski (IMKASF) @ 2025-01-31 16:55 UTC (permalink / raw)
  To: discuss


[-- Attachment #1.1: Type: text/plain, Size: 1200 bytes --]



On 31-01-2025 17:45, Udo Grabowski (IMKASF) wrote:
> 
> 
> On 31-01-2025 17:43, Enrico Weigelt, metux IT consult wrote:
>> Hi folks,
>>
>> I'm wondering what the /lib/libc.so.1 mount is actually for.
>>
>> Are there different libc versions that might be mounted ?
>> Where and how exactly is the decision made ? Who mounts it ?
>>
> It depends on the hardware capabilities of the processor, for
> Intel it's usually libc_hwcap1.so.1, for AMD I have
> libc_hwcap2.so.1, and there's a libc_hwcap3.so.1 (ARM?) too.
> 
> /lib/libc.so.1 on /usr/lib/libc/libc_hwcap2.so.1 read/write/setuid/ 
> devices/dev=4c50002 on Mon Dec 16 12:29:34 2024

Here are the specific capabilities used in the different versions (3 is
not ARM), see them with 'file':
/usr/lib/libc/libc_hwcap3.so.1: [SSE MMX CMOV FPU]
/usr/lib/libc/libc_hwcap2.so.1: [SSE2 SSE MMX CMOV AMD_SYSC FPU]
/usr/lib/libc/libc_hwcap1.so.1: [SSE MMX CMOV SEP FPU]
-- 
Dr.Udo Grabowski  Inst.of Meteorology & Climate Research IMKASF-SAT
https://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology          https://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 6041 bytes --]

[-- Attachment #2: Type: text/plain, Size: 248 bytes --]


------------------------------------------
illumos: illumos-discuss
Permalink: https://illumos.topicbox.com/groups/discuss/T9811b44617503fdd-Mde8e7fec6159d8f69e761c9c
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [discuss] whats the /lib/libc.so.1 mount for ?
  2025-01-31 16:55   ` Udo Grabowski (IMKASF)
@ 2025-01-31 17:09     ` Jason King
  2025-01-31 22:18       ` Joshua M. Clulow via illumos-discuss
  0 siblings, 1 reply; 5+ messages in thread
From: Jason King @ 2025-01-31 17:09 UTC (permalink / raw)
  To: illumos-discuss

[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]

The biggest differences I’m aware of between them is how syscalls are performed. Newer (relatively speaking) CPUs have nicer instructions for syscalls as well as things like optimized implementations of some of the libc string functions. During boot, the system will try to pick the ‘best’ one to use and loopback mount it over the more generic libc.

Newer libraries would likely use linker capabilities to do this in a single library (if the author is aware of them – it’s actually a neat feature that isn’t as well known as it should be IMO). I don’t have access to the relevant history (this all predates illumos), but my best guess is that the linker functionality to allow selection of an optimized implementation of a function based on CPU capabilities probably came later  (and no one’s been interested in doing the work to consolidate them – I suspect it’d get rather tedious).


From: Udo Grabowski (IMKASF) <udo.grabowski@kit.edu>
Date: Friday, January 31, 2025 at 10:56 AM
To: discuss@lists.illumos.org <discuss@lists.illumos.org>
Subject: Re: [discuss] whats the /lib/libc.so.1 mount for ?


On 31-01-2025 17:45, Udo Grabowski (IMKASF) wrote:
>
>
> On 31-01-2025 17:43, Enrico Weigelt, metux IT consult wrote:
>> Hi folks,
>>
>> I'm wondering what the /lib/libc.so.1 mount is actually for.
>>
>> Are there different libc versions that might be mounted ?
>> Where and how exactly is the decision made ? Who mounts it ?
>>
> It depends on the hardware capabilities of the processor, for
> Intel it's usually libc_hwcap1.so.1, for AMD I have
> libc_hwcap2.so.1, and there's a libc_hwcap3.so.1 (ARM?) too.
>
> /lib/libc.so.1 on /usr/lib/libc/libc_hwcap2.so.1 read/write/setuid/
> devices/dev=4c50002 on Mon Dec 16 12:29:34 2024

Here are the specific capabilities used in the different versions (3 is
not ARM), see them with 'file':
/usr/lib/libc/libc_hwcap3.so.1: [SSE MMX CMOV FPU]
/usr/lib/libc/libc_hwcap2.so.1: [SSE2 SSE MMX CMOV AMD_SYSC FPU]
/usr/lib/libc/libc_hwcap1.so.1: [SSE MMX CMOV SEP FPU]
--
Dr.Udo Grabowski  Inst.of Meteorology & Climate Research IMKASF-SAT
https://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology          https://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026

------------------------------------------
illumos: illumos-discuss
Permalink: https://illumos.topicbox.com/groups/discuss/T9811b44617503fdd-M1bf20a2e57ee79e8c4bdc6b9
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

[-- Attachment #2: Type: text/html, Size: 5652 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [discuss] whats the /lib/libc.so.1 mount for ?
  2025-01-31 17:09     ` Jason King
@ 2025-01-31 22:18       ` Joshua M. Clulow via illumos-discuss
  0 siblings, 0 replies; 5+ messages in thread
From: Joshua M. Clulow via illumos-discuss @ 2025-01-31 22:18 UTC (permalink / raw)
  To: illumos-discuss

On Fri, 31 Jan 2025 at 09:09, Jason King <jason.brian.king@gmail.com> wrote:
> Newer libraries would likely use linker capabilities to do this in a single library (if the author is aware of them – it’s actually a neat feature that isn’t as well known as it should be IMO). I don’t have access to the relevant history (this all predates illumos), but my best guess is that the linker functionality to allow selection of an optimized implementation of a function based on CPU capabilities probably came later  (and no one’s been interested in doing the work to consolidate them – I suspect it’d get rather tedious).

I think it also depends on how much of the program text ends up having
to change.  In the libc case, though I have not looked at this moment,
it's conceivable that there are a lot of syscall stubs laced
throughout the program text.  A whole-library switch may facilitate
better sharing of pages, or might just be faster to link, etc.  It
would require some investigation and measurement to know one way or
another.


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org

------------------------------------------
illumos: illumos-discuss
Permalink: https://illumos.topicbox.com/groups/discuss/T9811b44617503fdd-M55052f5a732b87ae7a528ffd
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2025-01-31 22:19 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-01-31 16:43 [discuss] whats the /lib/libc.so.1 mount for ? Enrico Weigelt, metux IT consult
2025-01-31 16:45 ` Udo Grabowski (IMKASF)
2025-01-31 16:55   ` Udo Grabowski (IMKASF)
2025-01-31 17:09     ` Jason King
2025-01-31 22:18       ` Joshua M. Clulow via illumos-discuss

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).