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

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.

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

[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]

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]

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]

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]

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

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.

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.

[oiaohm]

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.

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.

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/gabi4+/ch4.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.

[Weasel]

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.

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.

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.

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.

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.

[oiaohm]

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.

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.

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.