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: 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

Comments

@gopherbot
Copy link

commented Jul 13, 2012

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Author

commented Jul 13, 2012

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Author

commented Jul 13, 2012

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

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
[release-branch.go1] cmd/cgo: use 1 as last entry for __cgodebug_data
««« 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.
Projects
None yet
3 participants
You can’t perform that action at this time.