Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
swift-ci opened this issue Sep 27, 2019 · 16 comments · Fixed by #67077
Closed

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

swift-ci opened this issue Sep 27, 2019 · 16 comments · Fixed by #67077
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@swift-ci
Copy link
Collaborator

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
Copy link
Member

@swift-ci create

@adrian-prantl
Copy link
Member

What version of llvm-link were you using?

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

@swift-ci
Copy link
Collaborator Author

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
Copy link
Member

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
Copy link
Collaborator Author

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Collaborator Author

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
Copy link
Member

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

@swift-ci
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Member

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

swift-ci commented Aug 9, 2021

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
Copy link
Collaborator

keith commented Oct 14, 2021

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants