On Sun, Jun 01, 2014 at 01:33:04AM +0100, Michael Tautschnig wrote:
> Now I must admit that I'm pretty much at loss with the build system here -
> most
> likely this is an upstream issue, but I'm not sure whether the build scripts
> (with their bold warning) have any influence here.
For how we use them, the build scripts are essentially just a wrapper
around "go build", especially to ensure that the "dockerinit" binary is
compiled statically. Are you doing anything like forcing gccgo or
something like that to perform this analysis?
> So I did add a -x -work to "go build" in hack/make/binary to gain some more
> insight. I could then take a look at the generated _cgo_main.c, which has this
> contents:
>
> $ cat
> /tmp/go-build034909373/github.com/dotcloud/docker/daemon/graphdriver/devmapper/_obj/_cgo_main.c
> int main() { return 0; }
> void crosscall2(void(*fn)(void*, int), void *a, int c) { }
> void _cgo_allocate(void *a, int c) { }
> void _cgo_panic(void *a, int c) { }
> int _cgoexp_5107ef893e0c_DevmapperLogCallback;
>
> So clearly this is not just an entirely dumb list of symbol names, but really
> seems to be of some use. Yet if the linker gets to see the above file as well
> as
>
> $ cat
> /tmp/go-build034909373/github.com/dotcloud/docker/daemon/graphdriver/devmapper/_obj/_cgo_export.c
> /* Created by cgo - DO NOT EDIT. */
> #include "_cgo_export.h"
>
> extern void crosscall2(void (*fn)(void *, int), void *, int);
>
> extern void _cgoexp_5107ef893e0c_DevmapperLogCallback(void *, int);
>
> void DevmapperLogCallback(int p0, char* p1, int p2, int p3, char* p4)
> {
> struct {
> int p0;
> char __pad0[4];
> char* p1;
> int p2;
> int p3;
> char* p4;
> } __attribute__((packed)) a;
> a.p0 = p0;
> a.p1 = p1;
> a.p2 = p2;
> a.p3 = p3;
> a.p4 = p4;
> crosscall2(_cgoexp_5107ef893e0c_DevmapperLogCallback, &a, 32);
> }
>
> then it will have to make a decision on which section to put that symbol into
> -
> is it data or code? If the declaration from _cgo_main.c happens to be ignored,
> you're lucky - else things will crash badly at runtime.
>
> Unfortunately I'm clueless on how either of the two files were generated -
> even
> go build -x -work did not seem to print a command that (in some obvious way)
> generated the _cgo_main.c file. (I'm happy to perform further investigations
> if
> any guidance could be provided.)
I've got to admit that I myself am also at a loss here. This looks
pretty hairy, but we (upstream or downstream in Debian) haven't seen any
reports of any kind of crashes related to this, so either we're
extremely lucky, or Go's compiler is doing other magic behind the scenes
that it's not sharing when you ask it to dump things (which, from the
disdain the upstream Go developers have for "C problems", doesn't seem
at all unlikely).
TL;DR, I'm as much at a loss as you are and would love further guidance
on how to proceed with this (or whether to do anything concrete as a
result of it).
>
> Best,
> Michael
>
♥,
- Tianon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
