mirror of
https://github.com/golang/go
synced 2024-11-22 08:24:41 -07:00
4e2aa9bff0
The Plan 9 symbol table format defines big-endian symbol values
for portability, but we want to be able to generate an ELF object file
and let the host linker link it, as part of the solution to issue 4069.
The symbol table itself, since it is loaded into memory at run time,
must be filled in by the final host linker, using relocation directives
to set the symbol values. On a little-endian machine, the linker will
only fill in little-endian values during relocation, so we are forced
to use little-endian symbol values.
To preserve most of the original portability of the symbol table
format, we make the table itself say whether it uses big- or
little-endian values. If the table begins with the magic sequence
fe ff ff ff 00 00
then the actual table begins after those six bytes and contains
little-endian symbol values. Otherwise, the table is in the original
format and contains big-endian symbol values. The magic sequence
looks like an "end of table" entry (the fifth byte is zero), so legacy
readers will see a little-endian table as an empty table.
All the gc architectures are little-endian today, so the practical
effect of this CL is to make all the generated tables little-endian,
but if a big-endian system comes along, ld will not generate
the magic sequence, and the various readers will fall back to the
original big-endian interpretation.
R=ken2
CC=golang-dev
https://golang.org/cl/7066043
125 lines
4.5 KiB
HTML
125 lines
4.5 KiB
HTML
<!--{
|
|
"Title": "Go 1.1 Release Notes",
|
|
"Path": "/doc/go1.1",
|
|
"Template": true
|
|
}-->
|
|
|
|
<h2 id="introduction">Introduction to Go 1.1</h2>
|
|
|
|
TODO
|
|
- overview
|
|
- link back to Go 1 and also Go 1 Compatibility docs.
|
|
|
|
<h2 id="language">Changes to the language</h2>
|
|
|
|
TODO
|
|
|
|
<h2 id="impl">Changes to the implementations and tools</h2>
|
|
|
|
TODO: more
|
|
|
|
<h3 id="int">Size of int on 64-bit platforms</h3>
|
|
|
|
<p>
|
|
The language allows the implementation to choose whether the <code>int</code> type and <code>uint</code> types are 32 or 64 bits. Previous Go implementations made <code>int</code> and <code>uint</code> 32 bits on all systems. Both the gc and gccgo implementations (TODO: check that gccgo does) <a href="http://golang.org/issue/2188">now make <code>int</code> and <code>uint</code> 64 bits on 64-bit platforms such as AMD64/x86-64</a>.
|
|
Among other things, this enables the allocation of slices with
|
|
more than 2 billion elements on 64-bit platforms.
|
|
</p>
|
|
|
|
<p>
|
|
<em>Updating</em>:
|
|
Most programs will be unaffected by this change.
|
|
Because Go does not allow implicit conversions between distinct
|
|
<a href="/ref/spec#Numeric_types">numeric types</a>,
|
|
no programs will stop compiling due to this change.
|
|
However, programs that contain implicit assumptions
|
|
that <code>int</code> is only 32 bits may change behavior.
|
|
For example, this code prints a positive number on 64-bit systems and
|
|
a negative one on 32-bit systems:
|
|
|
|
<pre>
|
|
x := ^uint32(0) // x is 0xffffffff
|
|
i := int(x) // i is -1 on 32-bit systems, 0xffffffff on 64-bit
|
|
fmt.Println(i)
|
|
</pre>
|
|
|
|
<p>Portable code intending 32-bit sign extension (yielding -1 on all systems)
|
|
would instead say:
|
|
</p>
|
|
|
|
<pre>
|
|
i := int(int32(x))
|
|
</pre>
|
|
|
|
<h3 id="asm">Assembler</h3>
|
|
|
|
<p>
|
|
Due to the <a href="#int">int</a> and TODO: OTHER changes,
|
|
the placement of function arguments on the stack has changed.
|
|
Functions written in assembly will need to be revised at least
|
|
to adjust frame pointer offsets.
|
|
</p>
|
|
|
|
<h3 id="race">Data race detector</h3>
|
|
|
|
<p>
|
|
The implementation now includes a built-in <a href="/doc/articles/race_detector.html">data race detector</a>.
|
|
</p>
|
|
|
|
<h3 id="symtab">Symbol table</h3>
|
|
|
|
<p>
|
|
In the gc toolchain, the symbol table format has been extended to allow
|
|
little-endian encoding of symbol values, and the extension is used in
|
|
binaries generated by the Go 1.1 version of the gc linker.
|
|
To the Go 1.0 toolchain and libraries, these new symbol tables appear empty.
|
|
</p>
|
|
|
|
<h2 id="library">Changes to the standard library</h2>
|
|
|
|
<h3 id="debug/elf">debug/elf</h3>
|
|
<p>
|
|
Previous versions of the debug/elf package intentionally skipped over the first
|
|
symbol in the ELF symbol table, since it is always an empty symbol. This symbol
|
|
is no longer skipped since indexes into the symbol table returned by debug/elf,
|
|
will be different to indexes into the original ELF symbol table. Any code that
|
|
calls the debug/elf functions Symbols or ImportedSymbols may need to be
|
|
adjusted to account for the additional symbol and the change in symbol offsets.
|
|
</p>
|
|
|
|
<h3 id="net">net</h3>
|
|
|
|
<p>
|
|
The protocol-specific resolvers were formerly
|
|
lax about the network name passed in. For example, although the documentation was clear
|
|
that the only valid networks for <code>ResolveTCPAddr</code> are <code>"tcp"</code>,
|
|
<code>"tcp4"</code>, and <code>"tcp6"</code>, the Go 1.0 implementation silently accepted
|
|
any string. The Go 1.1 implementation returns an error if the network is not one of those strings.
|
|
The same is true of the other protocol-specific resolvers <code>ResolveIPAddr</code>, <code>ResolveUDPAddr</code>, and
|
|
<code>ResolveUnixAddr</code>.
|
|
</p>
|
|
|
|
<p>
|
|
The previous <code>ListenUnixgram</code> returned <code>UDPConn</code> as
|
|
arepresentation of the connection endpoint. The Go 1.1 implementation
|
|
returns <code>UnixConn</code> to allow reading and writing
|
|
with <code>ReadFrom</code> and <code>WriteTo</code> methods on
|
|
the <code>UnixConn</code>.
|
|
</p>
|
|
|
|
<h3 id="time">time</h3>
|
|
<p>
|
|
On FreeBSD, Linux, NetBSD, OS X and OpenBSD, previous versions of the time package
|
|
returned times with microsecond precision. The Go 1.1 implementation of time on these
|
|
systems now returns times with nanosecond precision. Code may exist that expects to be
|
|
able to store such a time in an external format with only microsecond precision,
|
|
read it back, and recover exactly the same time instant.
|
|
In Go 1.1 the same time will not be recovered, since the external storage
|
|
will have discarded nanoseconds.
|
|
To address this case, there are two new methods of time.Time, Round and Truncate,
|
|
that can be used to remove precision from a time before passing it to
|
|
external storage.
|
|
</p>
|
|
|
|
TODO
|