Skip to content

cmd/link: debug_line incomplete when using cgo with some versions of dsymutil [Debugging] #25451

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.

Sign up for GitHub

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

Jump to bottom
Closed
aarzilli opened this issue May 18, 2018 · 9 comments
Closed

cmd/link: debug_line incomplete when using cgo with some versions of dsymutil [Debugging] #25451

aarzilli opened this issue May 18, 2018 · 9 comments
Labels
Debugging FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Darwin release-blocker
Milestone
Go1.11

Comments

@aarzilli
Copy link
Contributor

This is a duplicate of #25392, I actually posted this on that issue yesterday but it was already closed and I think nobody saw it. I think that issue should be reopened.

It looks like some (most?) versions of dsymutil do not support (but see below) version 3 for debug_line, including the most recent version of dsymutil on 10.12.

If 10.12 is still considered supported this breaks backwards compatibility.

Now, Saying that dsymutil doesn't support v3 is incomplete, it seems that it actually does, but only if you lie to it and say it's v2. For example this is what the line table of a compilation unit produced by clang looks like in the final executable:

  Offset:                      0x2b3fc
  Length:                      154
  DWARF Version:               2
  Prologue Length:             30
  Minimum Instruction Length:  1
  Initial value of 'is_stmt':  1
  Line Base:                   -5
  Line Range:                  14
  Opcode Base:                 13

 Opcodes:
  Opcode 1 has 0 args
  Opcode 2 has 1 args
  Opcode 3 has 1 args
  Opcode 4 has 1 args
  Opcode 5 has 1 args
  Opcode 6 has 0 args
  Opcode 7 has 0 args
  Opcode 8 has 0 args
  Opcode 9 has 1 args
  Opcode 10 has 0 args
  Opcode 11 has 0 args
  Opcode 12 has 1 args

Note how it says version 2 but has more than 9 standard opcodes.

The choice is between lying, pretending 10.12 doesn't exist or reverting the prologueEnd thing.
@ianlancetaylor ianlancetaylor added OS-Darwin NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Debugging release-blocker labels May 18, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone May 18, 2018
@ianlancetaylor
Copy link
Member

CC @heschik @thanm

@ianlancetaylor
Copy link
Member

CC @dr2chase

@thanm
Copy link
Contributor

thanm commented May 18, 2018

I looked just now and clang is indeed breaking the rules when it comes to max number of opcodes for DWARF 2. I checked with clang-3.9 (which emits DWARF 2 by default) and with clang-7 / tip (which emits DWARF 4 by default, but produces a line table header with the wrong number of opcodes if you ask for DWARF 2); both have 12 opcodes.

A couple of questions:

  1. How sure are we that this specific aspect of the DWARF is what's causing problems with dsymutil (given that the behavior has apparenty been around for a while)?

  2. What does this have to do with Go? The Go portion of the line table looks fine.

@aarzilli
Copy link
Contributor Author

AFAICT the problem is not that clang is violating the rules, is that Go isn't. If you use an older version of dsymutil it will strip out the debug_line sections produced by Go now that they are using version 3.

@thanm
Copy link
Contributor

thanm commented May 18, 2018

How would I go about verifying that?

@dr2chase
Copy link
Contributor

dr2chase commented May 18, 2018 •
edited
Loading

Dsymutil in latest XCode works okay, but some not-much-earlier version does not.

Mine (which works):

dsymutil --version
Apple LLVM version 9.1.0 (clang-902.0.39.1)
  Optimized build.
  Default target: x86_64-apple-darwin17.5.0
  Host CPU: skylake

I believe LLVM/XCode 9.0.0 will fail, based on other bugs.

My understanding is that our choices are:

  • detect compilation/linking targeting Darwin and falsely claim DWARF version 2.
  • require upgrade to latest XCode.

Update to latest XCode might require update to latest OSX. I also don't know how far back the "claim version 2" trick will work (when was that first supported, how old a version of OSX does that imply?). I was going to try to download an old XCode to give it a try, but was asked for my Apple Developer ID and strongly suspect that my personal ID is not appropriate for this.

DWARF Version 3 is 12 years old, just saying....

@aarzilli
Copy link
Contributor Author

dsymutil version 9.0.0 (clang-900.0.39.2) is affected by this problem and AFAIK is the most recent version installable on macOS 10.12 (without compiling from source).

@dr2chase
Copy link
Contributor

I checked that lying works okay on 9.1.0.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/114015 mentions this issue: cmd/link: revert DWARF version to 2 for .debug_lines

@golang golang locked and limited conversation to collaborators May 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Debugging FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Darwin release-blocker
Projects
None yet
Milestone
Go1.11
Development

No branches or pull requests
5 participants
@aarzilli @dr2chase @ianlancetaylor @gopherbot @thanm