This is an archive of the discontinued LLVM Phabricator instance.

Make the debug info in some tests more realistic
ClosedPublic

Authored by espindola on Mar 21 2018, 4:12 PM.

Details

Summary

Currently lld just parser the .debug_line section assuming that there is only one compile unit. That assumption is false (PR36793).

I have patch that changes lld to iterate over the compile units and parse the portions of the .debug_line they point to (which fixes PR36793).

A problem is that we will then need a compiler unit pointing to .debug_line for lld to see it.

This patch updates existing tests to add a minimal compile unit so that they still work with PR36793 fixed.

Diff Detail

Event Timeline

espindola created this revision.Mar 21 2018, 4:12 PM
probinson accepted this revision.Mar 21 2018, 4:36 PM
probinson added a subscriber: probinson.

LLD looks at .debug_line just to get improved diagnostics, yes? In which case the minimal .debug_info sections LGTM.

This revision is now accepted and ready to land.Mar 21 2018, 4:36 PM
grimar accepted this revision.Mar 22 2018, 1:13 AM

This LGTM. I always wondered if we do really need to support the case when there is
no .debug_info section and how much this is real.

This LGTM. I always wondered if we do really need to support the case when there is
no .debug_info section and how much this is real.

Well, technically you could have a .o file that has had all debug info except .debug_line stripped from it. This is a minimalist use-case that still supports source-location based breakpoints, and identifying functions according to their ELF symbols. It differs from a line-tables-only scenario because the latter still has a minimal .debug_info section to provide information about inlined functions.

I don't know whether it's common to strip the .o files before linking, or more common to strip the final executables after linking.

This LGTM. I always wondered if we do really need to support the case when there is
no .debug_info section and how much this is real.

Well, technically you could have a .o file that has had all debug info except .debug_line stripped from it. This is a minimalist use-case that still supports source-location based breakpoints, and identifying functions according to their ELF symbols. It differs from a line-tables-only scenario because the latter still has a minimal .debug_info section to provide information about inlined functions.

I don't know whether it's common to strip the .o files before linking, or more common to strip the final executables after linking.

For what it is worth, ld.bfd doesn't print source names in these testcases without this patch, so it is probably common to have at least a minimal .debug_info.