These errors are expected. Cgo programs are linked using external linker on AIX, and objdump doesn't seem to work with ppc64 and external linker (cf TestDisasmExtld)

I've checked quickly, but it doesn't seem to have anywhere else in the compiler that need to call runtime.eqtype.

However, reflect and internal/reflectlite also have the same problem. In implements, the methods' type are checked (https://github.com/golang/gofrontend/blob/master/libgo/go/internal/reflectlite/type.go#L542 and https://github.com/golang/gofrontend/blob/master/libgo/go/internal/reflectlite/type.go#L559) and the last assertion toType(vm.mtyp).common() == toType(tm.typ).common() will also fail depending on where the type pointers are taken from.

As a workaround, I've changed this assertion to use the hash parameter toType(vm.mtyp).common().hash == toType(tm.typ).common().hash, it's not 100% accurate but I guess it works in almost all cases. Still, that's a workaround any idea if it could be fixed easily ?

I've discovered that there is another place where runtime.eqtype needs to be called. This happens when a type switch is checking for a "basic" types like string or int. Once again, for AIX even for "basic" types the type pointer is different. The statement to change is at https://github.com/golang/gofrontend/blob/master/go/statements.cc#L4669. But as there is no Gogo, I don't know how to check for Gogo->need_eqtype()

It can be reproduced with

package main

func do(i interface{}) bool {
	switch i.(type) {
	case string:
		return true
	case int:
		return true
	}
	return false
}

func main() {
	src := []byte("ab")
	do(src)

}

The current gimple representation for case string: is

        GOTMP.0 = i;
        GOTMP.1 = GOTMP.0.__type_descriptor;
        if (GOTMP.1 != &string..d) goto <D.1902>; else goto <D.1903>;
        <D.1902>:
        {
          goto <D.1619>;
        }
        <D.1903>:
        {
          {
            $ret0 = 1;
            D.1904 = $ret0;
            return D.1904;
          }
        }
        goto <D.1620>;
        <D.1619>:

It should be something like

        GOTMP.0 = i;
        GOTMP.1 = runtime.eqtype (&string..d, GOTMP.0.__type_descriptor);
        if (GOTMP.1 != &string..d) goto <D.1902>; else goto <D.1903>;
        <D.1902>:
        {
          goto <D.1619>;
        }
        <D.1903>:
        {
          {
            $ret0 = 1;
            D.1904 = $ret0;
            return D.1904;
          }
        }
        goto <D.1620>;
        <D.1619>:

Ps: The issue is already closed but that the exact same bug, thus I comment there. Tell me if I need to open another issue.

As I said in IBM forum, using fsync_range instead of fsync should work. I'm trying the patch right now and will submit it after that.

I wasn't aware you can pass compiler options directly to go tool cgo. Maybe, it should be said in cgo doc, at least that #cgo directives don't work with it.

Anyway, it's up to you, adding #cgo CFLAGS support can be useful in some cases. As you can record which flags to add, it would help if you want to have the same godefs file for different OS without wondering each time which flags are needed. But as there is a way to achieve the same behavior already it's not mandatory, I guess.

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

Master, 1.15, 1.14.7 and 1.13.13

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

Found on aix/ppc64, but same on linux/amd64

What did you do?

The #cgo CFLAGS directive is ignored when using -godefs mode. The following example shows it with a define. Of course, #cgo CFLAGS: -D_D1 can be replaced by #define _D1 and it will work. But that's not possible, AFAIK, for gcc flags like "-fms-extensions" which I need to pass for another code.

package p

/*
#cgo CFLAGS: -D_D1

#ifdef _D1
typedef struct S1 {
        int a;
} S1_t;
#endif
*/
import "C"

type S1 C.struct_S1

What did you expect to see?

$ go tool cgo -godefs  godefs.go 
// Code generated by cmd/cgo -godefs; DO NOT EDIT.
// cgo -godefs godefs.go

