New gABI/ELF Spec Available for Public Review

Posted by ketralnis@reddit | programming | View on Reddit | 11 comments

[-]

iris700@reddit

Just don't compile debug builds with compression. Oh wait, you just want to be a cynic, this isn't something that you actually care about. Carry on.

[-]

2rad0@reddit

Just don't compile debug builds with compression. Oh wait, you just want to be a cynic, this isn't something that you actually care about. Carry on.

If I don't want binaries bloated with debug info I strip it from the binary it's a quick process and basically a non-issue as it stands. Not sure who this helps exactly or why they care about it enough to add every and all possible compression algorithm to the ELF standard. Oh wait they're just looking to make their mark on tech and further complicate everything in the process. Are they paranoid about running the strip command? What is the real problem they were trying to solve?

[-]

--_@reddit

Debug symbols often increase the size of binaries enough that people won't ship them in their release builds, even though they could benefit from debug information for things like crash reports. Compression seems like a pretty obvious solution here, you get both debug information and a reasonable binary size.

[-]

2rad0@reddit

you get both debug information and a reasonable binary size.

could benefit from debug information for things like crash reports.

So glibc is going to have to implement zstd compression in order to print a backtrace? Modern software 'engineering' is not looking too good. All to save what, a couple MB's of symbol names? It's amazing that this was never a problem until now, considering you can get a drive with 1,000,000,000,000 byte capacity for ~$50. Who was asking for this? How many bytes do they think are consumed by symbol names on functions?

[-]

--_@reddit

So glibc is going to have to implement zstd compression, et, al. in order to print a backtrace?

Yes, I don't see the issue here.

damn thing already depends on python to compile, WHAT NEXT? Modern software 'engineering' is not looking too good. All to save what, a couple MB's of symbol names?

Seems to me like you're just yelling at clouds.

It's amazing that this was never a problem until now, considering you can get a drive with 1,000,000,000,000 byte capacity for ~$50.

So we should just be wasteful for no apparent reason?

Who was asking for this? How many bytes do they think are consumed by symbol names on functions?

Debug information is more than just symbol names. It's not uncommon for full debug information (with type names, source/variable mappings, etc) to make up for 50+% of a binary.

Another flaw in this ultra modern push to squeeze file sizes down a couple MB's is that you won't be able to grep for a symbol in a binary.

Just use a tool that actually understands the ELF format. Grepping through binaries is not very reliable or efficient. Combined with the fact that dynamically linked libraries require you to write fragile shell scripts even today.

[-]

2rad0@reddit

Yes, I don't see the issue here.

It's another piece of junk in the stack that can cause problems, and fail in a critical time of need, all to save a couple MB's, and we still don't know who is requesting this feature and why.

Seems to me like you're just yelling at clouds.

You'd be yelling too if you wasted as much time as me diagnosing and fixing issues this low-level in the OS stack.

So we should just be wasteful for no apparent reason?

So we should start obsoleting low level debugging tools without stating the case for why it must be added?

Debug information is more than just symbol names. It's not uncommon for full debug information (with type names, source/variable mappings, etc) to make up for 50+% of a binary.

If you care THIS MUCH about binary size, you're not going to include all of that information in the first place. All a crash reporter needs is the back trace. AND, if you are building a release build with debug information it potentially will contain misleading information as a release build uses optimizations, and a proper debug build will disable optimizations so the information is accurate.

Grepping through binaries is not very reliable or efficient.

I can grep my entire system in like 2-3 minute, every file on the system.

[-]

iris700@reddit

JESUS FUCKING CHRIST YOU DON'T HAVE TO USE IT