Announcement

Collapse
No announcement yet.

Google Still Doesn't Trust Linux GPU Drivers Enough To Enable Chrome Video Acceleration

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by Weasel View Post
    xonotic sounds like it does "manually" what DLLs do "automatically".
    No xonotic does not do it manually. Only thing when gcc of llvm links you dynamic binary it must see .so files that don't contain version information or they annoy set version information so ruining your cross platform.

    You can have visual studio get creative and auto populate you manifest with unrequited version restrictions as well. Issue here is the linkers on Linux lack a good easy to use off switch to say yes I want this .so file but I don't want you to include version information on the symbols.

    The dynamic loader only cares about symbol version if version information is in the program. Lot of glibc symbol not defined not that the glibc on the system does not have a suitable version of that symbol. But that there was some fault in that symbol that could cause a security issue and and it was revised slightly altering its operation. Like 99.9 percent of the time application not going to have a issue with the old buggy version of that symbol.

    Originally posted by Weasel View Post
    I never complained about those. Those work *exactly* like DLLs and LoadLibrary/GetProcAddress. Why would I complain about them?
    dlopen places all the libraries you have requested in the same link map. LoadLibrary does not in fact do that. You find this out when you load 2 libraries with confliting runtimes. So like something that requires two different versions of libstdc++ library
    A.so requires libstdc++ version A
    B.so requires libstdc++ version B
    You dlopen A.so version A libstdc++ is now loaded into link map.
    you dlopen B.so it now gets version A libstdc++ and you application fails because B happened to be incompatible with version A of libstdc++.

    This would not happen right if you use LoadLibrary right.
    dlmopen give can use a different link map is totally not populated by anything.
    http://man7.org/linux/man-pages/man3/dlmopen.3.html
    You can read it here LM_ID_NEWLM
    https://linux.die.net/man/8/ld-linux
    Read down and start cursing.
    LD_AUDIT
    There is a group of librarys loaded into its own NEWLM.
    So for you application you can two link maps just using what the default loader provided. One problem fairly much totally disconnected from each other.

    So yes glibc developers gave themselves means to run libraries to diagnostics in own link map. But then application developers were not given that feature as a link flag. The fact that the loader can do it for audit diagnostics means it not a ELF format problem. Its a loader implementation problem. Remember version on ELF symbols are a glibc extension. There is no reason why version information could not include this library should be loaded in own link map.

    Loadlibrary is in fact like libcapsule. That is a unique link map per so/dll and common shared so/dlls. It shims provides a nice proxy for existing applications.

    Remember issues libcapsule are fixing in dlmopen are really required before should expose option from loader because there are libraries that need to be shared when you split a library off into its own link map.

    Originally posted by Weasel View Post
    Now you say "see ELF is not so bad it can be like DLLs if you load symbols manually" when the point was the loader not using dynamic lookup in code.
    The problem is not the format. ELF format allows you to define your own loader in .interp. Gcc own include loader at times does load 2 more more link map.

    One of the LSB developers did make a over wrapper for the glibc loader that provide this feature as well. But he got funding to do this work and he end up giving up on it. I am really thankful to valve for funding libcapsule this time around.

    Audit interface is not fun for application developers to say the least. Its not that ELF format cannot have .so files loaded in different link maps. Its that the most common ELF loaders don't give you the feature for anything other than Audit.

    LD_AUDIT libraries are loaded in to their unique link map by using dlmopen.

    Comment


    • Originally posted by oiaohm View Post
      No xonotic does not do it manually. Only thing when gcc of llvm links you dynamic binary it must see .so files that don't contain version information or they annoy set version information so ruining your cross platform.
      dlopen/dlsym and other things you do in code is exactly what manual means. Isn't that what you said it uses? So yes, that's exactly what I mean by "manually". You have to embed extra binary code for it.

      Originally posted by oiaohm View Post
      You can have visual studio get creative and auto populate you manifest with unrequited version restrictions as well. Issue here is the linkers on Linux lack a good easy to use off switch to say yes I want this .so file but I don't want you to include version information on the symbols.
      Those aren't code so no, it doesn't matter what the linker does.

      What matters is that with CODE (dlopen/dlsym) you BYPASS ELF's normal loader since they're just APIs -- proving it's complete shit.

      Originally posted by oiaohm View Post
      dlopen places all the libraries you have requested in the same link map. LoadLibrary does not in fact do that. You find this out when you load 2 libraries with confliting runtimes. So like something that requires two different versions of libstdc++ library
      A.so requires libstdc++ version A
      B.so requires libstdc++ version B
      You dlopen A.so version A libstdc++ is now loaded into link map.
      you dlopen B.so it now gets version A libstdc++ and you application fails because B happened to be incompatible with version A of libstdc++.
      This has nothing to do with dlopen. This is because of ELF's retarded global symbol namespace, which is EXACTLY the point of all of this.

      dlopen simply loads the library. If A.so used dlopen on libstdc++ version A, and B.so likewise used dlopen on libstdc++ version B, then there would be no issue. Of course it's gonna fail if it uses ELF's global namespace retardation, thanks for showing EXACTLY MY POINT of why it sucks!

      dlopen just in YOUR app is not enough, you need dlopen on EACH AND EVERY dependency, along with dlsym, to have sane behavior like with DLLs. In your example A.so and B.so use the retarded global namespace and that's **EXACTLY** why it fails.

      dlsym's first parameter is the MODULE from dlopen, so if you load version A and look up a symbol in it, it will NOT load it from version B, so you can have BOTH loaded in the same process. This is sane, and guess what? It works exactly like DLLs.

      And by that I don't mean GetProcAddress (which also works the same). I mean even the normal, automatic, DLL imports work exactly that way.

      Conclusion: ELF is retarded, DLL is sane.



      ELF is retarded no matter how you look at it. If you think the global namespace is good, then dlopen/dlsym must be retarded since they are like DLLs, so ELF is retarded due to this asymmetry.

      And if you think (like me) that the global namespace is retarded, then well... ELF is still retarded.

      You can't win with ELF. DLLs have only one (right) way to import, so you can win with DLLs.
      Last edited by Weasel; 12 October 2018, 08:23 AM.

      Comment


      • Originally posted by Weasel View Post
        ELF is retarded no matter how you look at it. If you think the global namespace is good, then dlopen/dlsym must be retarded since they are like DLLs, so ELF is retarded due to this asymmetry.
        Did not read Weasel
        LD_AUDIT libraries are loaded in to their unique link map by using dlmopen.
        Do you know what LD_AUDIT .so files do.

        These these load before you application in fact loads and takes control of the glibc/solaris dynamic loader.

        Originally posted by Weasel View Post
        This has nothing to do with dlopen. This is because of ELF's retarded global symbol namespace, which is EXACTLY the point of all of this.
        There is a off switch to ELF global symbol namespace. Happens to be there is one
        LD_AUDIT=thirdpary.so yourprogram

        Using the link header and a audit library you can bend the dynamic loader in glibc or solaris around your little finger.

        So with the right library in LD_AUDIT basically equal to subsystem in windows PE header.

        When a library is loaded in your program by the dynamic loader default chooses dlopen that puts everything in default link map. Using a LD_AUDIT library you get to use if libraries get opened with dlopen or dlmopen.

        Solaris by sun has LD_AUDIT .so files used for application compatibly.

        Yes glibc mostly support this. So you attempt load libarchive.so.12 you have a LD_AUDIT library loaded it gets informed of that request and is able to change it to libarchive.so.13 or any other number required.

        Comment


        • Originally posted by oiaohm View Post
          Did not read Weasel
          LD_AUDIT libraries are loaded in to their unique link map by using dlmopen.
          Do you know what LD_AUDIT .so files do.

          These these load before you application in fact loads and takes control of the glibc/solaris dynamic loader.
          And what has this to do with loading 3rd party libs with the same symbol names for different functions?

          Originally posted by oiaohm View Post
          There is a off switch to ELF global symbol namespace. Happens to be there is one
          LD_AUDIT=thirdpary.so yourprogram

          Using the link header and a audit library you can bend the dynamic loader in glibc or solaris around your little finger.

          So with the right library in LD_AUDIT basically equal to subsystem in windows PE header.

          When a library is loaded in your program by the dynamic loader default chooses dlopen that puts everything in default link map. Using a LD_AUDIT library you get to use if libraries get opened with dlopen or dlmopen.

          Solaris by sun has LD_AUDIT .so files used for application compatibly.

          Yes glibc mostly support this. So you attempt load libarchive.so.12 you have a LD_AUDIT library loaded it gets informed of that request and is able to change it to libarchive.so.13 or any other number required.
          You know this proves that ELF is retarded right? That you need workarounds when calling your app.

          I don't want to use any environment variables, sandboxes, or other crap that can easily break. Those things only exist because ELF is retarded. This should be done automatically, forcefully, and safely, enforced by ELF's format, so that the loader has no choice.

          I mean, kind of the whole point of this was: ELF is retarded and Linux userland is retarded as a consequence; so much so that you need hacks like flatpak or other bullshit redirections/environment variables.

          Hacks are always needed due to poor design in the first place. Proper design = no hacks needed.

          Comment


          • Originally posted by Weasel View Post
            And what has this to do with loading 3rd party libs with the same symbol names for different functions?
            Simple you have loaded a audit library before you application you can load 3rd party libraries with conflicting symbols if the audit library direct those libraries to be dlmopen instead of dlopen conflicts can be hidden the same exact way Windows does in windows subsystem modes for your dll files. But also note windows is not that nice in nt native mode. Basically the first versions of libcapsule existed on solaris as LD_AUDIT libraries.

            [QUOTE=Weasel;n1053958You know this proves that ELF is retarded right? That you need workarounds when calling your app.[/QUOTE]
            Sun developers designed ELF. They also designed LD_AUDIT for application diagnostics and compatibility.

            Originally posted by Weasel View Post
            I don't want to use any environment variables, sandboxes, or other crap that can easily break. Those things only exist because ELF is retarded. This should be done automatically, forcefully, and safely, enforced by ELF's format, so that the loader has no choice.
            Safety is not forced by PE format either. PE loaded in NT native subsystem does not have to be safe either.

            The loader of PE and ELF define it safety and in some cases proxy loaders.

            Windows NT is just as retarded when you look under the hood

            Remember solaris is the source of ELF. The need to use environment variables is that a flag is not implemented by glibc to define LD_AUDIT from the elf file itself. Solaris version ELF has this. Its like the --audit flag not work as well. There are many parts of glibc ELF support that are not complete because there has not been the investment to complete them.

            Dlmopen you find is completely missing on bsd, musl and android platforms because not enough applications have been using that feature so have gone in their loaders with pure global only.

            So the reality here is the Sun documentation of the ELF format details quite a few more features you should have. Issues is implementation incompleteness.

            The idea that ELF is retarded is wrong. Saying glibc implementation of ELF is retarded in places is right. But its less retarded than the freebsd, android.... libc replacements.

            Really Weasel you are calling ELF retarded without having a clue what features ELF format says should exist and was designed to support. ELF format is in fact designed to allow loading libraries with conflicting requirements. This is why libcapsule developer has been shocked by how easy it is. ELF structures and operations are ready for it. Issue is have loader with all those feature implemented.

            Comment


            • Originally posted by oiaohm View Post
              Simple you have loaded a audit library before you application you can load 3rd party libraries with conflicting symbols if the audit library direct those libraries to be dlmopen instead of dlopen conflicts can be hidden the same exact way Windows does in windows subsystem modes for your dll files. But also note windows is not that nice in nt native mode. Basically the first versions of libcapsule existed on solaris as LD_AUDIT libraries.
              I don't want to hide them, I want to load both. And if you neede a lib for it (libcapsule) it only shows how broken ELF is.

              Originally posted by oiaohm View Post
              Safety is not forced by PE format either. PE loaded in NT native subsystem does not have to be safe either.
              You're mixing concepts. It's the same format, so yes it's "safe" and will NEVER have symbol clashes. Never. The subsystem is irrelevant.

              I'm guessing you found your new buzzword to throw around from the other thread, so here's the deal: the argument in the other thread was about kernel32 always being the same function (HeapAlloc). That's it.

              This has nothing to do with symbol clashes.

              Originally posted by oiaohm View Post
              The loader of PE and ELF define it safety and in some cases proxy loaders.

              Windows NT is just as retarded when you look under the hood

              Remember solaris is the source of ELF. The need to use environment variables is that a flag is not implemented by glibc to define LD_AUDIT from the elf file itself. Solaris version ELF has this. Its like the --audit flag not work as well. There are many parts of glibc ELF support that are not complete because there has not been the investment to complete them.

              Dlmopen you find is completely missing on bsd, musl and android platforms because not enough applications have been using that feature so have gone in their loaders with pure global only.

              So the reality here is the Sun documentation of the ELF format details quite a few more features you should have. Issues is implementation incompleteness.

              The idea that ELF is retarded is wrong. Saying glibc implementation of ELF is retarded in places is right. But its less retarded than the freebsd, android.... libc replacements.

              Really Weasel you are calling ELF retarded without having a clue what features ELF format says should exist and was designed to support. ELF format is in fact designed to allow loading libraries with conflicting requirements. This is why libcapsule developer has been shocked by how easy it is. ELF structures and operations are ready for it. Issue is have loader with all those feature implemented.
              You realize that needing an extra library means that it is retarded, right? ELF is not ready for it, not until it ditches the global symbol namespace forever.

              Comment


              • Originally posted by Weasel View Post
                I don't want to hide them, I want to load both. And if you neede a lib for it (libcapsule) it only shows how broken ELF is.
                Really you do need to hide them. Libcapsule is superior to the default windows solution once you understand why I said hide when loading both.

                Originally posted by Weasel View Post
                You're mixing concepts. It's the same format, so yes it's "safe" and will NEVER have symbol clashes. Never. The subsystem is irrelevant.
                PE you can in fact have symbol clashes.
                https://limbioliong.wordpress.com/20...the-same-name/

                Using a link map as libcapsule does or using LD_AUDIT compatibility libraries do in fact allows you to have imports on the .so files be the same name but different versions and be loaded at the same time. This is because you have used hide as give out proper link maps.

                Remember how you are anti dlopen. So this means you are anti LoadLibrary for working around limitations as well.

                https://en.wikipedia.org/wiki/Rpath
                DT_RPATH and DT_RUNPATH are also not part of the PE format. So you don't have the means to say this library will use libraries from X path different to applicatiohn.

                You implement the solaris method of link maps when you are wanting to load both libraries in any conflicting case including library name and symbol name match. Yes dropping to NT native subsystem and taken control of the dynamic loader you can pull this off under windows NT as well but you cannot pull this off inside normal windows subsystems.

                Originally posted by Weasel View Post
                You realize that needing an extra library means that it is retarded, right? ELF is not ready for it, not until it ditches the global symbol namespace forever.
                Windows dyamnic loader has its own set of retard problems due to the way it was chosen to work around this issue. Think all the application in debian build with global symbol namespace. So there is no need to ditch it.

                Why does windows have a subsystem for command line applications and a subsystem for graphical applications and a subsystem called native for when you want full control of stuff this is also very retard. Those flag for graphical and cli can end up loading libraries into your application that your application never uses.

                libcapsule does not show how broken ELF is. It shows how broken the default dynamic link loader is. Things that libcapsule can pull off also show the windows dynamic link loader as broken as well.. Nothing in the ELF specifications says that a loader could not be intelligent.

                Weasel global symbol namespaces provides application diagnostic advantages. There is no point throwing the baby out with the bath water. Just because global symbol namespace has caused you some problems does not mean they are absolutely useless.

                Really would you even care if the dynamic loader was a little smarter so that libraries loaded from your applications DT_RUNPATH are in your application link map and libraries used to resolve the host libraries called were in host libraries link map. This would not have the windows per .dll link map but would also cure most of the problems. This dynamic loader smarts could treat third party parts this way and keep on treating distribution provide as 1 global link map avoiding overhead.

                ELF is in fact the more flexible format. We do have some issues where link map usage in dynamic loader for ELF have not be implemented fully.

                Also libcapsule is something you can do on older distributions without requiring them to update their old glibc or dyanmic loader to versions containing new features. Fixing these problems sometimes require a short term work around.

                Comment


                • Originally posted by oiaohm View Post
                  Really you do need to hide them. Libcapsule is superior to the default windows solution once you understand why I said hide when loading both.
                  No you don't. Symbol "foobar" from "libfoobar" is completely separate from symbol "foobar" from library "libxyz". It is, literally, like having two different names. That's how sane DLLs are designed.

                  Originally posted by oiaohm View Post
                  PE you can in fact have symbol clashes.
                  https://limbioliong.wordpress.com/20...the-same-name/
                  This proves just how much you really don't understand even BASICS.

                  If you think a DLL's *name* is a *symbol* then there's really no hope for explaining anything to you.

                  Please document yourself on what an exported symbol is first before wasting people's time with irrelevant links.

                  And as usual, your link crushes all of your arguments and you think it's the contrary, see this exerpt:
                  you will notice that the first parameter is the HMODULE of the target DLL from which you want to search for a particular function name (the second parameter).

                  3.3 This implies that you can use 2 different HMODULEs to obtain 2 function address from 2 different DLLs using the same function name.

                  3.4 Extrapolating this, you can in fact use multiple HMODULEs to obtain multiple function addresses from multiple DLLs using the same function name.

                  3.5 Hence not only can you load multiple DLLs of the same name, you can also load multiple exported functions (of the same name) from each of these DLLs.
                  I'm not sure what else you want when even your links prove the opposite of your claims here. See point 3.5 (last line).

                  This is something that you CANNOT DO with ELF *unless* you resort to dlopen/dlsym, which is why it is garbage.

                  Originally posted by oiaohm View Post
                  Remember how you are anti dlopen. So this means you are anti LoadLibrary for working around limitations as well.
                  No, I'm anti-dlopen for the purpose of obtaining mandatory symbol dependencies.

                  LoadLibrary is used for resolving OPTIONAL symbols, or OPTIONAL libraries, such as PLUGINS. If LoadLibrary fails to load, your app should still run (albeit with missing features).

                  If you use dlopen/LoadLibrary for any other reason, it's proof how retarded ELF is.


                  Originally posted by oiaohm View Post
                  libcapsule does not show how broken ELF is. It shows how broken the default dynamic link loader is. Things that libcapsule can pull off also show the windows dynamic link loader as broken as well.. Nothing in the ELF specifications says that a loader could not be intelligent.
                  It doesn't matter how intelligent it is. The loader may be broken, but I don't care about it. ELF (the format) simply lacks the necessary INFORMATION by default (as most people build, i.e. without versioned symbols) so the loader won't know what to do with the symbols and which library they are from. They get resolved after libs are loaded already.

                  Originally posted by oiaohm View Post
                  Weasel global symbol namespaces provides application diagnostic advantages. There is no point throwing the baby out with the bath water. Just because global symbol namespace has caused you some problems does not mean they are absolutely useless.
                  No global symbol namespace is an artifact of a lack of design, and of "developer convenience" in the early days. It's an archaic monstrosity.

                  Because (the original) ELF is built around the assumption that you compile everything on the same machine environment. It's not for "distribution", it was made to be a simple "build" environment format, that's why it exposes so much of the underlying source code quirks. In short, it was designed by programmers to get a quick job done for development.

                  The most lazy form of development with no upfront design, like most of open source libraries, but just "code first, design never" mantra. Which is why you see them change their major version as often as their shitty developers probably change their socks.

                  This is obvious in the design, and that's why it's so retarded. It lacks proper distribution design. It's literally just a simple extension to static libraries (which are 100% for development).

                  ELF is "sane" from a design perspective only in a world of source-code distribution, like Gentoo or other such distro, where you build everything yourself. That's how pathetic it is.
                  Last edited by Weasel; 14 October 2018, 08:31 AM.

                  Comment


                  • Originally posted by Weasel View Post
                    No you don't. Symbol "foobar" from "libfoobar" is completely separate from symbol "foobar" from library "libxyz". It is, literally, like having two different names. That's how sane DLLs are designed.
                    That is not how fully implemented elf is designed.

                    DT_RPATH and DT_RUNPATH are also not part of the PE format. So you don't have the means to say this library will use libraries from X path different to application.
                    Lets ignore this bit right Weasel.

                    Symbol foobar from libfoobar in two different paths but load is in the original specification.


                    Originally posted by Weasel View Post
                    Because (the original) ELF is built around the assumption that you compile everything on the same machine environment. It's not for "distribution", it was made to be a simple "build" environment format, that's why it exposes so much of the underlying source code quirks. In short, it was designed by programmers to get a quick job done for development.
                    LD_AUDIT/link.h is part of the first operating system by Sun and AT&T with the ELF format. Yes it had the presume third part applications would start with "LD_AUDIT=/lib/libthirdpary.so application"

                    LD_AUDIT/link.h controlling the dynamic link loader was put outside the ELF specifications. Has not been helped that gnu debugger historically will not debug audit libraries.

                    So its not the original ELF that has the problem. Yes the original has dlmopen as well.

                    Also the interpretation of symbolic mode in the ELF standard has altered from the first version.

                    Originally posted by Weasel View Post
                    It doesn't matter how intelligent it is. The loader may be broken, but I don't care about it. ELF (the format) simply lacks the necessary INFORMATION by default (as most people build, i.e. without versioned symbols) so the loader won't know what to do with the symbols and which library they are from. They get resolved after libs are loaded already.
                    This is not true. ELF format has something really useful STT_FILE symbol only used on Solaris.
                    http://refspecs.linuxbase.org/elf/ga...h4.symtab.html

                    STT_FILE exists in the symbol table to be able to specify what .so the following functions are from.

                    So its not that the elf format lacks the means to store the necessary information but that current day linkers of elf opt out on providing it and current day dynamic
                    link loaders are not process it.

                    So in a full blown old school sun/at&t unix. You could have program a loading "foobar" from "libfoobar" from RUNPATH=/lib/one then application loads library xzy also using "foobar" from "libfoobar" from RUNPATH=/libtwo no dlopen/dlsym this would be just normal elf dynamic linker resolve. So yes you could load a library name and symbol name pairs more than once referencing different libraries . This is just having a good ELF dynamic loader that proper supports the STT_FILE symbol. Yes if you have not worked out STT_FILE was triggering private link map.

                    What most people build is a ELF binary that is in fact not 100 percent to specification being run by a dynamic loader not 100 percent to specification.

                    GNU comes along and implements there libc clone of unix stuff they do ELF but doing link maps is hard stuff it lets not have dlmopen working as Solaris has and lets skip out on STT_FILE and let skip out on the RUNPATH effects as well.

                    Basically the elf format specification hides system many time superior to the PE one. Problem is lack of implementation.

                    Of course we now have to design a solution that will work on top of the broken stack with incorrectly made elf files and incorrectly made elf dynamic loader. libcapsule will.

                    Really the symbol table of a elf is not meant to be without entries saying what .so file the symbol should come from. ELF and PE is not that different once you look at specifications. PE is the weaker format on paper. ELF has big implementation problems.



                    Comment


                    • Originally posted by oiaohm View Post
                      That is not how fully implemented elf is designed.

                      DT_RPATH and DT_RUNPATH are also not part of the PE format. So you don't have the means to say this library will use libraries from X path different to application.
                      Lets ignore this bit right Weasel.

                      Symbol foobar from libfoobar in two different paths but load is in the original specification.
                      What?

                      1) I obviously was talking about DLLs, why even bring ELF up? I know ELF doesn't work that way, that *is* why it is retarded, thanks?
                      2) You can specify a path to the DLL if you really want to, to disambiguate it. Again, I never said the DLLs have the same name, but they CAN, that's BESIDE THE POINT though. I said they have the same exported SYMBOL NAMES.

                      Same name has NOTHING to do with symbols. NOTHING. But yes you can have same name with DLLs too, again, that's off topic so just drop it (and you are wrong anyway but I don't want to argue about it, because you can do that with ELF too so it's not bad in this situation).

                      Originally posted by oiaohm View Post
                      LD_AUDIT/link.h is part of the first operating system by Sun and AT&T with the ELF format. Yes it had the presume third part applications would start with "LD_AUDIT=/lib/libthirdpary.so application"

                      LD_AUDIT/link.h controlling the dynamic link loader was put outside the ELF specifications. Has not been helped that gnu debugger historically will not debug audit libraries.

                      So its not the original ELF that has the problem. Yes the original has dlmopen as well.
                      Actually, that is the problem. The fact that the ELF format does not store such information -- that's exactly the point. Specifying environment variables is OUTSIDE of the ELF format.

                      The format itself should provide ALL the information needed for proper loading, not rely on external factors such as manual code using dlopen, or environment variables, or other crappy setup stuff. All the info should be in the format for proper loading.

                      Originally posted by oiaohm View Post
                      This is not true. ELF format has something really useful STT_FILE symbol only used on Solaris.
                      http://refspecs.linuxbase.org/elf/ga...h4.symtab.html

                      STT_FILE exists in the symbol table to be able to specify what .so the following functions are from.

                      So its not that the elf format lacks the means to store the necessary information but that current day linkers of elf opt out on providing it and current day dynamic
                      link loaders are not process it.
                      Yeah, that's why I said you have to remove the global symbol namespace so that you are forced to use those features. I don't know why I have to repeat myself. This is literally the thing I said from which the entire argument sprung.

                      Comment

                      Working...
                      X