5 ms·

There was a time when shared libraries were a necessity. Not to mention supporting myriad architectures. That was a different era. Conditions have changed.

by gwu78 12y ago

There was a time when shared libraries were a necessity. Not to mention supporting myriad architectures. That was a different era. Conditions have changed. Of course, the designs and implementations have not. They are still in heavy use, 20 years later. What "just works" is never questioned. I am glad to see some people questioning the old assumptions. Unrelated question: Why does Linux pass arguments in registers instead of using the stack?

deafeningblow 12y ago
What makes you say conditions have changed? Why should I have to wait for everything that consumes OpenSSL downstream to be updated/recompiled to fully patch my system?
- icebraining 12y ago
  Playing Devil's advocate, why do you need to wait for others to recompile the software?
- gwu78 12y ago
  Are you suggesting that the original purpose of shared libraries relates to patching software? Others seem to be suggesting that the emergence of dynamic linking was a response to general limitations in secondary storage and memory. Limitations that no longer exist.
  - icebraining 12y ago
    Does it have to be the original purpose to be a useful feature?
    - gwu78 12y ago
      Is this supposed to be an answer? I like marssaxman's comment. I'm not sure I would call this a "feature" because I think of "features" as being intentional and if marssaxman is correct, this justification for shared library use was an accidental side effect. But I have limited knowledge of the history behind dynamic linking. Hence my questions. I am just curious.
- marssaxman 12y ago
  It's easy to see why sysadmin types like shared libraries, even though that ability is an accidental side-effect of an architecture originally developed as a way to save disk space, but as an end user I strongly prefer isolated applications which depend only on the base OS. Updating one program and thereby inadvertently updating a bunch of other unrelated programs is an anti-feature for me as an end user, because it means I can't trust the state of my system. I don't want to waste time figuring out why things no longer work the way they used to; I want to keep on using my computer for its intended purposes. Therefore I, as an end user, update software as infrequently as possible, and only do so when I don't have anything else I need to do with the computer for the rest of the day, just in case I have to waste a bunch of time figuring out why things don't work anymore. If I were a sysadmin, and maintaining the computer were my job, this would not be a problem, because figuring out why things don't work and fixing them is what I would be trying to use the computer for; but as an end-user, I just want things to work. If every application were built with static linking, and system libraries only updated with an explicit system upgrade, I would be much more likely to upgrade frequently, because it would be possible to know and limit the scope of churn implied by any given upgrade act.
cma 12y ago
registers are much faster than stack, assuming you immediately make use of them; to use them from the stack you have to load them into registers anyway in most cases
- leaveyou 12y ago
  In theory passing args in registers is faster because you avoid one copy in simple/small routines (the ones that perform a very simple op on the reg arguments and return). In practice there are way more complex routines than simple routines and the arg from register is copied back on the stack in the local variables area of the routine because it needs that register to perform some op or simply because it needs that reg to pass an argument to a subroutine. So in practice, the arg copy is only shifted from the caller to the callee.
  - cma 12y ago
    For x86 you might be right, because there arent many registers. I doubt it is as much of an issue for x86-64. It depends on a lot of stuff that I don't have the numbers for, but, from your example: If the functions tend to perform operations that are dependent on the arguments first (I know lots of functions I see do, doing things like an immediate null pointer check and pointer dereference on an arg) then it is better to already have them in a register, you can often immediately replace the value of the pointer in the register with the value from dereferencing. For your point about there being more complex functions than simple ones, it doesn't matter which there are more of, it matters which are called more often. If every complex function on average calls 0.5 complex functions and 5 simple functions, you still probably have more simple function calls overall.
  - gsg 12y ago
    Except in leaf functions, where the win materializes. Leaf functions are a healthy fraction of calls, counting dynamically, so passing args in registers is a good idea. It's true that the benefit isn't enormous.
mappu 12y ago
>Why does Linux pass arguments in registers instead of using the stack? It's a convention. Depending on your architecture, compiler and API, it uses the stack in a lot of cases (cdecl/stdcall on i386). Linux on AMD64 always uses the SYSV ABI which uses registers as much as possible (i'm assuming for performance reasons, since 'fastcall' does the same on i386).
- raverbashing 12y ago
  I didn't know that was the name of it, interesting, though it sounds like an Anachronism http://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI http://en.wikipedia.org/wiki/X86_calling_conventions#System_...
- gwu78 12y ago
  "It's a convention." Does Minix use that convention? How about BSD?
  - icebraining 12y ago
    "The calling convention of the System V AMD64 ABI is followed on Solaris, Linux, FreeBSD, Mac OS X, and other UNIX-like or POSIX-compliant operating systems." http://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI http://en.wikipedia.org/wiki/X86_calling_conventions#System_...
    - gwu78 12y ago
      int80h.org Anyway, the original question was _why_ does Linux use registers to pass arguments. Arguments can be passed on the stack, but Linux chose to use registers. Why this choice over the other option? Do you know the answer? Just curious.
      - icebraining 12y ago
        It's because in theory, it's faster to copy the values to registers than to have to push them all to the stack and then have the callee pop them. At least that was the thought behind Microsoft's __fastcall, which was their original version of a calling convention using registers, though in that case it seems the benchmarks aren't conclusively in support of the theory.

