Debugging information in Linux release builds
|
23-01-2013, 10:44 PM
(This post was last modified: 23-01-2013 10:45 PM by simoncn.)
Post: #1
|
|||
|
|||
Debugging information in Linux release builds
This commit:
https://github.com/openhome/ohNet/commit...dd5e6aa76d added the -g option to Linux release builds. This produces huge binaries. Is this an oversight, or is there a reason for it? |
|||
24-01-2013, 09:37 AM
Post: #2
|
|||
|
|||
RE: Debugging information in Linux release builds
Hi Simon,
Good spotting! Yes, there's a reason ![]() The "-g" option adds debugging information to the libraries. This information is invaluable when diagnosing especially intransigent programs ![]() The binaries are larger because of this extra information, which is contained in it's own section (.debug I think). This information can be 'stripped' from any elf file (or archive) using the 'strip' command that comes with binutils. That'll have you back to the normal size in a jiffy. If you're cross-compiling, use the version of strip that lives in your cross-compiler installation (e.g. powerpc-linux-strip). We certainly want to have this information available. If it's a massive headache for you, we can consider a couple of options: (1) If you're rolling ohnet yourself, then we can add an option to exclude debugging information. This can happen quickly. (2) If you're relying on [http://www.openhome.org/releases/artifacts/] then we might consider providing additional, stripped libraries. This might happen slowly. HTH, Tim |
|||
24-01-2013, 12:43 PM
Post: #3
|
|||
|
|||
RE: Debugging information in Linux release builds
(24-01-2013 09:37 AM)skz Wrote: Hi Simon, Hi Tim, Thanks for the quick reply. This information would not normally be useful for my usage of ohNet, but there are some situations where it does help. In particular, it produces better information when using gdb to generate a full native thread dump containing ohNet backtraces. For the time being, I'll include these symbols in my distribution. It makes the distribution larger, but it shouldn't add overhead at runtime. I've also done some build experiments to confirm that I can eliminate this debug information by setting CROSS_COMPILE_CFLAGS to -g0. If I need to do this at some stage in the future, this mechanism works OK for me. I'm rolling all my own builds. Best regards, Simon |
|||
25-01-2013, 04:59 PM
Post: #4
|
|||
|
|||
RE: Debugging information in Linux release builds
(24-01-2013 12:43 PM)simoncn Wrote: This information would not normally be useful for my usage of ohNet, but there are some situations where it does help. In particular, it produces better information when using gdb to generate a full native thread dump containing ohNet backtraces. A pattern we've found useful is to distribute binaries without the debug info, but provide a mechanism for retrieving the appropriate debug info if (when) crash data needs to be processed. And yup, I'd be pretty worried is .debug info was contributing any runtime cost. i.e. the loader on your target system should pretty much ignore the .debug section. Cheers, Tim |
|||
25-01-2013, 07:13 PM
Post: #5
|
|||
|
|||
RE: Debugging information in Linux release builds
(25-01-2013 04:59 PM)skz Wrote: A pattern we've found useful is to distribute binaries without the debug info, but provide a mechanism for retrieving the appropriate debug info if (when) crash data needs to be processed. I was wondering about this. Do you use the "debug link" approach described on this page, or something else? |
|||
« Next Oldest | Next Newest »
|