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/cgo: [1][2][3][0]byte doesn't work on OS X Lion #8611

Closed
rsc opened this issue Aug 28, 2014 · 4 comments

Comments

@rsc
Copy link
Contributor

commented Aug 28, 2014

CL 127980043 introduced a test that fails on OS X Lion.
I replied to the code review with details.
We need to clean this up or else disable the test on Lion.
@mdempsky

This comment has been minimized.

Copy link
Member

commented Aug 28, 2014

Comment 1:

Looking at that _cgo_.o file with llvm-dwarfdump-3.5, it looks like this field:
        char y[3][0][1][2];
is generating this DW_TAG_array_type entry:
0x00000193:   DW_TAG_array_type [4] *
                DW_AT_sibling [DW_FORM_ref4]    (cu + 0x01b5 => {0x000001b5})
                DW_AT_type [DW_FORM_ref4]       (cu + 0x00c0 => {0x000000c0})
0x0000019c:     DW_TAG_subrange_type [5]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x008b => {0x0000008b})
                  DW_AT_upper_bound [DW_FORM_data1]     (0x02)
0x000001a2:     DW_TAG_subrange_type [5]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x008b => {0x0000008b})
                  DW_AT_upper_bound [DW_FORM_data1]     (0x00)
0x000001a8:     DW_TAG_subrange_type [5]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x008b => {0x0000008b})
                  DW_AT_upper_bound [DW_FORM_data1]     (0x00)
0x000001ae:     DW_TAG_subrange_type [5]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x008b => {0x0000008b})
                  DW_AT_upper_bound [DW_FORM_data1]     (0x01)
Whereas GCC 4.8.2 and Clang 3.5 generate this:
0x000000aa:   DW_TAG_array_type [4] *
                DW_AT_type [DW_FORM_ref4]       (cu + 0x0082 => {0x00000082})
                DW_AT_sibling [DW_FORM_ref4]    (cu + 0x00cb => {0x000000cb})
0x000000b3:     DW_TAG_subrange_type [5]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x007b => {0x0000007b})
                  DW_AT_upper_bound [DW_FORM_data1]     (0x02)
0x000000b9:     DW_TAG_subrange_type [6]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x007b => {0x0000007b})
0x000000be:     DW_TAG_subrange_type [5]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x007b => {0x0000007b})
                  DW_AT_upper_bound [DW_FORM_data1]     (0x00)
0x000000c4:     DW_TAG_subrange_type [5]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x007b => {0x0000007b})
                  DW_AT_upper_bound [DW_FORM_data1]     (0x01)
I.e., for the [0] sized entry, they omit the DW_AT_upper_bound entry.
Looking quickly through LLVM commit history, it seems like this commit on Dec 2012 was
probably when they fixed this behavior:
http://llvm.org/viewvc/llvm-project?view=revision&revision=169312
It looks like Clang 3.3 was the first release to include that fix.  So presumably this
test will be broken on any version of OS X that uses an older (i.e., buggy) version of
Clang, such as Lion.
@mdempsky

This comment has been minimized.

Copy link
Member

commented Aug 29, 2014

Comment 2:

I don't think there's anything we can do to truly solve this problem when the compiler
generates bad DWARF type information.  E.g., from the Clang 3.0 _cgo_.o, we can't
distinguish whether the field should have type "[3][0][1][2]C.char" or
"[3][1][0][2]C.char".  Arguably either would be better than "[0][1][1][2]C.char", but I
don't think it makes sense to further complicate debug/dwarf if we can't guarantee a
correct answer.
I suspect the best solution unfortunately is to simply disable
misc/cgo/test/issue8428.go on older OS X with buggy versions of Clang.  According to
http://stackoverflow.com/questions/8674546/how-to-update-llvm-clang-on-mac-osx, that
seems to be OS X Lion (Clang 3.0) and OS X Mountain Lion (Clang 3.2).
Is it possible to use +build rules to skip particular versions of a platform?  Or should
I just skip all of darwin for issue8428.go?
@gopherbot

This comment has been minimized.

Copy link

commented Aug 29, 2014

Comment 3:

CL https://golang.org/cl/135990043 mentions this issue.
@rsc

This comment has been minimized.

Copy link
Contributor Author

commented Aug 29, 2014

Comment 4:

This issue was closed by revision f2e7fa9.

Status changed to Fixed.

@rsc rsc added fixed labels Aug 29, 2014

@rsc rsc added this to the Go1.4 milestone Apr 14, 2015

@rsc rsc removed the release-go1.4 label Apr 14, 2015

@golang golang locked and limited conversation to collaborators Jun 25, 2016

wheatman added a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
misc/cgo/test: disable issue 8428 regress test on darwin
Clang 3.2 and older (as shipped with OS X Mountain Lion and older)
outputs ambiguous DWARF debug info that makes it impossible for us to
reconstruct accurate type information as required for this test.

Fixes golang#8611.

LGTM=rsc
R=r, rsc, minux
CC=golang-codereviews
https://golang.org/cl/135990043
wheatman added a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
misc/cgo/test: disable issue 8428 regress test on darwin
Clang 3.2 and older (as shipped with OS X Mountain Lion and older)
outputs ambiguous DWARF debug info that makes it impossible for us to
reconstruct accurate type information as required for this test.

Fixes golang#8611.

LGTM=rsc
R=r, rsc, minux
CC=golang-codereviews
https://golang.org/cl/135990043

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
3 participants
You can’t perform that action at this time.