Works, thanks! Hope the information cloud added to golang.org/doc/gdb
On Thursday, September 27, 2018 at 8:02:20 PM UTC+2, David Chase wrote:
>
> You did nothing wrong, in 1.11 we started compressing the debug
> information to reduce binary size, and gdb on the Mac does not understand
> compressed DWARF.
> We had hoped that the several speedbumps involved in running gdb on modern
> OSX would have caused most users to move to Delve, which handles compressed
> DWARF, but obviously this was overoptimistic.
>
> The workaround is to also specify "-ldflags=-compressdwarf=false" which
> does exactly what it claims.
> If you wanted to do this generally (so you did not need to remember),
>
> export GOFLAGS="-ldflags=-compressdwarf=false"
>
> You might try not specifying "-N -l" and see whether optimized binaries
> have adequate debugging information; it's not perfect, but we are hoping to
> get it good enough that core dumps and probes from/on running applications
> will yield useful information.
>
> Sorry for the inconvenience.
>
>
> On Thursday, September 27, 2018 at 9:38:23 AM UTC-4, changkun wrote:
>>
>> Debugging with GDB works fine on Linux, it is able to show everything
>> with the breakpoint. However, nothing appears on macOS.
>>
>> A simple Go program, say `main.go`:
>>
>> package main
>>
>> func main() {
>> println("hello, world!")
>> }
>>
>>
>> Then build with
>>
>> go build -gcflags "-N -l" -o main main.go
>>
>>
>> Using GDB:
>>
>> $ gdb main
>> GNU gdb (GDB) 8.2
>> (...)
>> Reading symbols from main...(no debugging symbols found)...done.
>> Loading Go Runtime support.
>> (gdb) source /usr/local/Cellar/go/1.11/libexec/src/runtime/runtime-
>> gdb.py
>> Loading Go Runtime support.
>> (gdb) info files
>> Symbols from "/Users/changkun/Desktop/demo/main".
>> Local exec file:
>> `/Users/changkun/Desktop/demo/main', file type mach-o-x86-64.
>> Entry point: 0x1049e20
>> 0x0000000001001000 - 0x000000000104dfcf is .text
>> 0x000000000104dfe0 - 0x0000000001077344 is __TEXT.__rodata
>> (...)
>> (gdb) b *0x1049e20
>> Breakpoint 1 at 0x1049e20
>> (gdb)
>>
>>
>> There is no `at` in the GDB outputs, the version of Go is `go version
>> go1.11 darwin/amd64` and:
>>
>> $ ls -al /usr/local/bin | grep go
>> lrwxr-xr-x 1 changkun admin 24 Aug 25 16:37 go -> ../
>> Cellar/go/1.11/bin/go
>>
>>
>>
>> ======
>>
>> Same process in linux environment:
>>
>> docker run -it --rm --name golang golang:1.11 bash
>>
>> then entering container install `gdb`
>>
>> root@1326d3f1a957:/# gdb main
>> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
>> (...)
>> (gdb) info files
>> Symbols from "/main".
>> Local exec file:
>> `/main', file type elf64-x86-64.
>> Entry point: 0x44a2e0
>> 0x0000000000401000 - 0x000000000044ea8f is .text
>> (...)
>> (gdb) b *0x44a2e0
>> Breakpoint 1 at 0x44a2e0: file
>> /usr/local/go/src/runtime/rt0_linux_amd64.s, line 8.
>> (gdb)
>>
>>
>> Linux is able to show with a breakpoint, `(gdb) b *0x44a2e0
>> Breakpoint 1 at 0x44a2e0: file
>> /usr/local/go/src/runtime/rt0_linux_amd64.s, line 8.`
>>
>> What did I do wrong on macOS? How can I perform low-level debugging for
>> Go programs on macOS with GDB?
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
