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

Jump to bottom

cmd/cgo: enum constants with value of 0 are garbled if they are the only ones used #3821

Closed
gopherbot opened this issue Jul 13, 2012 · 6 comments
Closed

cmd/cgo: enum constants with value of 0 are garbled if they are the only ones used #3821

gopherbot opened this issue Jul 13, 2012 · 6 comments
Labels
FrozenDueToAge

Comments

@gopherbot
Copy link

by mpvanlohuizen:

cmd/cgo: Consider the code below.  It will print 72057628379708111 instead of the
expected 0.  Uncomment the last line and everything works as expected.
I observed the bug only with enum values of 0.  As soon as another constant with a
non-zero value out of the same enum is used, all is good. Using multiple constants with
a value of 0 of the same enum does not fix the problem.  In this case, different values
may be printed in each case.

package main
/*
enum Const { ZERO, ONE, };
*/
import "C"
import "fmt"

func main() {
    fmt.Println(int64(C.ZERO))
    // fmt.Println(int64(C.ONE))
}

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Mac OS X Lion 10.7.4

Which version are you using?  (run 'go version')
go version weekly.2012-03-27 +2874979af37a

Please provide any additional information below.
@alberts
Copy link
Contributor

alberts commented Jul 13, 2012

Comment 1:

Seems to work fine on windows/386 with go1.0.1 and GCC 4.6.2. 
maybe try go run -work whatever.go and take a look at the generated _cgo_gotypes.go.
What do you see there?

@gopherbot
Copy link
Author

Comment 2 by mpvanlohuizen:

Indeed, the error is in the generated file as well.  The value may change per run btw. 
If I uncomment the last line, both the constant ZERO and ONE are correctly defined.
_cgo_gotypes.go:
// Created by cgo - DO NOT EDIT
package main
import "unsafe"
import "syscall"
import _ "runtime/cgo"
type _ unsafe.Pointer
func _Cerrno(dst *error, x int) { *dst = syscall.Errno(x) }
type _Ctype_int int32
type _Ctype_void [0]byte
const _Cconst_ZERO = 0x1000007feedfacf

@minux
Copy link
Member

minux commented Jul 13, 2012

Comment 3:

Could you please attach to this issue a zip of all the immediate files?
I think it is related to the dwarf generated by the llvm backend.

@gopherbot
Copy link
Author

Comment 4 by mpvanlohuizen:

Attached the generated files, as well as the source file for reference.

Attachments:

  1. cgobug.go (164 bytes)
  2. go-build124958246.zip (382264 bytes)

@minux
Copy link
Member

minux commented Jul 15, 2012

Comment 5:

This is because llvm based gcc places the all zero __cgodebug_data array
in a zero filled section (common data section), but our debug/macho pkg
doesn't support that.
On Friday, July 13, 2012, wrote:

@minux
Copy link
Member

minux commented Jul 30, 2012

Comment 6:

This issue was closed by revision dd62bb4.

Status changed to Fixed.

minux added a commit that referenced this issue May 11, 2015
@minux
[release-branch.go1] cmd/cgo: use 1 as last entry for __cgodebug_data
82de010 
««« backport aeaab9df5600
cmd/cgo: use 1 as last entry for __cgodebug_data
        LLVM-based gcc will place all-zero data in a zero-filled
        section, but our debug/macho can't handle that.
        Fixes #3821.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6444049

»»»
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@minux @alberts @gopherbot