I can buy that an object file can be viewed as a relational db. Why SQLite though? Why not SQL query engine over the object file using a virtual table abstraction? I’m not seeing how most the SQLite features, with the exception of a subset of the query engine would translate over.

If the author wants to make a case for including schema metadata in an object file, again why SQLite? This strikes me a lot as someone who is trying to find uses for their favorite hammer (a very useful hammer I might say) rather than a serious exploration of what a new, improved object file format would look like.

(And that’s totally ok)

▲

jonhohle 2 hours ago | parent | next [-]

I wrote a tool[0] for manipulating elf files to support inline assembly for a compiler that doesn’t support it (based on a similar python tool). That required knowing any of the ELF sections that were being changed and how those changes would impact other sections.

sqlite would have made this pretty trivial. Replace the .text fields of a few rows. Insert a few rows for symbols, update a few from the old object.

The best part - there’s tons of library support for sqlite. If it was a new object format, there would be no support and I’d just have to write different parsers and generators.

The schema might the the biggest issue for efficiency. As others have noted, ELF->SELF->ELF might be the best use case for compatibility. That said, a big part of [0] was performance, and I don’t know how sqlite would have done compared to my naive elf parsing and manipulation.

0 - https://github.com/ttkb-oss/metrowrap

	▲	catlifeonmars 2 hours ago \| parent [-]
		> I wrote a tool[0] for manipulating elf files to support inline assembly for a compiler that doesn’t support it (based on a similar python tool). That required knowing any of the ELF sections that were being changed and how those changes would impact other sections. Would this normally be something the compiler would handle, or would it be the linker? I guess I’m curious how this would impact any optimizations the compiler implements. Also I’m guessing for your use case (elf edits) you would be looking at both SELECT and INSERT type operations?

▲

inigyou 2 hours ago | parent | prev [-]

sqlite is a great replacement for fopen - although the C interface is much more verbose.

	▲	catlifeonmars 2 hours ago \| parent [-]
		Oh do you mean as a way to store app state? Yeah 100%. It also helps that there are native reimplementations in many major languages, which means you don’t even need to link a libsqlite3 in contexts where it can sometimes be impractical to use the official C library (looking at you, CGO_ENABLED=0). And let’s not forget about sqlite3 running in wasm :)