delta/go-git.git/src/debug, branch dev.debug

debug/dwarf: heuristically handle both UNIX and Windows paths

2017-05-26T14:35:20+00:00

Currently debug/dwarf assumes all paths in line tables will be
UNIX-style paths, which obviously isn't the case for binaries built on
Windows. However, we can't simply switch from the path package to the
filepath package because we don't know that we're running on the same
host type that built the binary and we want this to work even if we're
not. This is essentially the approach taken by GDB, which treats paths
in accordance with the system GDB itself is compiled for. In fact, we
can't even guess the compilation system from the type of the binary
because it may have been cross-compiled.

We fix this by heuristically determining whether paths are UNIX-style
or DOS-style by looking for a drive letter or UNC path. If we see a
DOS-style path, we use appropriate logic for determining whether the
path is absolute and for joining two paths. This is helped by the fact
that we should basically always be starting with an absolute path.
However, it could mistake a relative UNIX-style path that begins with
a directory like "C:" for an absolute DOS-style path. There doesn't
seem to be any way around this.

Fixes #19784.

Change-Id: Ie13b546d2f1dcd8b02e668583a627b571b281588
Reviewed-on: https://go-review.googlesource.com/44017
Run-TryBot: Austin Clements 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor 
Reviewed-by: Alex Brainman

cmd/link: actually generate .debug_gdb_scripts section on windows

2017-05-15T06:16:19+00:00

Adjust finddebugruntimepath to look for runtime/debug.go file
instead of runtime/runtime.go. This actually finds runtime.GOMAXPROCS
in every Go executable (including windows).

I also included "-Wl,-T,fix_debug_gdb_scripts.ld" parameter to gcc
invocation on windows to work around gcc bug (see #20183 for details).

This CL only fixes windows -buildmode=exe, buildmode=c-archive
is still broken.

Thanks to Egon Elbre and Nick Clifton for investigation.

Fixes #20183
Fixes #20218

Change-Id: I5369a4db3913226aef3d9bd6317446856b0a1c34
Reviewed-on: https://go-review.googlesource.com/43331
Reviewed-by: Ian Lance Taylor

cmd/internal/obj: fix LSym.Type during compilation, not linking

2017-05-02T00:21:33+00:00

Prior to this CL, the compiler and assembler
were sloppy about the LSym.Type for LSyms
containing static data.

The linker then fixed this up, converting
Sxxx and SBSS to SDATA, and SNOPTRBSS to SNOPTRDATA
if it noticed that the symbol had associated data.

It is preferable to just get this right in cmd/compile
and cmd/asm, because it removes an unnecessary traversal
of the symbol table from the linker (see #14624).
Do this by touching up the LSym.Type fixes in
LSym.prepwrite and Link.Globl.

I have confirmed by instrumenting the linker
that the now-eliminated code paths were unreached.
And an additional check in the object file writing code
will help preserve that invariant.

There was a case in the Windows linker,
with internal linking and cgo,
where we were generating SNOPTRBSS symbols with data.
For now, convert those at the site at which they occur
into SNOPTRDATA, just like they were.

Does not pass toolstash-check,
but does generate identical linked binaries.

No compiler performance changes.

Change-Id: I77b071ab103685ff8e042cee9abb864385488872
Reviewed-on: https://go-review.googlesource.com/40864
Run-TryBot: Josh Bleecher Snyder 
TryBot-Result: Gobot Gobot 
Reviewed-by: Alex Brainman 
Reviewed-by: Michael Hudson-Doyle

debug/pe: add TestBuildingWindowsGUI

2017-03-30T01:19:57+00:00

Change-Id: I6b6a6dc57e48e02ff0d452755b8dcf5543b3caed
Reviewed-on: https://go-review.googlesource.com/38759
Reviewed-by: Ian Lance Taylor

cmd/link: write dwarf sections

2017-03-01T04:51:03+00:00

Also stop skipping TestExternalLinkerDWARF and
TestDefaultLinkerDWARF.

Fixes #10776.

Change-Id: Ia596a684132e3cdee59ce5539293eedc1752fe5a
Reviewed-on: https://go-review.googlesource.com/36983
Reviewed-by: Ian Lance Taylor

debug/pe: add test to check dwarf info

2017-02-16T00:05:51+00:00

For #10776.

Change-Id: I7931558257c1f6b895e4d44b46d320a54de0d677
Reviewed-on: https://go-review.googlesource.com/36973
Run-TryBot: Alex Brainman 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor

cmd/objdump: copy gosym.PCValue into internal package

2016-12-01T18:20:04+00:00

... so we don't have to export gosym.PCValue.

Change-Id: Ie8f196d5e5ab63e3e69d1d7b4bfbbf32b7b5e4f5
Reviewed-on: https://go-review.googlesource.com/33791
Run-TryBot: Keith Randall 
Reviewed-by: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot

debug/pe: do not create symbol table if FileHeader.PointerToSymbolTable is 0

2016-11-17T07:55:06+00:00

https://github.com/tpn/pdfs/raw/master/Microsoft Portable Executable and Common Object File Format Specification - 1999 (pecoff).doc
says this about PointerToSymbolTable:

File offset of the COFF symbol table or 0 if none is present.

Do as it says.

Fixes #17809.

Change-Id: Ib1ad83532f36a3e56c7e058dc9b2acfbf60c4e72
Reviewed-on: https://go-review.googlesource.com/33170
Reviewed-by: Ian Lance Taylor 
Run-TryBot: Alex Brainman 
TryBot-Result: Gobot Gobot

debug/elf: SPARC64 relocation type is only 8 bits

2016-11-10T22:58:49+00:00

https://docs.oracle.com/cd/E53394_01/html/E54813/chapter6-54839.html#OSLLGchapter6-24:

"For 64–bit SPARC Elf64_Rela structures, the r_info field is further
broken down into an 8–bit type identifier and a 24–bit type dependent
data field. For the existing relocation types, the data field is
zero. New relocation types, however, might make use of the data bits.

 #define ELF64_R_TYPE_ID(info)         (((Elf64_Xword)(info)<<56)>>56)
"

No test for this because the only test would be an invalid object file.

Change-Id: I5052ca3bfaf0759e920f9a24a16fd97543b24486
Reviewed-on: https://go-review.googlesource.com/33091
Reviewed-by: Michael Hudson-Doyle

all: make copyright headers consistent with one space after period

2016-11-04T20:46:25+00:00

Continuation of CL 20111.

Change-Id: Ie2f62237e6ec316989c021de9b267cc9d6ee6676
Reviewed-on: https://go-review.googlesource.com/32830
Reviewed-by: Brad Fitzpatrick