gcc/libgo
Ian Lance Taylor 4e62f891cd runtime: expose the g variable
Currently, getg is implemented in C, which loads the thread-local
    g variable. The g variable is declared static in C.
    
    This CL exposes the g variable, so it can be accessed from the Go
    side. This allows the Go compiler to inline getg calls to direct
    access of g.
    
    Currently, the actual inlining is only implemented in the gollvm
    compiler. The g variable is thread-local and the compiler backend
    may choose to cache the TLS address in a register or on stack. If
    a thread switch happens the cache may become invalid. I don't
    know how to disable the TLS address cache in gccgo, therefore
    the inlining of getg is not implemented. In the future gccgo may
    gain this if we know how to do it safely.
    
    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/186238

From-SVN: r273499
2019-07-15 21:17:16 +00:00
..
config
go compiler: optimize 0,1,2-case select statement 2019-07-04 02:20:37 +00:00
misc/cgo
runtime runtime: expose the g variable 2019-07-15 21:17:16 +00:00
testsuite libgo/testsuite: ignore symbols with a leading dot in symtogo 2019-06-26 00:17:32 +00:00
aclocal.m4
check-packages.txt
config.h.in
configure
configure.ac
goarch.sh
godeps.sh
gotool-packages.txt
libgo-packages.txt
libgo.imp
LICENSE
Makefile.am compiler: use builtin memcmp directly 2019-06-24 16:54:22 +00:00
Makefile.in compiler: use builtin memcmp directly 2019-06-24 16:54:22 +00:00
match.sh
MERGE
merge.sh
mkrsysinfo.sh
mkruntimeinc.sh
mksigtab.sh
mksysinfo.sh
mvifdiff.sh
PATENTS
README
README.gcc
sysinfo.c
VERSION

See ../README.

This is the runtime support library for the Go programming language.
This library is intended for use with the Go frontend.

This library should not be stripped when it is installed.  Go code
relies on being able to look up file/line information, which comes
from the debugging info using the libbacktrace library.

The library has only been tested on GNU/Linux using glibc, and on
Solaris.  It should not be difficult to port to other operating
systems.

Directories:

go
  A copy of the Go library from http://golang.org/, with several
  changes for gccgo.

runtime
  Runtime functions, written in C, which are called directly by the
  compiler or by the library.

Contributing
============

To contribute patches to the files in this directory, please see
http://golang.org/doc/gccgo_contribute.html .

The master copy of these files is hosted at
http://code.google.com/p/gofrontend .  Changes to these files require
signing a Google contributor license agreement.  If you are the
copyright holder, you will need to agree to the individual contributor
license agreement at
http://code.google.com/legal/individual-cla-v1.0.html.  This agreement
can be completed online.

If your organization is the copyright holder, the organization will
need to agree to the corporate contributor license agreement at
http://code.google.com/legal/corporate-cla-v1.0.html.

If the copyright holder for your code has already completed the
agreement in connection with another Google open source project, it
does not need to be completed again.

Debugging
=========

This describes how to test libgo when built as part of gccgo.

To test a specific package, cd to the libgo build directory
(TARGET/libgo) and run `make PKG/check`.  For example, `make
bytes/check`.

To see the exact commands that it runs, including how the compiler is
invoked, run `make GOTESTFLAGS=--trace bytes/check`.  This will
display the commands if the test fails.  If the test passes, the
commands and other output will be visible in a file named
check-testlog in a subdirectory with the name of the package being
checked.  In the case of bytes/check, this will create
bytes/check-testlog.

To leave the test program behind, run `make GOTESTFLAGS=--keep
bytes/check`.  That will leave a gotestNNNN/test directory in the
libgo build directory.  In that directory you can run
`LD_LIBRARY_PATH=../../.libs ./a.out -test.short` to run the tests.
You can run specific failing tests using a -test.run option.  You can
see the tests being run with the -test.v option.  You can run the
program under a debugger such as gdb.