LoadLibrary: Support For Loading Windows DLLs On Linux

[Weasel]

STT_FILE some_so_name
STT_FUNC func1 STT_FUNC func2
STT_FUNC func3
STT_FILE some_other_so_name
STT_FUNC func1
STT_FUNC func2
STT_FUNC func3

This is where you are completely wrong. As the ELF format was in fact designed in object mode to have a STT_FILE entry as well. The linking not done yet does not mean you don't want to have space to record a asm directive saying get X function from X library. Yes this was include in the ELF specification but its not being used.

It's not being used because there's no freaking option to do that from standard C/C++. You'd need a compiler extension or the like.

Anyway I really couldn't care less about the loader. Just because an ELF loader refuses to accept global symbols doesn't mean global symbols are good. They shouldn't be able to be stored in the first place. A PE loader cannot even use global symbols, unless it's non-compliant. Meanwhile an ELF loader that accepts global symbols is compliant.

So look, stop talking about loaders, I'm talking about the on-disk format. Global symbols should simply not exist. Not optionally.

[oiaohm]

It's not being used because there's no freaking option to do that from standard C/C++. You'd need a compiler extension or the like.

This is wrong look at java and its class files. C++ classes and name space could be done as STT_FILE entries basically same way java does classes. C++ no compiler extension to language required. C you can use like what used with symver

__asm__(".symver realpath,realpath@GLIBC_2.2.5");

Anyway I really couldn't care less about the loader. Just because an ELF loader refuses to accept global symbols doesn't mean global symbols are good. They shouldn't be able to be stored in the first place. A PE loader cannot even use global symbols, unless it's non-compliant. Meanwhile an ELF loader that accepts global symbols is compliant.

This is where you are repeatedly wrong when you read the elf standards global symbol stuff you are talking about is non compliant. So a ELF loader that accept global symbols is non compliant no matter how much you attempt to weasel point it does not change. You have issues with non complaint ELF loader.

So look, stop talking about loaders, I'm talking about the on-disk format. Global symbols should simply not exist. Not optionally.

Global symbols without control only exist in ELF because the standard is not followed. This is why suggesting changing standards particular to a standard that is missing features compared to ELF is not a good idea. If they implemented a standard that techically forbid uncontrolled global symbols with uncontrolled global symbols nothing will stop them doing it again with another format.

ELF standard has many things that PE does not.

PT_INTERP entry yes the PT_INTERP that is called the ELF interpreter or the ELF dynamic loader loader. Why is this configurable entry in the ELF format. The theory was that different languages would do their own loaders. But today we are stuck using the C ELF loader for everything that has been optimised to hell including removing ELF standard features to optimise it. Same was though that different languages would also make their own static linkers so there are space left to record information that could be useful on a per language base in the ELF format.

STT_FILE being a open string its meant to be a really useful thing. ELF you should not need C++ name mangling. STT_FILE string could have soname@class in it for import and export table could have STT_FILE class in it for C++. STT_FILE entry could even be used in static linking.

ELF format design is brilliant our usage of it is absolute crap.

If the problem is in the loader ELF was design to have more than 1 loader. So it possible fix a loader caused problem for new programs without disrupting old programs.

ELF was design to allow these issues to be fixed at a latter date as well. It possible even now to add more STT_ options to ELF. PE format was not designed to have its import/export tables extended to store more information. Problem here people run that in reverse with ELF to store the least amount of information possible.

Yes C++ could have added to the ELF format STT_CLASS and had it loader process it.

Sorry Weasel ELF is on a completely different level to PE. It really said that the advantages of ELF have not been used.

[Weasel]

This is wrong look at java and its class files. C++ classes and name space could be done as STT_FILE entries basically same way java does classes. C++ no compiler extension to language required. C you can use like what used with symver

C++ has no class files. The fact you say could be done proves that it's not possible and thus requires a compiler extension.

__asm__(".symver realpath,realpath@GLIBC_2.2.5");

You realize that's not standard portable C++, right?

Hint: try compile that on Windows or other platform that doesn't have .symver. Heck, even one with a different assembler instead of GNU AS.

Thanks for shooting yourself in the foot.

Lastly I told you I don't want to argue about the loader. Why can ELF even store global symbols if they shouldn't be loaded? Bad design.

[oiaohm]

C++ has no class files. The fact you say could be done proves that it's not possible and thus requires a compiler extension.

C++ standard does not define how class in the final binary.

You realize that's not standard portable C++, right?

