Linux Kernel Finally Deprecating A.out Support

[moilami]

Haha, had maybe a boring day because laughed at this.

[jo-erlend]

Moving to 100% ELF support. Elrond and Legolas agree.

I just have to point out that Elrond was only 50% elf.

[jacob]

Linus should deprecate systemD (as a failed attempt from a cretin) finally in favor of sysVinit .

Michael should deprecate trolls in favour of people who actually have something to say.

[dwagner]

I already envision fans of a.out writing an "interpreter" that you can use in

echo "#!/bin/aout" | cat - your.old.a.out.executable >still_running_executable

[Jaxad0127]

Not only does it not say exactly which symbol is from which library, but even worse you can load libraries for no reason (there was a thread some time ago where Fedora decided to strip away unused imports etc, a problem that should NOT exist in a sane format, like PE) if the symbol is satisfied from somewhere else.

How does PE prevent unused imports? The format can't possibly not allow them, leaving the loader to either ignore them or block the executable, both of which should be possible with ELF.

[Weasel]

How does PE prevent unused imports? The format can't possibly not allow them, leaving the loader to either ignore them or block the executable, both of which should be possible with ELF.

Because you have to get out of your way to import symbols that you don't use anywhere.

Let's say you link to a library, but don't import and symbols from it in the end (perhaps because of some #ifdef or compiler optimization removing dead code, etc). It is trivial to see that there are unused libraries in PE because they will have no symbol table. It is impossible to know for an ELF after-the-fact (i.e. after linking) with global symbols (non-versioned) because you get a bunch of symbols and a bunch of libraries. So you need a linker option (what that thread was about) to do it during linking.

Sure you can scan your libraries and see whether they export those symbols, but what if the ELF file is not supposed to run on YOUR machine? Perhaps your libs don't export those symbols cause they're old or whatever.

This is the problem with ELF mentality, it assumes that "machine you compile on = environment you run on" which is just retarded.

For example, you also have to specify "-Wl,-unresolved-symbols=ignore-in-shared-libs" or else it assumes the above retardation, again.

[F.Ultra]

For example, you also have to specify "-Wl,-unresolved-symbols=ignore-in-shared-libs" or else it assumes the above retardation, again.

Take 2 seconds to contemplate if that is due to ELF or due to GCC/ld having a wrong default.

[Weasel]

Take 2 seconds to contemplate if that is due to ELF or due to GCC/ld having a wrong default.

It's both. They evolved together, like most executable or object formats. In fact ELF itself can be used even for object files, to show you that it is designed for the compiler/linker, when the resulting binary should be something different. Global namespace is probably for the same reason (it's the most straightforward conversion from language like C to symbols, but it's obviously stupid; with DLLs you'd need a .def file etc, but that's proper design).

[oiaohm]

Let's say you link to a library, but don't import and symbols from it in the end (perhaps because of some #ifdef or compiler optimization removing dead code, etc). It is trivial to see that there are unused libraries in PE because they will have no symbol table. It is impossible to know for an ELF after-the-fact (i.e. after linking) with global symbols (non-versioned) because you get a bunch of symbols and a bunch of libraries. So you need a linker option (what that thread was about) to do it during linking.

Is this behaviour to ELF standard you have not asked that question. The answer is no it not.

https://blogs.oracle.com/solaris/inside-elf-symbol-tables-v2

There is a thing that is called STT_FILE . When you static link with gcc and ld you nicely have STT_FILE insert into the symbol table so you know exactly what .o file did a function come from. Now you dynamic link gcc and ld results in no STT_FILE entries for the .so files used. You use the sun complier to make a dynamic linked binary the STT_FILE entries are in the dynamic link table so you know what .so file each function should be acquired from. This is not a ELF format bug this is a linker/loader bug to be correct GNU binutils and loader(glibc) bug.

There is a fun little fact that Weasel is not aware of. How did you historically do dynamic global symbols in PE. You used a dll name [GLOBAL] this is why you can put a library name in PE file without it having a symbol because that used to be used with global mode in the early Windows NT loader. So this bug that Weasel complains about with what he calling ELF also did exist in PE platforms at one point but the loader and compilers were modified no longer to support it. The format was not modified to fix this and ELF is in the same location.

I don't know how many more times I will have to tell Weasel this. Its not a problem with the ELF format. Its the problem with the compleirs/linkers/loaders used around the ELF format.

[Weasel]

There is a thing that is called STT_FILE . When you static link with gcc and ld you nicely have STT_FILE insert into the symbol table so you know exactly what .o file did a function come from. Now you dynamic link gcc and ld results in no STT_FILE entries for the .so files used. You use the sun complier to make a dynamic linked binary the STT_FILE entries are in the dynamic link table so you know what .so file each function should be acquired from. This is not a ELF format bug this is a linker/loader bug to be correct GNU binutils and loader(glibc) bug.

No it's not a linker bug because it discards. It's a bug in the design of ELF that it ALLOWS you to work without STT_FILE or whatever.

You won't get it, so it's really a lost cause. You see, a loader CAN ignore a bunch of things, like a missing STT_FILE section. You can't ignore it in PE, though, because quite simply you CANNOT have a symbol table without a module associated with it. There's just "no way to encode it", not simply a matter of "loader refuses to load it". You cannot have it in the format, it's not up to the loader, like with ELF. This is what you simply won't get.

There is a fun little fact that Weasel is not aware of. How did you historically do dynamic global symbols in PE. You used a dll name [GLOBAL] this is why you can put a library name in PE file without it having a symbol because that used to be used with global mode in the early Windows NT loader. So this bug that Weasel complains about with what he calling ELF also did exist in PE platforms at one point but the loader and compilers were modified no longer to support it. The format was not modified to fix this and ELF is in the same location.

I have no idea what in the world you are talking about here. Who the fuck even used global symbols? They're literally cancer and as bad as global variables.

I don't know how many more times I will have to tell Weasel this. Its not a problem with the ELF format. Its the problem with the compleirs/linkers/loaders used around the ELF format.

Re-read my reply to F.Ultra. ELF was directly designed around the needs of linkers and languages (C) at the time, as a direct translation, without requiring extra stuff like .def files. Which is idiotic.