by gwu78 12y ago

deafeningblow 12y ago

What makes you say conditions have changed? Why should I have to wait for everything that consumes OpenSSL downstream to be updated/recompiled to fully patch my system?

icebraining 12y ago
Playing Devil's advocate, why do you need to wait for others to recompile the software?
gwu78 12y ago
Are you suggesting that the original purpose of shared libraries relates to patching software? Others seem to be suggesting that the emergence of dynamic linking was a response to general limitations in secondary storage and memory. Limitations that no longer exist.
- icebraining 12y ago
  Does it have to be the original purpose to be a useful feature?
  - gwu78 12y ago
    Is this supposed to be an answer? I like marssaxman's comment. I'm not sure I would call this a "feature" because I think of "features" as being intentional and if marssaxman is correct, this justification for shared library use was an accidental side effect. But I have limited knowledge of the history behind dynamic linking. Hence my questions. I am just curious.
marssaxman 12y ago
It's easy to see why sysadmin types like shared libraries, even though that ability is an accidental side-effect of an architecture originally developed as a way to save disk space, but as an end user I strongly prefer isolated applications which depend only on the base OS. Updating one program and thereby inadvertently updating a bunch of other unrelated programs is an anti-feature for me as an end user, because it means I can't trust the state of my system. I don't want to waste time figuring out why things no longer work the way they used to; I want to keep on using my computer for its intended purposes. Therefore I, as an end user, update software as infrequently as possible, and only do so when I don't have anything else I need to do with the computer for the rest of the day, just in case I have to waste a bunch of time figuring out why things don't work anymore. If I were a sysadmin, and maintaining the computer were my job, this would not be a problem, because figuring out why things don't work and fixing them is what I would be trying to use the computer for; but as an end-user, I just want things to work. If every application were built with static linking, and system libraries only updated with an explicit system upgrade, I would be much more likely to upgrade frequently, because it would be possible to know and limit the scope of churn implied by any given upgrade act.

cma 12y ago

registers are much faster than stack, assuming you immediately make use of them; to use them from the stack you have to load them into registers anyway in most cases

leaveyou 12y ago
In theory passing args in registers is faster because you avoid one copy in simple/small routines (the ones that perform a very simple op on the reg arguments and return). In practice there are way more complex routines than simple routines and the arg from register is copied back on the stack in the local variables area of the routine because it needs that register to perform some op or simply because it needs that reg to pass an argument to a subroutine. So in practice, the arg copy is only shifted from the caller to the callee.
- cma 12y ago
  For x86 you might be right, because there arent many registers. I doubt it is as much of an issue for x86-64. It depends on a lot of stuff that I don't have the numbers for, but, from your example: If the functions tend to perform operations that are dependent on the arguments first (I know lots of functions I see do, doing things like an immediate null pointer check and pointer dereference on an arg) then it is better to already have them in a register, you can often immediately replace the value of the pointer in the register with the value from dereferencing. For your point about there being more complex functions than simple ones, it doesn't matter which there are more of, it matters which are called more often. If every complex function on average calls 0.5 complex functions and 5 simple functions, you still probably have more simple function calls overall.
- gsg 12y ago
  Except in leaf functions, where the win materializes. Leaf functions are a healthy fraction of calls, counting dynamically, so passing args in registers is a good idea. It's true that the benefit isn't enormous.

mappu 12y ago

>Why does Linux pass arguments in registers instead of using the stack? It's a convention. Depending on your architecture, compiler and API, it uses the stack in a lot of cases (cdecl/stdcall on i386). Linux on AMD64 always uses the SYSV ABI which uses registers as much as possible (i'm assuming for performance reasons, since 'fastcall' does the same on i386).

raverbashing 12y ago
I didn't know that was the name of it, interesting, though it sounds like an Anachronism http://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI http://en.wikipedia.org/wiki/X86_calling_conventions#System_...
gwu78 12y ago
"It's a convention." Does Minix use that convention? How about BSD?
- icebraining 12y ago
  "The calling convention of the System V AMD64 ABI is followed on Solaris, Linux, FreeBSD, Mac OS X, and other UNIX-like or POSIX-compliant operating systems." http://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI http://en.wikipedia.org/wiki/X86_calling_conventions#System_...
  - gwu78 12y ago
    int80h.org Anyway, the original question was _why_ does Linux use registers to pass arguments. Arguments can be passed on the stack, but Linux chose to use registers. Why this choice over the other option? Do you know the answer? Just curious.
    - icebraining 12y ago
      It's because in theory, it's faster to copy the values to registers than to have to push them all to the stack and then have the callee pop them. At least that was the thought behind Microsoft's __fastcall, which was their original version of a calling convention using registers, though in that case it seems the benchmarks aren't conclusively in support of the theory.