Do you not realise there no such thing as standard portable C++ because items like name managling and memory management design are purely left up to the complier to implement it how ever they

Hint: try compile that on Windows or other platform that doesn't have .symver. Heck, even one with a different assembler instead of GNU AS.

https://github.com/GregorR/gelfload

Horrible reality here is that not a problem if we really want to-do it. Because the ELF standard has .symver you can use a ELF loader on windows that supports .symver and it will work of course. At this point you could put presure on Microsoft and OS X to extend their formats to provide .symver of course PE will be a total nightmare to add this stuff. OS X format has room for expand in the right places.

Lastly I told you I don't want to argue about the loader. Why can ELF even store global symbols if they shouldn't be loaded? Bad design.

Really I have answered this a different way this time listen.

Why can I create a PE with import table under the name GLOBAL instead of proper DLL name and have a PE loader work anywhere. This is not that the standard say you should do this. Its not bad design. It bad implementation. Heck it is possible to use a DLL name of "" in PE import tables and be valid to standard of course windows PE loader is not going to load it. So yes you can store global symbols in PE standard just the Windows PE loader will not have a bar of it. There are other loaders of PE that will process a empty DLL name and will populate symbols from global funny enough some UEFI implementations. Yes weasel the computer you are sitting at could have a PE loader that does support global symbol resolve.

Yet some how when the ELF standards says you should not have global symbols that are global resolved its bad design of ELF for you instead of what it really is a bad implementation.

Weasel its about time you look at the format with a non bias eye. The ELF problem is implementations that don't obey the ELF standard. You can make PE implementation that don't obey the standard in loader and have exactly the same set of problems. So like it or not there is no difference here so this should not be sold as an advantage of PE over ELF because both formats are open to the same abuse problem.

Weasel no matter how much you argue will not remove the fact bad implementations of PE loaders exist with the same defect. Will not change that the ELF standard does not say you should implement it with that defect either.

Really Weasel your point does not hold up on the idea everyone need to move to PE if you say the fact ELF has bad implementation because a bad implementation can be replaced with time and effort with a good implementation. Then it comes down to what format has the most features.

Heck you straight up admitted PE cannot store symbol versions so PE is feature behind by your own admit here.

[Weasel]

C++ standard does not define how class in the final binary.

Do you not realise there no such thing as standard portable C++ because items like name managling and memory management design are purely left up to the complier to implement it how ever they

Ok, you're a lost cause. I'm obviously referring to the SOURCE CODE giving this information.

In other words: Your __asm__ statement.

In what world is that portable?

[oiaohm]

Ok, you're a lost cause. I'm obviously referring to the SOURCE CODE giving this information.

In other words: Your __asm__ statement.

In what world is that portable?

Yes what in the world is portable. Microsoft is PE is portable to Linux and OSX with .net because they have loader on those platforms that will process it. Microsoft claim that its portable does not matter if other platform compilers cannot build the stuff either.

That asm statement
__asm__(".symver realpath,realpath@GLIBC_2.2.5");

Is writing stuff for a ELF loader to use, Turns out that direction is portable to most platforms that can run ELF Loaders this includes Windows and OS X.

Lest throw you bias crap out the window from the Microsoft model.

1) If you complier does not support the file format and cannot make the binary in that format. Microsoft model of portable it does not matter.
2) As long as you have a loader the format is portable.


Remember you said "try compile that on Windows" it will in complie on windows that asm stable and usable with different ELF loaders for Windows.

When you come to looking at how portable ELF or PE format is the measure comes simpler.

1) Does the format have loader fairly much every where yes both ELF and PE does.
2) How many cpu architectures does the format support. ELF supports more cpu archectures than PE so by this metric is the more portable one.

Weasel you have been saying everyone should change to PE from ELF no matter what is breaks. This means I should not give rats about thing you class as portable issues because you have already set that you don't care if you take away ELF users features like ifunc or version symbols or other feature the ELF format does give.


Like or not by Microsoft define of what is portable ELF is more portable than PE.

Weasel if you are going to suggest everyone change and require breaking everyone workflow you better not be suggesting a format that cannot store all the information. ELF/PE hybrid that wine does is technically a pure ELF file it just exploits ELF ability to store extra information.

Welcome to horrible reality Weasel ELF can store everything PE format can but PE format cannot store everything ELF format can. This is not talking about missing entries that cause the issue you are complaining about.

[Weasel]

I don't think you understand what "portable source code" means or what the C++ standard is written for.

It's not for the binary output format, buddy. Nobody was talking about the binary.

[ssokolow]

