3 ms·
That's a smart way to do it and it certainly would have made things easier. I'm a big fan of the UNIX philosophy of small simple programs. But please consider t
by jart 4y ago
That's a smart way to do it and it certainly would have made things easier. I'm a big fan of the UNIX philosophy of small simple programs. But please consider that this facility is also used for ShowCrashReports() which prints a backtrace upon a SIGSEGV, SIGBUS, etc. When a crash spontaneously happens, it's not always easy or possible to run it again piped into an addr2line-like tool. It makes life simpler to have reporting facilities baked into each binary, and a lot of effort went into making it lightweight. Right now life.com (i.e. exit(42)) in the default build mode is 68kb (although it's 12kb in MODE=tiny) and that includes --ftrace, --strace, support for six operating systems and it embeds an operating system in each binary too, so it can run on autonomously on metal.
- Veserv 4y agoWhy do you need to run the crashing program again? In the case you bring up you already printed the encoded backtrace. You can just copy the contents printed onto your screen/log file and post-process that as long as you have also output the relevant runtime linking information used to make the encoding.
- AlotOfReading 4y agoIs there a reason why you don't call GetSymbolTable() yourself in the runtime init or at least through an __attribute__((constructor)) if you want to keep it C?
- jart 4y agoIt's mostly to avoid imposing the latency on startup unless it's necessary or the user requested it. But now that you mention it, I think it should be updated to call that automatically in cases where the --strace flag is passed. Thanks!