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

[oiaohm]

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?

Really some UEFI Elf loaders pull off exactly what I described where you can in fact use matching library names and symbol names. Its fun finding that some of then support DT_RUNPATH.

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.

dlmopen that libcapsule is using in fact support matching DLL/so name and Symbol name. Where the DLL/so name is in fact different library.

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

DLL cannot do it with its general symbol import tables it against the rules. ELF format include method to-do just using it import tables but not implemented in most implementations.

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.

Really here is the fun bit. /lib/libthirdpary.so was making STT_FILE symbol in the ELF format be respected on the first OS with ELF. So this was just making the loader respect the ELF format.

Its not that the ELF format cannot store the information. Its that the complier/link decides not to store the information and the dynamic linker decides to not to require it and not even process it even when it present.

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.

Is there a subsystem entry in a ELF file. Yes interpreter (PT_INTERP). Problem is most linux systems only have 1 being ld-linux.so LSB did attempt to create a ld-lsb.so.

ELF format can store all the need information. Problem is having implementations. We cannot magically travel back in time and alter what is all ready out there.

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.

What you are missing is then you have to build a global symbol name-space by forcing other things in the dynamic linker as well. Windows is using a KnownDLLs.hack this results in less flexibility than the ELF format in fact offers.

What is need is implementations that fully exploit what elf format can do.

Short term this mean using LD_AUDIT, providing your own loaders, libcapsule....
1) provide use cases requiring the elf features.
2) provide personal to work on glibc to implement these features.

Removing global namespace only to end up having to fake recreate it is stupid.

Think about it you could write a PE dynamic loader that disregards all those dll declares on symbols. Then using that loader you could stupidly argue that PE format does not support the feature. This is exactly the case what has happened with ELF. The ELF format supports declaring what library a symbol is from. It is more compact than the PE version. PE version has embedded dll name per symbol entery. Where STT_FILE symbol gives you declaration in batches.

The fact you don't find any STT_FILE symbols defined in gcc/llvm ELF binaries by default and to define them results in having to use linker scripts is a pain.

To make STT_FILE work you will need a lot of the framework stuff that libcapsule is working on.

ELF format is fine. ELF dynamic linkers and ELF compliers need work. Using LD_AUDIT you can patch the existing loader and make it work without needing to modify the elf format and have the information come from the binary is one proof that is not the format and the fact that some UEFI implementations with ELF loaders also have it working. The idea that you have that its ELF format is completely wrong. Its implementations of the ELF format that have it wrong one happens to be a very common one.

Basically PE cannot do as much as ELF does it missing features out it format. Please note dlsym has RTLD_NEXT this also should have you questioning . Why do you need a next look up if a symbol name can only exist once in the ELF link map the answer is you would not need it. Yes the global link map support symbols of the same name from different .so files to be listed it also horrible support same name in 1 so file and this is following the design of the global link map in the ELF format. Using dlinfo you can query what .so file a dlsym load thing is from.

See where not having the STT_FILE symbol support dynamic loader causes problem. Its the STT_FILE symbol that allowed declaring to the dynamic loader what library it should be expecting the following symbols for the imported symbols.

Linux platform Libstdc++ clashes are in fact more often than not exactly the same so name/library name different path something windows loader is not going to help with. STT_FILE used with DT_RUNPATH can cope. In fact making the loader automatically load libraries from DT_RUNPATH into own linkmap and search this link map first for application and application provided libraries and make host libraries resolve with host files in their own link map. This is my problem I don't see that we need the link map per dll as windows does.

We need more than 1 link map. Host and application link maps would go a long way. Host and application link map could be split a lot of the time just by DT_RUNPATH. Yes application doing plugins would still have to declare split link map at plugin load and that would be use dlmopen instead of just dlopen your plugins libcapsule would provide the framework for this.

The biggest problem I have with elf is STT_FILE is not implemented in the common dynamic loaders if it was using symbols of the same name but different soname would not be a problem. You still would have the problem of symbols of the same name from the same library name but on a different path problem. DT_RUNPATH could be used to fix this too just extend the dynamic loader a bit. None of these fix requires altering ELF format.

