MaskRay

Nice!

In llvm-project, obj2yaml pretty prints an object file in YAML and yaml2obj can convert the output back to an object file.

The test cases are a good way to explore the functionality: https://github.com/llvm/llvm-project/tree/main/llvm/test/too... https://github.com/llvm/llvm-project/tree/main/llvm/test/too...

Linkers and Loaders

I have analyzed a few object file formats in another blog post https://maskray.me/blog/2024-01-14-exploring-object-file-for... (HN discussion: https://news.ycombinator.com/item?id=38998914)

ELF is technically not complicated and simpler than COFF and Mach-O.

Yes! I immediately thought about APE when I read The 86open Project's FAQ. However, I feel that APE is less related to the blog post so decide not to add the link to the post.

- 2003-2010 The SCO Group

- 2011- Xinous, but Xinous has stopped updating https://www.sco.com/developers/gabi/latest/contents.html . It seems that Xinous has moved on from System V based OpenServer/UnixWare. The newer OpenServer seems to be based on FreeBSD. They likely no longer care about the System V ABI.

Nowadays, people make proposals to the generic-abi Google Group. Essentially, a proposal is considered "standardized" if it receives approval from GNU, LLVM, and Ali Bahrami (Solaris representative).

Many GNU extensions are implemented by LLVM and adopted by BSD and newer ELF-based OSes. For extensions that are considered generic enough, it's recommended to propose them through the generic-abi Google Group. psABI documents generally prefer generic extensions over GNU or LLVM-specific ones.

Decker builds on the legacy of HyperCard and MacPaint, and utilizes an interesting little language (https://beyondloom.com/decker/lil.html 2022 HN discussion: https://news.ycombinator.com/item?id=33393283)

I feel that The SCO Group's role in the evolution of the System V ABI seems to have been more of a curator/editor than an innovator, inheriting the System V ABI from previous entities. Given that the Tool Interface Standard (TIS) Committee has essentially released the ELF-related chapters into the public domain, and others have made changes, it's unclear what specific rights The SCO Group (and now Xinuos) could claim to reserve. (That said, their maintenance work needs to be remembered.)

Thank you! This will be very useful. Yes, for C/C++ one needs:

* ISA manual * ELF (generic ABI, psABI (e.g. x86-64-psABI), OSABI) * DWARF * Floating-point * Language standards * Itanium C++ ABI

and probably a few other stuff.

> it seems like my failure to find the most up-to-date specification is simply because one doesn't exist.

While the up-to-date specification is unavailable, hopefully it is not too bad because all essential features have been completed as of 2001:)

RELR is a linker and loader feature, not on the compiler side. Compressed debug sections are a pretty natural extension.

A few folks have asked me the generic ABI status (unmaintained?) and the availability of an up-to-date specification (no). I compiled “History” and “Evolution of the generic ABI” in the blog post.

I have two specific questions:

- Key features (symbol visibility, section groups, SHF_MERGE, etc) were all available as of April 2001. Where can we find the discussion mailing lists? Are they still available?

- How does the ABI end up being “All rights reserved” by SCO? Tool Interface Standard (TIS) Portable Formats Specification, version 1.2 effectively put the specification in the public domain.

Interesting. Traditionally, Clang's -O1 and higher optimizations have been considered less debuggable than GCC's.

Sony developers have proposed changes to improve the debugging experience and some work has been done, e.g. https://discourse.llvm.org/t/rfc-redefine-og-o1-and-add-a-ne...

* change representation to help make -g not change codegen : https://discourse.llvm.org/t/rfc-debuginfo-proposed-changes-...

Thanks for mentioning nasm.

Both GNU assembler and LLVM integrate assembler parse and match instructions only once. hey then store an internal representation in memory and perform fixed-point iteration. The section/fragment representation gives a lot of flexibility.

In contrast, nasm parses and matches instructions multiple times depending on the optimization level. It also assigns addresses during parsing and uses an ad-hoc method for JMP/JCC instructions. The end conditions of the fixed-point iteration algorithm (global_offset_changed and stall_count) seem unconventional. -O0 does not "relax all" short jumps to near jumps.

There is ongoing work to improve debuggability for optimized code. https://discourse.llvm.org/t/rfc-redefine-og-o1-and-add-a-ne...

``` Mode | Execution Time | Debuggability | Compile Time O0 | 1.0000 | 1.0000 | 1.0000 Og | 0.3439 | 0.5357 | 1.8630 O1 | 0.3082 | 0.4241 | 1.7880 O2g | 0.2823 | 0.4845 | 3.0420 O2 | 0.2514 | 0.3908 | 2.9380 ```

Thanks for posting:)

I added this sentence to the article, hopefully making it clearer:

> If h is in the range [0x0fffff01,0x0fffffff] in the previous iteration, shifting it by 4 and adding *name may make h larger than UINT32_MAX.

The subject should be "glibc and DT_GNU_HASH" :) Hope this gives some background information for "Easy Anti-Cheat" users.

Interposing libc.so symbols in a shared object is not affected by -fno-semantic-interposition or -Bsymbolic

https://maskray.me/blog/2021-05-16-elf-interposition-and-bsy...

Solaris offers a similar model called direct bindings.

Folks may be interested in the two blog posts which have more technical details: https://maskray.me/blog/2021-05-09-fno-semantic-interpositio... https://maskray.me/blog/2021-05-16-elf-interposition-and-bsy...

There are some screenshots in https://github.com/MaskRay/ccls/wiki/Emacs

If you use vim/neovim, https://www.reddit.com/r/vim/comments/99utc7/ccls_languagecl...