Debug information and bitcode linking patch

Hi,

The enclosed patch preserves debug information about compilation units, functions, and line number information when doing bitcode linking. I'm not easily able to try this for non-bitcode linking. Could someone familiar with debug info take a look and tell me if it appears to be benign?

The rational is that formerly the compile units and subprogram definitions were made into a single occurrence after linking, which really messed up the debug info. This patch keeps them separate, as they should be.

This is a fix for http://llvm.org/bugs/show_bug.cgi?id=4530

-Rich

Richard Pennington wrote:

Hi,

The enclosed patch preserves debug information about compilation units, functions, and line number information when doing bitcode linking. I'm not easily able to try this for non-bitcode linking. Could someone familiar with debug info take a look and tell me if it appears to be benign?

The rational is that formerly the compile units and subprogram definitions were made into a single occurrence after linking, which really messed up the debug info. This patch keeps them separate, as they should be.

This is a fix for http://llvm.org/bugs/show_bug.cgi?id=4530

-Rich

Oops. the patch.

bcdebug.patch (1.06 KB)

This is not the right approach. This patch allows optimizer to remove
debug info for functions that are still present in the module.

Plus, very soon (as soon as 2.6 release branch is created) the LLVM IR
will stop using GlobalVariables to encode debug info. Stay tuned.

Devang Patel wrote:

Richard Pennington wrote:

Hi,

The enclosed patch preserves debug information about compilation units,
functions, and line number information when doing bitcode linking. I'm not
easily able to try this for non-bitcode linking. Could someone familiar with
debug info take a look and tell me if it appears to be benign?

The rational is that formerly the compile units and subprogram definitions
were made into a single occurrence after linking, which really messed up the
debug info. This patch keeps them separate, as they should be.

Hi Devang,

Actually, it is the right approach. The optimizer won't optimize the debug info out unless the llvm.dbg.function.start instruction, or the entire function, is removed. If the llvm.dbg.function start instruction is optimized away for some reason, the subprogram data is useless.

I think this should go in to 2.06, because it fixes something that is currently broken.

I'm looking forward to the new post 2.06 implementation.

-Rich