I don't think you understand what "portable source code" means or what the C++ standard is written for.

It's not for the binary output format, buddy. Nobody was talking about the binary.

I think oiaohm is talking about how, depending on your definition of "portable", "portable source code" for C or C++ is surprisingly un-useful, given how much is left up to the individual platforms to specify, rather than required for every standards-compliant implementation to support.

[oiaohm]

I don't think you understand what "portable source code" means or what the C++ standard is written for.

It's not for the binary output format, buddy..

Sorry you were saying people should use PE over ELF this is talking about binary not portable source code . This is you attempting to use goal post.

C++ standard source could be converted into ELF using some of it features that you don't have in PE and you would not need C++ name mangling that is not part of the C++ standard.

Nobody was talking about the binary.

No you were talking about binary with PE vs ELF. Now you attempted move the goal post to talk about portable source instead. Get back on topic comparing the PE and ELF binary formats the one the technically the best by what the standard defines is ELF. Implementations of ELF have some issues.

In the past you have admitted to only look at implementations not what the ELF standard defines. You have kept on doing this and you need to stop. ELF loader from glibc and others need to change. Segregated dynamic linking need to come standard feature of all ELF loaders that will get rid of 99% of the real world usage difference between PE and ELF. Of course implement STT_FILE or a new entry in ELF standard to put in the dynamic symbol table to denote what so file the symbol should come from can be done as well.

Here what people don't notice if they don't look at the loader.

/lib/ld-linux.so.2

Hang on one min why is there a 2 there. That is know as glibc2 or libc6. Yes libc5 and before on Linux was /lib/ld-linux.so.1. Did the change from ld-linux.so.1 to ld-linux.so.3 require rebuilding all so files the answer as no. Did that change the way stuff was dynamically resolves yes it added the version symbol look up

So migration between loaders that change the dynamic load process of elf have already been done one with almost zero disruption. It can in fact be done again.

https://en.wikipedia.org/wiki/Executable_and_Linkable_Format

Here another interesting point. In the ELF format program header that on every executable/so there a value e_ident[EI_ABIVERSION] entry this had been bumped before. This is how new glibc2/libc6 programs were able to load libc5 .so files without trouble.

In theory you can run 255 different dynamic loader methods for resolving symbols in the one application using one dynamic loader using the e_ident[EI_ABIVERSION] value.

ELF current implementation issue you complain about Weasel can be fixed by what is built into ELF standard. Thing is this would not be the first time using the section of the ELF standard.

Its quite possible for people to say to glibc/binutils/gcc make "segregated dynamic linking" standard across the board this can be done on legacy .so files without breaking anything. Make STT_FILE or allocate like STT_SONAME(as in a new STT entry ELF standard allows for this to happen) for the dynamic import table as mandatory in all new made ELF files. The new ELF files will have a bumped e_ident[EI_ABIVERSION] number up by 1 this way the loader knows what are new files and what are old files.

Basically if you demand above and get above the total problem you complain about with elf will disappear in about 5-10 years the same pace libc5-libc6 transition took. No major disruptions required for this transition because performing this transition is designed into the ELF standard. Change to PE is a major disruption that result in reduction of features like no ifunc and not required to fix the problem.

Think about this if you have used every single e_ident[EI_ABIVERSION] the ELF format you can start again from 0 if require by in fact bumping the e_ident[EI_VERSION] or taking another byte out of pad.

ELF format is not set in stone it was in fact designed to be changed over time as required and has changed over time as required.

[Weasel]

Sorry you were saying people should use PE over ELF this is talking about binary not portable source code . This is you attempting to use goal post.

C++ standard source could be converted into ELF using some of it features that you don't have in PE and you would not need C++ name mangling that is not part of the C++ standard.

You're the one attempting to move goal posts, idiot. We were talking about object files (i.e. COFF) and ELF and why they have global symbols. C++ has nothing to do with PE, that's the linker's problem. This was about object files.

No you were talking about binary with PE vs ELF. Now you attempted move the goal post to talk about portable source instead. Get back on topic comparing the PE and ELF binary formats the one the technically the best by what the standard defines is ELF. Implementations of ELF have some issues.

Let's recap.

PE doesn't have global symbols, it cannot store them.
ELF can because it's "one format" for both a DLL and an object file. So it sucks as a dynamic link library.

Object files must be able to store global symbols, because that's how C/C++ work. At least with portable source code.
COFF and ELF can store global symbols, which is good for object files, not for a dynamic library.

Since I had to repeat it because you're too dense, I think I'm done here.