The link_map design in the elf format documentation tells you that particular problems should not exist in full implementations of the ELF format. Weasel you have been using broken ELF implementations to say what ELF can do.

[Weasel]

Really some UEFI Elf loaders pull off exactly what I described where you can in fact use matching library names and symbol names. Its fun finding that some of then support DT_RUNPATH.

I've no idea how this is relevant to what I said at all. It's like you reply randomly...

dlmopen that libcapsule is using in fact support matching DLL/so name and Symbol name. Where the DLL/so name is in fact different library.

I'm not sure you understand the simple fact that needing something like libcapsule proves that ELF is retarded. I mean, otherwise, you wouldn't need it. Magic? Logic!

DLL cannot do it with its general symbol import tables it against the rules. ELF format include method to-do just using it import tables but not implemented in most implementations.

You can specify the path tho as I said already...

Really here is the fun bit. /lib/libthirdpary.so was making STT_FILE symbol in the ELF format be respected on the first OS with ELF. So this was just making the loader respect the ELF format.

Its not that the ELF format cannot store the information. Its that the complier/link decides not to store the information and the dynamic linker decides to not to require it and not even process it even when it present.

Alright, since you don't seem to get it. Let me put it in an easier way for you to understand. If the compiler/linker decides not to store that information, it should be illegal to even attempt to write such an output. This shouldn't even be a "feature", nor optional. In fact, you really should *not* be able to import a symbol without specifying the library it's from.

How many times must I repeat this before you at least show you read it and address it?!

Is there a subsystem entry in a ELF file. Yes interpreter (PT_INTERP). Problem is most linux systems only have 1 being ld-linux.so LSB did attempt to create a ld-lsb.so.

ELF format can store all the need information. Problem is having implementations. We cannot magically travel back in time and alter what is all ready out there.

See above. Its ability to NOT store that information is the problem here. And yes we can't go back in time, that's the pity.

Even today people build ELF binaries like that, which is just disgusting. Just remove the fucking global symbol namespace already and force people to stop using it. It serves, literally, no good use and any "hacks" it is useful for have workarounds. It may be harder to use hacks, but hacks are hacks for a reason, they're supposed to not be "easy" to implement.

What you are missing is then you have to build a global symbol name-space by forcing other things in the dynamic linker as well. Windows is using a KnownDLLs.hack this results in less flexibility than the ELF format in fact offers.

KnownDLLs has nothing to do with symbols but with DLL names, stop mixing the names with symbol exports.

Removing global namespace only to end up having to fake recreate it is stupid.

No you won't need that garbage, ever. Anywhere.

Think about it you could write a PE dynamic loader that disregards all those dll declares on symbols. Then using that loader you could stupidly argue that PE format does not support the feature. This is exactly the case what has happened with ELF. The ELF format supports declaring what library a symbol is from. It is more compact than the PE version. PE version has embedded dll name per symbol entery. Where STT_FILE symbol gives you declaration in batches.

No because it is illegal to do that with DLL and in that case it wouldn't be DLL anymore.

DLLs store exports in tables, and same with imports -- and the symbol import table is linked from the DLL name table. Here's the fun fact: the MODULE table comes first. The symbol table doesn't exist without the module table; encoding it would give you an invalid DLL per the format specs. So the module table (i.e. the names) comes first, and THEN the symbols associated with that name.

Thus, you CANNOT have symbols imported WITHOUT being linked to some DLL (or exe), which is where they should be loaded from. The format forbids it.

Sure you can "ignore" the DLL and load random symbols and use your own custom hacks but then you don't have a DLL loader, you have some broken piece of crap not adhering to the spec.

In the same way you can "load" an mp3 file using ogg vorbis, and fail, even if it has .mp3 extension.

The fact you don't find any STT_FILE symbols defined in gcc/llvm ELF binaries by default and to define them results in having to use linker scripts is a pain.

Again, not finding them should make it an illegal ELF. In fact the entire symbol table should be required to link to the STT_FILE thing or w/e it's called.

[oiaohm]

