[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #19 from Stephen Kim  ---
Thank you for all of your comments! I have talked with our team members again. 

It seems that there has been miscommunication. They seemed to have intended
that Go tools should give Scrt1.o. However, as Go tools is just an ordinary
client of gcc (and clang or whatsoever), I believed that Go tools is not
supposed to know about Scrt1.o or crt1.o. They are internals. That made me
think that the gcc driver must be the culprit. 

However, it seems that the gcc driver is supposed to give crt1.o, and I could
now convince myself. 

If that's the case, this issue should be resolved either in glibc or gold.
Thanks again!

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #16 from Stephen Kim  ---


(In reply to Andrew Pinski from comment #15)
> Let's start over.  crt1.o in glibc should support calling main that is
> located in the shared library.
> If it does not then there is a bug there.
> 
Sorry. I got notice this comment a bit late. 

Firstly, the glibc commit I posted was not correct. It seems like this commit:
 6cd380dd366d728da9f579eeb9f7f4c47f48e474

It does not. Nonetheless, a glibc maintainer, Siddhesh Poyarekar, told me that
it is NOT a glibc bug. I am not a glibc expert, so I did not find a reason that
I should not believe Siddhesh regarding glibc. 

> Can you explain why you think crt1.o is broken that it can't be used for
> that purpose?
> 
If I manually link with Scrt1.0, it works. I firstly used -Wl,-v option to see
what options are passed to Gold. Then, I just change crt1.o with Scrt1.o, which
works. Running the generate executable does not cause a segmentation fault as
the address of main is correctly found in the _start function. However, I am
not sure whether we could call it "broken crt1.o." The glibc maintainer and
also Ian Lance Taylor--the Gold developer--believed that Scrt1.o should be
given.

> Also you pointed to a commit which you said changed the behavior in glibc
> but the commit you pointed to only changes dates and nothing more.  Can you
> point to the commit which changed the behavior in glibc which caused this
> not to work any more?  
> 

I am not a glibc expert, so I am not sure about the details. I found three
commits that updated start.S probably with regard to my issue.

Here is the commit message:

AArch64: use movz/movk instead of literal pools in start.S

eXecute-Only Memory (XOM) is a protection mechanism against some ROP
attacks. XOM sets the code as executable and unreadable, so the access
to any data, like literal pools, in the code section causes the fault
with XOM. The compiler can disable literal pools for C source files,
but not for assembly files, so I use movz/movk instead of literal pools
in start.S for XOM.

I add MOVL macro with movz/movk instructions like movl pseudo-instruction
in armasm, and use the macro instead of literal pools.

* sysdeps/aarch64/start.S: Use MOVL instead of literal pools.
* sysdeps/aarch64/sysdep.h (MOVL): Add MOVL macro.


Since then, there have been multiple commits that change start.S regarding the
problem:


commit 3d1d79283e6de4f7c434cb67fb53a4fd28359669
Author: Szabolcs Nagy 
Date:   Tue Dec 19 18:43:04 2017 +

aarch64: fix static pie enabled libc when main is in a shared library

In the static pie enabled libc, crt1.o uses the same position independent
code as rcrt1.o and crt1.o is used instead of Scrt1.o when -no-pie
executables are linked.  When main is not defined in the executable, but
in a shared library crt1.o is currently broken, it assumes main is local.
(glibc has a test for this but i missed it in my previous testing.)

To make both rcrt1.o and crt1.o happy with the same code, a wrapper is
introduced around main: with this crt1.o works with extern main symbol
while rcrt1.o does not depend on GOT relocations. (The change only
affects static pie enabled libc. Further simplification of start.S is
possible in the future by using the same approach for Scrt1.o too.)

* aarch64/start.S (_start): Use __wrap_main.
(__wrap_main): New local symbol.


commit 14d886edbd3d80b771e1c42fbd9217f9074de9c6
Author: Szabolcs Nagy 
Date:   Fri Nov 17 10:45:32 2017 +

aarch64: fix start code for static pie

There are three flavors of the crt startup code:

1) crt1.o used for non-pie,
2) Scrt1.o used for dynamic linked pie (dynamic linker relocates),
3) rcrt1.o used for static linked pie (self relocation is needed)

