Making use of backtrace?

Incoming wall of text.

I want to be able to make use of the backtrace function in order to ease debugging when my application crashes for a user. I found an implementation which seems to work on MinGW, so on the target platforms I can pretty much use SEH or signals to catch a crash, get a backtrace and do something with it (I also realize that sometimes, I won't be able to do anything good in the handler due to the state of the application. I'm willing to take that risk.)

The problem is, I don't know where to begin. I of course need the debugging information to be on a server of sorts, but I'm not even sure what I should do to get this information. How do I generate it? I know gdb can determine what line of code an address is, and I'm guessing gdb is using embedded debug info - but I can't find any reasonable sources of information for the format or how I could do this without the information embedded (although I have a feeling i could just extract and strip, it sounds redundant to me.) I'm also not sure how, using signals, I would get the backtrace, since I'm pretty sure signal handlers get a different thread. (But hell if I know. I've never actually done one.)

I saw Google Breakpad, but this is an awful solution. I checked everything out from source and it seems it doesn't really work on Windows without hacking around, and definitely not with MinGW. It might be useful for reference, but i don't think it is actually helpful in my case. Too many dependencies, not enough docs, no MinGW support... not worth it.

Any advice? I'm new here, but I'm hoping unlike /g/ people here actually know their stuff. I'm primarily concerned with MinGW right now, since I bet this will be much simpler under Linux and etc.

>>30
C and Lisp coder here. I've written enough CL programs by now which have very good performance according to my requirements. They were easy to write at first, but turned out sluggish (even with SBCL's compiler(generates optimized native code and can infer types, thus minimizing the need for your own type decls)), after spending less than 30 minutes profiling and optimizing code, I've managed to improve the speed of multiple orders of magnitude. I could have improved it some 20-30% more, but the performance was already well beyond my needs and I decided that the effort needed to improve speed by 20% (a few more hours of coding) would not be worth my time (as the current performance was already well beyond my requirements and expectations). This was possible because I can generate code dynamically as I see fit and I can easily change large bodies of (EFFECTIVE) code by just minor modifications to the code belonging to the DSL which is being compiled. An interpreted C solution would have been much slower than the Lisp one, even though the C interpreter would have been faster than a Lisp interpreter (by some 2-3 times tops), the fact that I'm compiling/generating the code myself gives me much faster speed than I could have hoped to achieve by using just C (of course, I could have written a compiler in C, but such things don't come free like in Lisp, not to mention I've only spent a fraction of the time it would have taken me to write it in C, I don't have to write a parser, a compiler, the testing is very easy, debugging support is excellent and so on). Lisp can be just as good for performance critical applications if you know how to wield it properly, otherwise you might as well just use C. However, best performance is of course not achieved by the means of C or Lisp-only solutions, instead I found that a combination of Lisp, assembly and C is the best suited answer to high performance needs. Pick the right tool for the job, and get as fine-grained control over performance as you need, but you don't need fine-grained control over 80-90% of the applications most of the time. ``Good enough'' speed (let's say 2-3 times slower as if it were written in hand-optimized C) is enough for most of the code, but when you need the performance, you should feel free to go as low as you need. Don't fear generating code to achieve better performance, don't fear writing program writing programs to both reduce the among of code you need to write and improve performance.