Again, not finding them should make it an illegal ELF. In fact the entire symbol table should be required to link to the STT_FILE thing or w/e it's called.

https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/stlac/index.html

STT_FILE is entry that you can put in the elf symbol tables. STT_FILE can be followed by a stack of symbols that are from that file. This is how you set-up a local to .so/exe resolve in ELF format. Has been valid to be in the .dynsym table. Declaring library local instead of global alters how to should be mapped in.

STT_FILE is the method to import functions with conficting names and other things.

You would kind of expect third party programs using stuff like libstdc++ to be using STT_FILE. You would expect the dynamic loader to respect that STT_FILE is a local load only so not overwrite global defines from host libraries and not to be overriden by host libraries as long as file name that is used is unique.

The reality of ELF is the first form of dynamic elf only has the .dynsym symbol table. There are no global symbols yet. Yes STT_FILE declare in .dynsym is how to ask for local look up of file and not to have that file loaded into the global symbol space.

The dynamic section that comes latter is where you ask for .so files to be loaded into the global name space.

So by the elf format there are two ways to load a .so file.

Dynamic section shoves it into global name space where it should resolve down to be 1 symbol= 1 function shared application wide.
STT_FILE in the .dynsym say it should be the one that the dt_runpath of what ever file(executable/library) this is in would find.

Not supporting STT_FILE in the symbol tables is not being to ELF specification. Yes application needing different libstdc++ to host should be a simple problem to solve third party application just request the version they want with STT_FILE in the .dynsym in the libraries and applications they provide. Trying to get gcc or llvm to-do this is a uphill battle ruined by the dynamic linker not support it.

As the orcale documentation lists the usage of STT_FILE fell out of favour as for most cases globally dynamic worked.

[Weasel]

oiaohm Well, I'm talking about Linux. I don't think it uses the exact same ELF as Solaris since whatever you say with STT_FILE clearly doesn't apply here. Maybe Solaris was sane. But Linux is not.

[oiaohm]

oiaohm Well, I'm talking about Linux. I don't think it uses the exact same ELF as Solaris since whatever you say with STT_FILE clearly doesn't apply here. Maybe Solaris was sane. But Linux is not.

This is that you don't know the history. Linux ELF has not always suffered from this issue. Its really simple to forget for a while you could run binary that targeted Unix in general in the early time frame of Linux the iBCS stuff. These where elf binaries and did have STT_FILE support in their loader/interpreter .

So there was a time when you could use exactly the same ELF binary on Solaris and Linux as long as ibcs loaders were on both. Linux ELF format is straight from Sun documented method.

There has been 3 universal things.
1) Never made STT_FILE into glibc provided elf dynamic loader/interpreter .
2) Required brutal bashing of gcc/binuntils to get binaries using the STT_FILE feature.
3) The developers who made elf loaders with the feature of STT_FILE end up out of a job and was not paid by his employer to make them anyhow.

Windows to heavily mess with the loader you have to go into kernel space.

With Linux the loader is a static elf binary. So you can in fact ship your application with your own loader.

This is why your arguement that I could not talk about kernel mode stuff is so bull when you are talking about functionality open to application developers to have the equal you have to cover the windows cases where applications modify the loaders. Why because under Linux you are free to ship a static binary with your own application replacing the system wide loader. NixOS that is a Linux distribution made patchelf so they could change the loaders on binary elf files.

ELF format is not the problem. Linux ELF binaries from different points of history had the feature.

The combination of symbol versions with STT_FILE gives something way more powerful than PE format has.

So the question is more who is going to pay to have STT_FILE support implemented and merged into the glibc and made practical for developers to use from compiler side.

The ELF binary format is not the problem. The common loaders of dynamic elf binaries are the problem and the ELF standard allows you to set your own interpreter.

[Guest]

The funny thing is that even with stringent blacklists, chromium and chrome can crash without adjusting any settings on some GPUs, with my prime example being Intel UHD 620.

On the other hand, in majority of cases it's just safe to forcibly override the blacklist, and the browser will end up doing the right thing and accelerating as much as it can.