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

cmd/link: bad debug_frame section on macOS with buildmode=pie [Debugging] #25841

aarzilli opened this issue Jun 12, 2018 · 8 comments

cmd/link: bad debug_frame section on macOS with buildmode=pie [Debugging] #25841

aarzilli opened this issue Jun 12, 2018 · 8 comments


Copy link

@aarzilli aarzilli commented Jun 12, 2018

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.10 darwin/amd64

(also reproduces with go1.11 built from tip)

What operating system and processor architecture are you using (go env)?

GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/rm/ywx69srx1kq_dtjz2ynznn000000gp/T/go-build680864595=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Build any program with go build -gcflags='-N -l' -buildmode pie

What did you expect to see?

debug_info has an entry for main.main that looks like this

 <1><40cda>: Abbrev Number: 2 (DW_TAG_subprogram)
    <40cdb>   DW_AT_name        : (indirect string, offset: 0x29120): main.main
    <40cdf>   DW_AT_low_pc      : 0x100090530
    <40ce7>   DW_AT_high_pc     : 0x100090636
    <40cef>   DW_AT_frame_base  : 1 byte block: 9c      (DW_OP_call_frame_cfa)
    <40cf1>   DW_AT_decl_file   : 0x1
    <40cf5>   DW_AT_external    : 1

but nothing in debug_frame covers anywhere close to the range 0x100090530...0x100090636, for example the first FDE is:

00000014 000000000000002c 00000000 FDE cie=00000000 pc=0000000000002600..0000000000002737
  DW_CFA_def_cfa_offset_sf: 8
  DW_CFA_advance_loc: 23 to 0000000000002617
  DW_CFA_def_cfa_offset_sf: 48
  DW_CFA_advance_loc1: 92 to 0000000000002673
  DW_CFA_def_cfa_offset_sf: 8
  DW_CFA_advance_loc: 1 to 0000000000002674
  DW_CFA_def_cfa_offset_sf: 48
  DW_CFA_advance_loc1: 124 to 00000000000026f0
  DW_CFA_def_cfa_offset_sf: 8
  DW_CFA_advance_loc: 1 to 00000000000026f1
  DW_CFA_def_cfa_offset_sf: 48
  DW_CFA_advance_loc: 60 to 000000000000272d
  DW_CFA_def_cfa_offset_sf: 8
  DW_CFA_advance_loc: 9 to 0000000000002736

It seems to me that this is wrong but I could be missing something.

@aarzilli aarzilli changed the title cmd/link: bad debug_frame section on macOS with buildmode=pie cmd/link: bad debug_frame section on macOS with buildmode=pie [Debugging] Jun 12, 2018
Copy link

@bcmills bcmills commented Jun 12, 2018

@bcmills bcmills added this to the Go1.12 milestone Jun 12, 2018
@heschik heschik added the Debugging label Jun 12, 2018
Copy link

@heschik heschik commented Jun 12, 2018

dsymutil, I'm pretty sure, surprising nobody.

main.main DIE in go.o, before external linker/dsymutil:

0x00075e8a:     TAG_subprogram [2] *
                 AT_name( "main.main" )
                 AT_low_pc( 0x000000000008f410 )
                 AT_high_pc( 0x000000000008f7f0 )
                 AT_frame_base( call-frame-cfa )
                 AT_decl_file( "/Users/heschi/go/src/hello.go" )
                 AT_external( 0x01 )

and the FDE:

0x00013b3c: FDE
        length: 0x0000002c
   CIE_pointer: 0x00000000
    start_addr: 0x000000000008f410 main.main
    range_size: 0x00000000000003e0 (end_addr = 0x000000000008f7f0)

It looks to me like dysmutil just doesn't adjust the addresses in .debug_frame, but I haven't looked at the code to figure out why.

Copy link

@heschik heschik commented Jun 13, 2018

Is this important? I can step through dsymutil and try to figure out what the problem is but this feels like something we'd have to get fixed upstream.

Copy link
Contributor Author

@aarzilli aarzilli commented Jun 14, 2018

Is this important?


Copy link

@erikdw erikdw commented Dec 30, 2019

@heschik : it seems like this issue is preventing debugging of go plugins on Mac OS X. My project is using go plugins and most of our engineers have Macs, so it's inconvenient to not be able to debug the code.

As I have summarized in a comment in the related delve issue (go-delve/delve#1628), @aarzilli has stated that this particular issue is also a blocker for delve supporting go plugins on Mac. I know very little about how delve, DWARF, etc. work, so I'm not sure if this is the only issue still blocking that from working. However, based on @aarzilli 's statements, I would say the earlier claim that this issue is unimportant is no longer true.

Copy link

@heschik heschik commented Dec 30, 2019

@jeremyfaller I think you would be first stop for this stuff now? Especially if you have a Mac handy -- I let mine rot.

Copy link

@jeremyfaller jeremyfaller commented Jan 2, 2020

I'll take a look in the next couple of days. Whatever happens though, this won't make 1.14, so don't expect a mainline fix for quite some time. :)

@jeremyfaller jeremyfaller self-assigned this Jan 2, 2020
Copy link

@jeremyfaller jeremyfaller commented Feb 7, 2020

Apologies, for the latency. I finally got a chance to take a look at this. As @heschik suspected, it's dsymutil. [un]Surprisingly, dsymutil can't even verify its own output while generating the debug information.

I've filed a bug with apple (7568255), and will follow up here with any responses.

I have little experience debugging dsymutil myself, but I know a few people internally (@google) with some experience. I'll reach out to them next week, and see if they have any insights as well. I'll update this bug as we hear from Apple, or I gain insight from the local knowledgable people.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.