Debugging information in Linux release builds

[simoncn]

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?

[skz]

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

[simoncn]

(24-01-2013 09:37 AM)skz Wrote:  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

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

[skz]

(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.

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.

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

[simoncn]

(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?