debug-symbols

I have a simple project I want to debug want to produce dSYM folder with debugging symbols. Running: clang++ -std=c++14 -stdlib=libc++ -g -o Lazy Lazy.cpp Creates Lazy.dSYM as I expect. However: clang++ -std=c++14 -stdlib=libc++ -g -c Lazy.cpp clang++ -stdlib=libc++ -g -o Lazy Lazy.o Does not create Lazy.dSYM (It seems that the symbols are embedded in the binary). Sadly the 2-step build is what my modified makefile does. How can I generate Lazy.dSYM from a 2-stage compile-and-link build? I don't need a dSYM directory, just debugging symbols, but would like to understand when and why it is

I'm just digging into the gcc manual and some things are still unclear to me: When specifying a std, should I always use -pedantic in conjunction? When using -g, it the standard level sufficient or should I specify level 3, i.e. -g3? Is it good practice to use -Werror to promote all warnings to errors and -pedantic-errors to promote all pedantic warnings to errors? If you are writing a library, please do make sure that a simple program like #include <yourlib.h> int main() { return 0; } compiles without any warnings whatsoever even when the compiler is running in the most pedantic mode with all

All other factors being equal (eg optimisation level), how does having debug symbols in an ELF or SO affect: Load time. Runtime memory footprint. Runtime performance? And what could be done to mitigate any negative effects? EDIT I've seen this question but I find the discussion unhelpful, as the code optimization factor has confused the issue there. Why does my code run slower with multiple threads than with a single thread when it is compiled for profiling (-pg)? The debug symbols are located in totally different sections from the code/data sections. You can check it with objdump : $ objdump

The project I'm compiling uses CMake, which loves absolute pathnames . When I compile with debugging information enabled, gcc puts those long names into .debug_str sections, which is bad for debugging. I'd like to have short relative-to-project-root pathnames there instead. Is there some option to tell gcc to strip some part of pathname before emitting debug data? Or, maybe, there is some tool that could do that on compiled binaries? I've tried using SET(CMAKE_USE_RELATIVE_PATHS ON) (which seems to be frowned upon by devs) option, but as I'm using out-of-source builds, pathnames are still not

I'm tempted to include debug information in my release builds that go out to customers. As far as I see the only down side is 25% increase in the binary file size. The advantage is that I can get an immediately usable crash dump, much easier to analyze. I'm willing to live with the 25% increase. Are there any other disadvantages I'm missing? This is a C project and all I want to do is Linked/Debugging/Generate Debug Info Michael Burr The size of the executable should increase much less than 25%. I'm actually a little surprised that it increases much at all, but some quick tests show that at

I've noticed recently that there's a few java libs (the JDK, joda time, iText) that compile without some/all of the debugging information. Either the local variable info is missing, or the both the local variable info and line numbers are missing. Is there any reason for this? I realise it makes compiled code larger but I don't believe that's a particular large consideration. Or is it just building with the default compile options? Thanks. The default compile options don't include debugging information, you must specifically tell the compiler to include it. There are several reasons why most

In a team project I'm working on, setting a breakpoint in a file (say IdeasController.cs ) will lead to erratic debugger behaviour if there's another file with the same name in the solution. I've reproduced the problem on several developers' workstations. Example I set a breakpoint in IdeasController.cs in our Web API: Another file called IdeasController.cs exists in our separate MVC 4 web project. In the screenshot below, the debugger shows the Api->IdeasController source code, but the line highlight matches the code structure of Web->IdeasController . The breakpoint is duplicated, with one