[SR-11539] llvm-link: dsymutil prints warning: could not find referenced DIE

[swift-ci]

Previous ID	SR-11539
Radar	rdar://problem/55802700
Original Reporter	jholajter (JIRA User)
Type	Bug

Attachment: Download

Additional Detail from JIRA

Votes	4
Component/s
Labels	Bug
Assignee	@JDevlieghere
Priority	Medium

md5: f5a1284ed6017ecdbfbe081809c954a1

Issue Description:

When using llvm-link to link multiple bitcode files from swift source, the following warning is seen when using dsymutil:

warning: could not find referenced DIE
note: while processing /private/tmp/gulps/llvm-linked-bitcode.bc.o

This is very similar to the problem reported in https://bugs.swift.org/browse/SR-5935 which has been marked as resolved.

In the attached llvm-link-dsymutil-repro.zip, if the "17.bc" and "24.bc" are linked together using llvm-link, dsymutil outputs warnings as seen in the attached "repro-output.txt"

The "repro.sh" script can be used to reproduce the issue. However because of the limits in the attachment size, I could not include the dependent Frameworks. I can send those via another mechanism upon request. Alternatively, they can be obtained by building the open source Gulps application found at https://github.com/FancyPixel/gulps

The artifacts in the attachments were generated using Xcode 11.1 GM.

[adrian-prantl]

@swift-ci create

[adrian-prantl]

What version of llvm-link were you using?

`find` seems to indicate that this tool is not being shipped with Xcode...

[swift-ci]

Comment by Jason Holajter (JIRA)

We built the llvm-link we are using off latest in the swift-llvm repository on the swift-5.1-branch:

https://github.com/apple/swift-llvm/tree/swift-5.1-branch

[adrian-prantl]

I managed to get all the way to the linker invocation, but I don't have all the frameworks (the first on that it's complaining about is AHKActionSheet.framework). Could you please attach them too?

[swift-ci]

Comment by Jason Holajter (JIRA)

They are too large to attach to this issue. I'll e-mail you a link to where you can get them from me.

[adrian-prantl]

Passing --verbose to dsymutil:

{{
warning: could not find referenced DIE
note: while processing llvm-linked-bitcode.bc.o
note: in DIE:

0x00000c21: DW_TAG_inlined_subroutine [32]
DW_AT_abstract_origin [DW_FORM_ref4] (cu + 0x00e3 =>

{0x000000e3}

)
DW_AT_ranges [DW_FORM_sec_offset] (0x00000ed0
[0x0000000000003ea0, 0x0000000000003ea4)
[0x0000000000003eb4, 0x0000000000003ef8))
DW_AT_call_file [DW_FORM_data1] ("/tmp/gulps/Gulps/AppDelegate.swift")
DW_AT_call_line [DW_FORM_data1] (50)
}}

It's the DW_AT_abstract_origin the error is complaining about.

[adrian-prantl]

There is nothing at 0xe3:

0x000000e0: DW_TAG_structure_type
DW_AT_name ("AppDelegate")
DW_AT_linkage_name ("$s5Gulps11AppDelegateCD")
DW_AT_byte_size (0x08)
DW_AT_decl_file ("/tmp/gulps/Gulps/AppDelegate.swift")
DW_AT_decl_line (6)
DW_AT_APPLE_runtime_class (DW_LANG_Swift)

0x000000ed: DW_TAG_subprogram
DW_AT_linkage_name ("$s5Gulps11AppDelegateC6windowSo8UIWindowCSgvg")
DW_AT_name ("window.get")
DW_AT_decl_file ("/tmp/gulps/Gulps/AppDelegate.swift")
DW_AT_decl_line (7)
DW_AT_type (0x00001778 "$sSo8UIWindowCSgD")
DW_AT_APPLE_optimized (true)
DW_AT_inline (DW_INL_inlined)

[adrian-prantl]

That does look like a potential LLVM backend bug to me. Steps to reproduce:

/Volumes/Data/swift-5.1/_build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/bin/"llvm-link" "17.bc" "24.bc" "-o" "llvm-linked-bitcode.bc"
"xcrun" "clang++" "-c" "-arch" "arm64" "-mios-version-min=9.0.0" "-isysroot" "/Applications/Xcode-11.1.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk" "-fembed-bitcode" "llvm-linked-bitcode.bc" "-o" "llvm-linked-bitcode.bc.o"
dwarfdump --verify llvm-linked-bitcode.bc.o

[swift-ci]

Comment by Jason Holajter (JIRA)

Is there anything else we can do or provide to get this looked at by the appropriate LLVM backend experts?

[adrian-prantl]

The information you supplied is perfect, I just hadn't found the time to look at this yet.

[swift-ci]

Comment by Jason Holajter (JIRA)

Thank you, Adrian. Appreciate the support. I just wanted to make sure there was nothing else that we could provide from our end to help out.

[swift-ci]

Comment by Luis Gomez (JIRA)

I'm working with https://github.com/apple/llvm-project with tag swift-5.3.2 and I'm facing the same warning with dsymutil after link bitcode files with llvm-link tool. Did you find a solution?

Note: We don't support Xcode12.5 / swift 5.4 yet, so not sure if this warning is present there

Update: this also happens in Xcode12.5 / swift 5.4

[JDevlieghere]

I've attached a reduced bitcode file that exhibits the issue:

Verifying /tmp/linked.out: file format Mach-O arm64
Verifying .debug_abbrev...
Verifying .debug_info Unit Header Chain...
Verifying .debug_info references...
error: invalid DIE reference 0x0000004e. Offset is in between DIEs:

0x0000007a: DW_TAG_inlined_subroutine
DW_AT_abstract_origin (0x0000004e)
DW_AT_low_pc (0x000000000000001c)
DW_AT_high_pc (0x000000000000003c)
DW_AT_call_file ("/tmp/gulps/Gulps/AppDelegate.swift")
DW_AT_call_line (56)
DW_AT_call_column (0x0f)

Verifying .debug_types Unit Header Chain...
Verifying .apple_names...
Verifying .apple_types...
Verifying .apple_namespaces...
Verifying .apple_objc...
Errors detected.

[swift-ci]

Comment by Luis Gomez (JIRA)

I attached 'llvm-link-bug.zip', which contains bc files created with swift 5.4, and a 'runnme.sh' script to reproduce the error.

[swift-ci]

Comment by Luis Gomez (JIRA)

As an update, for our particular use case we were able to solve it by disabling "Generate Debug Symbols" in Xcode. This removes "-g" flag when compiling.
Later in our pipeline, we are using the llc . I guess that one is generating the debug info from the linked bitcode file, because we were able to generate the DSYMs without errors.

Probably this don't solve this bug, because llc is not taking into account in the original issue with llvm-link, but it could help anyone else using llvm-link + llc

[keith]

I would expect removing the `-g` flag to affect the quality of the info in the dsym you produce though. When you `dwarfdump` the valid dsym do you have full debug info fidelity? Same question but if you use it to symbolicate crash reports?