Support for 32-bit systems about delve

[c5253458]

Learn about multiplatform !

That is different CPUs, architectures, Operating systems (a distribution is not an operating system), different countries, different encodings, ...

Ignorant hobbyists, believing their development machine is the world, are such a drag.

[smhulkund]

When can we expect the release for 32 bit system ?

[tenortim]

I've made a start on this, and have something somewhat functional for Linux/386.
The branch is at https://github.com/tenortim/delve/tree/linux_386
Per the commit message, there are a number of things that should be changed before it can be merged (and I haven't even started on OSX or Windows support), but I wanted to get this out there and get comments etc.

[prai14]

When can we get this support for 32 bit system ?

I am using 32bit window laptop and not able to debug go program.

[derekparker]

That is correct, the proctl package is all 64-bit specific. It should be trivial to remove or modify any 64-bit specific code. 32-bit support is the next major task I'd like to check off, aside from general OS X support.

[bbartol]

This would be useful for me as well. I am trying to debug a go program using LiteIDE on a Raspberry Pi 3. I get a segmentation fault error with gdb specified as the debugger in LiteIDE - apparently gdb doesn't play well with go (see second paragraph here - https://golang.org/doc/gdb). So I then decided to try delve; and when I did "go get -u github.com/derekparker/delve/cmd/dlv", I got the subject error:

github.com/derekparker/delve/proc/disasm.go:9: undefined: ArchInst

So I am thinking that unless this gets "fixed" or there is another debugger out there somewhere for go, anybody trying to step through go code on a Raspberry Pi is out of luck.

Other than this, I really like the LiteIDE. It is indeed light - it loads quickly and doesn't lag at all when I am using it (I have it running on ubuntu MATE on my Pi). And given the nature of the problem I am having running a debugger, I don't think it is going to help to switch to a different IDE. So since I do like LiteIDE, I have no desire or see no potential benefit in going down the rabbit hole of trying another IDE.

Any other thoughts or status?

Thanks!

[aarzilli]

@tenortim This is a commendable effort, thank you!

I think instead of passing the Thread to TLS it would be better to read it in proc/native.registers and save it directly inside Regs.

Most (all?) checks for runtime.GOARCH will have to be replaced with calls to Arch or similar. For example:

• op.DwarfRegisters has a SPRegNum field
• everywhere we carelessly called binary.LittleEndian.Uint64 should be replaced with a call to proc.Arch.DecodePtr (which doesn't exist)
• pkg/dwarf/frame, pkg/dwarf/line and pkg/dwarf/op will have to get the pointer size from somewhere and use it

You don't have to do this, though, finding all the places is more than enough.

If you need help with anything, let me know.

[gidoBOSSftw5731]

Im on arm64 but still cannot install this package! Same error as if I had a i386 computer.

[sethwklein]

I'm out of time now, but I want to throw some stuff in here to save time for the next person who looks at this. These instructions trade the precision of a branch for markers of intent that hopefully will prevent them from bit rotting so fast. The 32bit branch no longer applies cleanly to master.

To start running tests in proctl...

• move proctl_linux_amd64.go -> proctl_linux.go
• move breakpoints_linux_amd64.go -> breakpoints_linux.go
• move setHardwareBreakpoint from breakpoints_linux.go to breakpoints_linux_amd64.go and add C imports from breakpoints_linux.go but change the definition of offset to a declaration
• copy breakpoints_linux_amd64.go -> breakpoints_linux_386.go and replace C.DR_LEN_8 with whatever is correct. I don't know, but I used C.DR_LEN_4
• copy threads_linux_amd64.go -> threads_linux_386.go and replace Rsp with whatever is correct. I don't know, but I used uint64(Esp)

At this point, proctl tests should run, but fire hose your terminal with "Hello, World!". You may have to killall testprog from another terminal to make it stop. After you fix that, you should see the tests panicking in "delve/dwarf/frame".parseFDE. If you make a test like the following, you'll find that this doesn't happen on an actual binary, but the proctl code calls frame.Parse on /proc/{{fd}}/exe, not directly on a binary.

package frame

import (
    "debug/elf"
    "os"
    "os/exec"
    "testing"
)

func DirectTest(t *testing.T) {
    const progName = "./testprog"
    cmd := exec.Command("go", "build", "-gcflags=-N -l", "-o", progName, "../../_fixtures/"+progName+".go")
    err := cmd.Run()
    if err != nil {
        t.Fatalf("Couldn't compile test program: %v\n", err)
    }
    defer os.Remove(progName)

    exe, err := elf.Open(progName)
    if err != nil {
        t.Fatalf("ELF missing: %v\n", err)
    }

    sec := exe.Section(".debug_frame")
    if sec == nil {
        t.Fatalf("No debug frame section: %v\n", err)
    }

    data, err := sec.Data()
    if err != nil {
        t.Fatalf("No debug frame data: %v\n", err)
    }

    Parse(data)
}

The uses of 8 and 16 in parseFDE is suspicious, but tests (including the one above) succeed whether they are changed to 4 and 8 or not. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087#c24 may be relevant, or not.

glhf!

[joegrasse]

Just ran into this on a linux box. Any progress on this front?

Also, it might be nice to make the 64bit requirement more prominent in the docs.

[derekparker]

@joegrasse as far as I'm aware nobody is working on this, but I agree it is important. I also agree we should point out in installation docs the processor requirements. I'll update the documentation shortly.

[joegrasse]

I was taking a look at this for 32bit linux, but there are a couple things I can't seem to locate.

For example, does anyone know what the following should be for 32bit linux?

https://github.com/derekparker/delve/blob/e7a9a3ea9a72d943a9e9012977d28419933f5896/proc/registers_linux_amd64.go#L71

Also, here.

https://github.com/derekparker/delve/blob/e7a9a3ea9a72d943a9e9012977d28419933f5896/proc/arch.go#L45

[aarzilli]

does anyone know what the following should be for 32bit linux?

I don't but disassembling a go program compiled for 32bit linux will probably reveal it (I also do not know how segments work in protected mode, I skipped that section of the intel manual).

[joegrasse]

I have delve partially working on 32bit linux and based on your comment here https://github.com/derekparker/delve/issues/468#issuecomment-203968010, I get the following output.

32bit

TEXT main.main(SB) /usr2/shared/graj04/gowork/src/github.com/joegrasse/cgotest/cgotest.go
        cgotest.go:12   0x8048e60       658b0d00000000          mov ecx, dword ptr gs:[]
        cgotest.go:12   0x8048e67       8b89fcffffff            mov ecx, dword ptr [ecx+0xfffffffc]
        cgotest.go:12   0x8048e6d       3b6108                  cmp esp, dword ptr [ecx+0x8]
        cgotest.go:12   0x8048e70       0f86d2000000            jbe 0x8048f48
=>      cgotest.go:12   0x8048e76*      83ec3c                  sub esp, 0x3c

64bit

TEXT main.main(SB) /usr2/shared/graj04/gowork-64/src/github.com/joegrasse/cgotest/cgotest.go
        cgotest.go:12   0x401360        64488b0c25f8ffffff      mov rcx, qword ptr fs:[0xfffffff8]
        cgotest.go:12   0x401369        483b6110                cmp rsp, qword ptr [rcx+0x10]
        cgotest.go:12   0x40136d        0f86fa000000            jbe 0x40146d
=>      cgotest.go:12   0x401373*       4883ec78                sub rsp, 0x78

Looks like it isn't quite as straight forward on 32bit.

[aarzilli]

It's not that different. The big problem is that ptrace on 86x64 does not return the base address of the GS segment.
Apparently to read it you have to do something like this which involves calling PTRACE_GET_THREAD_AREA which golang.org/x/sys/unix does not currently implement :(

[joegrasse]

@rsc is there an easy way to get the base address of the thread local storage memory on 386 linux in Go? On 64bit linux it looks like you can just use PtraceRegs.Fs_base.

[joegrasse]

Just curious if anyone has picked this up yet, or is this still a ways off?

[alexbrainman]

Probably, wouldn't be difficult to implement on windows. Both amd64 and 386 use same Windows API. As long as the rest of code is not 64-bit specific, I think windows-386 part will be small.

Alex

[niondir]

I could need this as well. Would be happy to hear if someone is working on the topic.

[jcmontx]

Any news on this? It'd be really useful for me.

[declanshanaghy]

I'm also developing a Raspberry Pi 3 go app and would love to be able to debug it remotely rather than rely on print statements! 👍

[Mazza-Chen]

I have the same problem on Windows 7 32 bit : disasm.go:9: undefined: ArchInst

[dlsniper]

@gidoBOSSftw5731 that's because ARM architectures are not supported by Delve currently, see: https://github.com/derekparker/delve/issues/118

[Evengard]

Any progress on this one? My project heavily relies on some i386 C code (which we attempt to migrate to Go - but there's just too much, the process is slow, and it is really i386 locked), and there's a need to debug the Go code somehow.

[aarzilli]

linux/i386 has been supported for a while.

[Evengard]

Hrm, didn't knew, my main dev env is Windows. I'll check it out, thanks.

[aarzilli]

Closing since linux/386 has been supported for years, there are many different 32bit architectures and for some of them (including mips, arm32 and windows/386) we have specific issues open.