package p

type S1 struct {
	A int32
}

What did you see instead?

$ go tool cgo -godefs  godefs.go 
// Code generated by cmd/cgo -godefs; DO NOT EDIT.
// cgo -godefs godefs.go

package p

type S1 struct{}

@Helflym @fearful-symmetry @bcmills apologies, my hesitation has been that there are zero AIX build resources available for the community and it looked prohibitively expensive to try and learn AIX / gain access to one.

Yeah, it's not really possible. IBM doesn't provide free AIX VM for OpenSource developers... As I said for other Go packages, the AIX community should report if anything go wrong and should be able to fix it. Anyway, you can tag me if you want some tests on AIX.

At this point I'm okay ignoring that discomfort and merging this in for the benefit of the community, but there is a blocker in getting this merged. There were some changes released in v0.7.2 (#43) that need to be included here and tested on an AIX system.

Is there someone with access to AIX hardware that can develop / test that change?

I've made the change it and the tests are all OK.

While trying to compile metricbeat (with go1.15rc1 and 1.14.6), we discovered that a relocation overflow might occur when a CGO generated file tries to call crosscall2.

ld: 0711-780 SEVERE ERROR: Symbol .CallbackSubscr (entry 49130) in object /tmp/golang/000019.o:
       Relocation overflow in reference to: .crosscall2 (entry 6)
       Address: 0x0000004c;    RLD type: R_RBR;   RLD length: 26

I don't really know why ld isn't able to generate a trampoline but we don't want one anyway as it might end up being added inside Golang generated .text section, changing the offset, alignement, etc. The problem already happened with kubernetes where we decided to add __attribute__((longcall)) for a few runtime/cgo functions (cf gcc_aix_ppc64.c).

It's possible to do the same thing in generated CGO code (here), but I don't know if it's possible to add it only for AIX ? Moreover, could it be merged for 1.15 (and maybe backported to 1.14) ? This error is not a new one, thus I don't remember if it's possible to merge it this late in the cycle.

@fearful-symmetry

@fearful-symmetry I've checked the patches I've done when starting the port earlier this year. Most of them we'll be useless for you (the one dealing with either dependencies or magefiles) but I guess a few are still worth it. I'm giving them as is. I mean to say that they are 6 months old so they might not be accurate anymore. Sadly I don't have time to update them right now...

0001-auditbeat-module-file_integrity-port-for-AIX.txt 0001-libbeat-processors-add_host_metadata-add-AIX.txt 0001-libbeat-processors-add_process_metadata-fix-TestBadP.txt 0001-metricbeat-add-system-metric-support-for-AIX.txt

Sorry to change my mind, would it be possible to get these tests after all?

The two other unit tests which can be made are (*process) User() and (*process) CPUTime() as they are the only ones dealing with /proc files.

Actually, it's a bit more complicated than I thought. I either need to change the way I'm retrieving "/proc" information or I need to check the test process but it seems to unstable for me. Do you really wish these tests or can they be added to a TODO ? I'm a bit overwhelmed by other stuff right now, so I would be glad if I can add them later.

@Helflym It looks like swap stats require root:

    TestConcreteGetSwap: concrete_sigar_test.go:58:
                Error Trace:    concrete_sigar_test.go:58
                Error:          Received unexpected error:
                                perfstat_memory_total: permission denied
                Test:           TestConcreteGetSwap
--- FAIL: TestConcreteGetSwap (0.01s)

No, perfstat API is working without root permissions. The problem is related to how CGO handles errno and perfstat_pagingspace results. I guess errno is being set somewhere during perfstat_pagingspace's call even if it finally succeeds. Adding a check on perfstat_pagingspace results should be enough.

Yeah don't worry. I was warned by the IBM team for that.

The tests are failing because in system_test.go you marked Environment as false, but it appears to be implemented anyways. Because it's set as True in my environment. I don't know how I missed that one...