mirror of
https://github.com/golang/go
synced 2024-11-20 06:44:40 -07:00
76689845e3
Do not skip the first symbol in the symbol table. Any other indexes into the symbol table (for example, indexes in relocation entries) will now refer to the symbol following the one that was intended. Add an object that contains debug relocations, which debug/dwarf failed to decode correctly. Extend the relocation tests to cover this case. Note that the existing tests passed since the symbol following the symbol that required relocation is also of type STT_SECTION. Fixes #4107. R=golang-dev, mikioh.mikioh, iant, iant CC=golang-dev https://golang.org/cl/6848044
76 lines
2.4 KiB
HTML
76 lines
2.4 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>
|
|
|
|
<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>
|
|
|
|
TODO
|