In the --enable-static-pie case crt1.o is built with -DPIC and in case
of static linking it interposes _dl_relocate_static_pie in libc to
avoid self relocation.

Scrt1.o is built with -DPIC -DSHARED and it relies on GOT entries that
the static linker cannot relax and thus need relocation before the
start code is executed, so rcrt1.o needs separate implementation.

This implementation does not work for .text > 4G position independent
executables, which is fine since the toolchain does not support
-mcmodel=large with -fPIE.

Tests pass with ld/22269 and ld/22263 binutils bugs fixed.

* sysdeps/aarch64/start.S (_start): Handle PIC && !SHARED case.

commit 6cd380dd366d728da9f579eeb9f7f4c47f48e474 (thecommit2)
Author: Wang Boshi 
Date:   Fri Sep 15 17:53:23 2017 +0100

AArch64: use movz/movk instead of literal pools in start.S

eXecute-Only Memory (XOM) is a protection mechanism against some ROP
attacks. XOM sets the code as executable and unreadable, so the access
to any data, like literal pools, in the code 

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #14 from Stephen Kim  ---
(In reply to Andreas Schwab from comment #7)
> If you think you have found a bug in glibc, then this is not the right place
> to report it.

I believe that this is NOT a glibc bug. It is TRIGGERED by a glibc patch. I
would say that the glibc patch is legitimate. Personally, I believe that this
is a compiler driver bug. That's why I am filing the bug here. Even now, I am
not convinced that this is not a gcc bug.(In reply to Andrew Pinski from
comment #10)
> This could also be a gold linker issue too.
> 
> But then again this is not the right place to report a gold or glibc issue. 
> Try https://sourceware.org/bugzilla/ instead.

Regarding Gold, I have talked with Ian Lance Taylor, who is known to be an
author of gold and who I believe is a linker expert. He does not think that
this bug is a Gold issue. According to his emails, he seems to believe that
Gold should be given Scrt1.o.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #13 from Stephen Kim  ---
(In reply to Andreas Schwab from comment #7)
> If you think you have found a bug in glibc, then this is not the right place
> to report it.

I believe that this is NOT a glibc bug. It is TRIGGERED by a glibc patch. I
would say that the glibc patch is legitimate. Personally, I believe that this
is a compiler driver bug. That's why I am filing the bug here. Even now, I am
not convinced that this is not a gcc bug.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #12 from Stephen Kim  ---
(In reply to jos...@codesourcery.com from comment #8)
> On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:
> 
> > The glibc commit that triggered this bug is:
> >  bfff8b1becd7d01c074177df7196ab327cd8c844 
> 
> That's the copyright date updates for 2017.

Thank you for the information. Anyway, the patch is still in glibc, and it is
particularly for aarch64. If the bug wasn't reproduced on a system such as
Gentoo, Debian, etc, it is due to either of the following two:
  1. gcc is configured with --enable-default-pie (e.g. Debian, Gentoo)
  2. glibc is old and the patch hasn't been backported (e.g. old Oracle Linux)

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #11 from Stephen Kim  ---
(In reply to Andrew Pinski from comment #9)
> (In reply to jos...@codesourcery.com from comment #8)
> > On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:
> > 
> > > The glibc commit that triggered this bug is:
> > >  bfff8b1becd7d01c074177df7196ab327cd8c844 
> > 
> > That's the copyright date updates for 2017.
> 
> I was going to say that too.
> Maybe:
> https://sourceware.org/git/?p=glibc.git;a=commit;
> h=14d886edbd3d80b771e1c42fbd9217f9074de9c6

It does not seem to be the fix for this one I had been reporting. (In reply to
Andrew Pinski from comment #9)
> (In reply to jos...@codesourcery.com from comment #8)
> > On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:
> > 
> > > The glibc commit that triggered this bug is:
> > >  bfff8b1becd7d01c074177df7196ab327cd8c844 
> > 
> > That's the copyright date updates for 2017.
> 
> I was going to say that too.
> Maybe:
> https://sourceware.org/git/?p=glibc.git;a=commit;
> h=14d886edbd3d80b771e1c42fbd9217f9074de9c6


Thank you for sharing the link. The bug here I am reporting is !PIC case. The
fix is for PIC && !SHARED case.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

Stephen Kim  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #6 from Stephen Kim  ---
This bug is reproducible only on arm64. Sorry for missing the info. That was my
bad. 

Besides, it is reproducible with a particular patch in glibc, which was made
this year. 

And, the reason that glibc test did not detect this issue is because Debian gcc
seems to default pie. I.e. it might be configured with --enable-default-pie.
Gentoo does the same. Thus, they are giving Scrt1.o.

As of today, the gcc I got after running Debian:latest docker container and
executing "apt-get update," shows this on "gcc -v":
 $ gcc -v  2>&1 | egrep -o "enable-default-pie"
 enable-default-pie

Oracle Linux on arm64 is the environment that meets the requirements for the
bug. It has the glibc patch, and the gcc is not configured to default PIE. 

Thus, if not being reproducible was the reason that the bug is closed, I would
say that it is reproducible. Please, use oraclelinux:latest docker container on
aarch64.

If this bug is closed because it is indeed user's fault not a compiler driver
error, please, close this bug again.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #5 from Stephen Kim  ---
(In reply to jos...@codesourcery.com from comment #3)
> As of October 2017, glibc has a testcase that having main in a shared 
> library works - that's a valid use case, which should work with crt1.o.  
> If it doesn't work for some particular architecture that would be a glibc 
> bug (or conceivably an ld bug) - but I'd also expect it to show up as a 
> failure of the glibc elf/tst-main1 test, and no such failure is listed for 
> any architecture on .

It is reproducible, currently with Oracle Linux. For example, you could do:
 docker run -it oraclelinux:7.5 /bin/bash

followed by:
  yum update -y

Then, the issue is reproducible. I think I am the one that discovered this
issue while building Go tools on aarch64.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

Stephen Kim  changed:

   What|Removed |Added

 CC||stephen.kim at oracle dot com

--- Comment #4 from Stephen Kim  ---


(In reply to jos...@codesourcery.com from comment #3)
> As of October 2017, glibc has a testcase that having main in a shared 
> library works - that's a valid use case, which should work with crt1.o.  
> If it doesn't work for some particular architecture that would be a glibc 
> bug (or conceivably an ld bug) - but I'd also expect it to show up as a 
> failure of the glibc elf/tst-main1 test, and no such failure is listed for 
> any architecture on <https://sourceware.org/glibc/wiki/Release/2.28>.

The glibc commit that triggered this bug is:
 bfff8b1becd7d01c074177df7196ab327cd8c844 

It is a patch for aarch64 only. From there, giving crt1.o rather than Scrt1.o
has become problematic. 

The patch is included in Oracle Linux while it is not in Debian. The patch was
made this year. Thus, back then 2017, I think this problem did not exist.
Unfortunately, glibc still keeps the patch. Thus, the bug might be going to be
a problem in case of other Linux distro running on arm64, I believe. Gentoo has
the same issue but it avoids by defaulting PIE: --enable-default-pie at
configure.

[Bug driver/88262] New: gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

Bug ID: 88262
   Summary: gcc uses crt1.o in place of Scrt1.o when the main
function is in a PIC shared lib
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stephen.kim at oracle dot com
  Target Milestone: ---

I am not yet certain that this is a gcc bug or user's fault. That's why I am
filing a bug here to get other engineers' thoughts.

I have a non-PIC app.o, which does not have the main function but a set of
functions, variables, etc. Besides, I have a PIC shared library, say,
libmain.so, which has the main function. 

Having a "PIE" is not mandatory, so I just linked the two like this:

 gcc -o app.x -L. -lmain -fuse-ld=gold -Wl,-rpath=$PWD app.o

Running app.x gives me a segmentation fault when the glibc is sufficiently
new--the patch that triggers this issue is created this year--and the platform
is arm64. 

The reason is when gcc invokes gold, gcc gives it crt1.o rather than Scrt1.o.
Multiple experts confirmed that Scrt1.o should be given in this case. 

I am wondering if this is a gcc bug that should be fixed in the gcc driver. Or,
would it be claimed that the users (e.g. myself) should have used "-pie" to
link them although making a PIE is not mandatory from my perspective?

Regarding severity, as a C and C++ programmer, I personally have not placed
main inside a shared library. I haven't yet faced at work any pure C/C++ code
that has the main  inside a PIC shared library. This might not be highly common
in the C and C++ worlds. 

However, Go tools always do this with a certain combination of buildmode. I
would expect this situation happens more there.

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331

--- Comment #8 from Stephen Kim  ---
After applying your patch, the issue seems to have gone away.

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331

--- Comment #4 from Stephen Kim  ---
Just in case, this system also includes Google's gc. With the gc, everything
that fails with gccgo like this seems all fine. Thus, I think this problem
might be in the top-level "go tool," which parses the command line and invokes
the sub tools.

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331

--- Comment #3 from Stephen Kim  ---
Created attachment 44327
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44327=edit
strace -f go run hello.go

strace -f go run hello.go

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331

Stephen Kim  changed:

   What|Removed |Added

 CC||stephen.kim at oracle dot com

--- Comment #2 from Stephen Kim  ---
First of all, the error occurs sometimes but not always. 

What is being called "the error" is as follows. Go run hello.go (just say
"hello!" with fmt.Println) sometimes fails to find gccgo itself. However, go
build with a cgo invokation sometimes fails to find cgo and sometimes succeed
with cgo but failed to locate gccgo. I assume that other go commands that
invoke any other subtool would have similar issues but with different error
messages. 

Here is the example of failure with go run hello.go:
[aion1223@localhost gcc_upstream]$ go run /home/aion1223/hello.go
/home/aion1223/install/bin/gccgo: waitid: no such file or directory; output:
"Using built-in specs.\nCOLLECT_GCC=/home/aion1223/install/bin/gccgo\nTarget:
aarch64-unknown-linux-gnu\nConfigured with: ../configure
--enable-languages=c,c++,go --prefix=/home/aion1223/install\nThread model:
posix\ngcc version 9.0.0 20180627 (experimental) (GCC)
\nCOLLECT_GCC_OPTIONS='-c' '-shared-libgcc' '-mlittle-endian' '-mabi=lp64'\n
/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/go1 - -quiet
-dumpbase - -mlittle-endian \"-mabi=lp64\" -auxbase -
-L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0
-L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../.. -o
/tmp/ccr66E5t.s\nCOLLECT_GCC_OPTIONS='-c' '-shared-libgcc' '-mlittle-endian'
'-mabi=lp64'\n as -EL \"-mabi=lp64\" -o -.o
/tmp/ccr66E5t.s\nCOMPILER_PATH=/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/\nLIBRARY_PATH=/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../:/lib/:/usr/lib/\nCOLLECT_GCC_OPTIONS='-c'
'-shared-libgcc' '-mlittle-endian' '-mabi=lp64'\n"

Here are examples of failure with go build that requires cgo:

$ cat ce.go
package main


import "fmt"

/*
const unsigned long long int neg = (const unsigned long long int) -1;
*/
import "C"

func main() {
 var i uint64
 i = uint64(C.neg)
 fmt.Println(i)
}

[aion1223@localhost ~]$ rm -fr ~/.cache/go-build; go build -x ~/ce.go
WORK=/tmp/go-build421481847
mkdir -p $WORK/b001/
cd $WORK
/home/aion1223/install/bin/gccgo -fsplit-stack -c -x c - || true
cd /home/aion1223
CGO_LDFLAGS='"-g" "-O2"'
./install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/cgo -objdir $WORK/b001/
-importpath command-line-arguments -gccgo -- -I $WORK/b001/ -g -O2 ./ce.go
# command-line-arguments
waitid: no such file or directory

[aion1223@localhost ~]$ rm -fr ~/.cache/go-build; go build -x ~/ce.go
WORK=/tmp/go-build170944385
go tool cgo: waitid: no such file or directory
cgo version go1.10.3 gccgo (GCC) 9.0.0 20180627 (experimental)

[aion1223@localhost ~]$ rm -fr ~/.cache/go-build; go build -x ~/ce.go
WORK=/tmp/go-build774257621
mkdir -p $WORK/b001/
cd $WORK
/home/aion1223/install/bin/gccgo -fsplit-stack -c -x c - || true
cd /home/aion1223
CGO_LDFLAGS='"-g" "-O2"'
./install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/cgo -objdir $WORK/b001/
-importpath command-line-arguments -gccgo -- -I $WORK/b001/ -g -O2 ./ce.go
cd $WORK
gcc -fno-caret-diagnostics -c -x c - || true
gcc -Qunused-arguments -c -x c - || true
gcc -fdebug-prefix-map=a=b -c -x c - || true
gcc -gno-record-gcc-switches -c -x c - || true
cd $WORK/b001
gcc -I /home/aion1223 -fPIC -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches
-funwind-tables -I ./ -g -O2 -o ./_x001.o -c _cgo_export.c
gcc -I /home/aion1223 -fPIC -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches
-funwind-tables -I ./ -g -O2 -o ./_x002.o -c ce.cgo2.c
cd $WORK
gcc -fsplit-stack -c -x c - || true
cd /home/aion1223
gcc -Wall -g -I $WORK/b001/ -I ./install/pkg/include -o $WORK/b001/_cgo_defun.o
-D GOOS_linux -D GOARCH_arm64 -fdebug-prefix-map=$WORK=/tmp/go-build
-gno-record-gcc-switches -c $WORK/b001/_cgo_defun.c
cd $WORK
/home/aion1223/install/bin/gccgo -fgo-importcfg=/dev/null -c -x c - || true
cd /home/aion1223
./install/bin/gccgo -c -g -fdebug-prefix-map=$WORK=/tmp/go-build
-gno-record-gcc-switches -fgo-rela

[Bug go/86331] New: the gccgo's "go" tool looks like failing to invoke any sub go command

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331

Bug ID: 86331
   Summary: the gccgo's "go" tool looks like failing to invoke any
sub go command
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: stephen.kim at oracle dot com
CC: cmang at google dot com
  Target Milestone: ---

It seems that putting back a new version of go to gcc8 triggers the issue I
would describe here. 

Invoking any go command randomly fails in aarch64:

[aion1223@localhost gcc_upstream]$ go run /home/aion1223/hello.go
hello!
[aion1223@localhost gcc_upstream]$ go run /home/aion1223/hello.go
hello!
[aion1223@localhost gcc_upstream]$ go run /home/aion1223/hello.go
/home/aion1223/install/bin/gccgo: waitid: no such file or directory; output:
"Using built-in specs.\nCOLLECT_GCC=/home/aion1223/install/bin/gccgo\nTarget:
aarch64-unknown-linux-gnu\nConfigured with: ../configure
--enable-languages=c,c++,go --prefix=/home/aion1223/install\nThread model:
posix\ngcc version 9.0.0 20180627 (experimental) (GCC)
\nCOLLECT_GCC_OPTIONS='-c' '-shared-libgcc' '-mlittle-endian' '-mabi=lp64'\n
/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/go1 - -quiet
-dumpbase - -mlittle-endian \"-mabi=lp64\" -auxbase -
-L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0
-L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../.. -o
/tmp/ccr66E5t.s\nCOLLECT_GCC_OPTIONS='-c' '-shared-libgcc' '-mlittle-endian'
'-mabi=lp64'\n as -EL \"-mabi=lp64\" -o -.o
/tmp/ccr66E5t.s\nCOMPILER_PATH=/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/\nLIBRARY_PATH=/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../:/lib/:/usr/lib/\nCOLLECT_GCC_OPTIONS='-c'
'-shared-libgcc' '-mlittle-endian' '-mabi=lp64'\n"

Please, note that there has been no change in the hello.go. 

Go run is not the only command to fail. 
[aion1223@localhost gcc_upstream]$ go build -x ~/ce.go
WORK=/tmp/go-build231706713
go tool cgo: waitid: no such file or directory
cgo version go1.10.3 gccgo (GCC) 9.0.0 20180627 (experimental)
[aion1223@localhost gcc_upstream]$ go build -x ~/ce.go
WORK=/tmp/go-build583342013
mkdir -p $WORK/b001/
cd $WORK
/home/aion1223/install/bin/gccgo -fsplit-stack -c -x c - || true
cd /home/aion1223
CGO_LDFLAGS='"-g" "-O2"'
./install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/cgo -objdir $WORK/b001/
-importpath command-line-arguments -gccgo -- -I $WORK/b001/ -g -O2 ./ce.go
# command-line-arguments
waitid: no such file or directory


Also, please note that the two commands issued were the same although the
output is different.

Here are some information about my system:

[aion1223@localhost gcc_upstream]$ go version
go version go1.10.3 gccgo (GCC) 9.0.0 20180627 (experimental) linux/arm64
[aion1223@localhost gcc_upstream]$ gcc --version
gcc (GCC) 9.0.0 20180627 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[aion1223@localhost gcc_upstream]$ uname -a
Linux localhost 4.13.0-1.0.5.2.el7.aarch64 #1 SMP Wed Nov 1 18:33:55 UTC 2017
aarch64 aarch64 aarch64 GNU/Linux

Basically, this is a VM running on an arm64 machine. This problem goes away if
the failed command/subtool is invoked with Google's gc's go tool with
-compiler=gccgo.

[Bug go/86289] Cgo integer constant overflow for 64 bits (unsigned) int

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86289

Stephen Kim  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |---

--- Comment #3 from Stephen Kim  ---
I thought the bug is not reproducible with latest gccgo. However, it is. 

Somehow, I have invoked gccgo with old gcc (7.3).

[Bug go/86289] Cgo integer constant overflow for 64 bits (unsigned) int

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86289

Stephen Kim  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Stephen Kim  ---
I haven't check for a couple of weeks. I think this seems to have been fixed in
the upstream

[Bug go/86289] New: Cgo integer constant overflow for 64 bits (unsigned) int

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86289

Bug ID: 86289
   Summary: Cgo integer constant overflow for 64 bits (unsigned)
int
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: stephen.kim at oracle dot com
CC: cmang at google dot com
  Target Milestone: ---

I think the bug report is not the best format for this issue but that's the
only I have. Let me start with the bug. The bug seems a regression that I have
found in building docker with gccgo for aarch64. Here is, however, the reduced
test case:

$ cat ~/ce.go
package main

import "fmt"

/*
const unsigned long long int neg = (const unsigned long long) -1;
*/
import "C"

func main() {
var i int64 
i = int64(C.neg)
fmt.Println(C.neg)  
fmt.Println(i)
}

$ go build -x ~/ce.go
(omitted some logs)
../../../ce.go:14:6: error: integer constant overflow
  i = int64(C.neg)
  ^
The problem is, cgo invokes gcc as just "gcc." Gcc 8.x started to accept the
following C code:
const unsigned long long int neg = (const unsigned long long) -1;

#line 1 "not-num-const"
void __cgo_f_1_4(void) { static const double __cgo_undefined__4 = (neg); }

The code above is generated by cgo; cgo tries to understand "neg" by generating
the code and giving it to gcc. Gcc 7.3 said "That's a compile error." while gcc
8.x and 9.0 silently accept it. 

Once the code is accepted by, say, gcc 9, cgo type-casts the value as double.
It is very clear that a 64 bit double cannot accommodate all 64 bits integer
values. -1 is one of the corner cases. 

As "neg" is "not-int-const," if gcc says it does not fall into "not-num-const,"
cgo thinks "neg" is an fconst. That is destined to be type-casted to a double:

#line 1 "cgo-generated-wrapper"
#line 1 "cgo-dwarf-inference"
__typeof__(neg) *__cgo__0;
long long __cgodebug_ints[] = {
0,
1
};
double __cgodebug_floats[] = {
neg,
1
};

Cgo generates the code above to get some debugging information gcc generated,
and use the value there to initialize C.neg in the Go code. 

I believe that is not correct. 

Firstly, this bug would be a regression as gcc 7.3 did say the following is a
compile error:
const unsigned long long int neg = (const unsigned long long) -1;

#line 1 "not-num-const"
void __cgo_f_1_4(void) { static const double __cgo_undefined__4 = (neg); }


Then, should the bug be filed against gcc? 

However, I am also wondering. Even if everything were fine, I still think that
my "neg" variable perhaps should not fall into "not-int-const." It should be
int-const. 

Personally, regarding my work with my employer, I have worked on this issue. I
would like to proceed to provide a fix for the issue if someone confirms I am
on the right track.

Thank you!