It helps if you've hit the same issue before :) On Wed, Jun 15, 2016 at 8:14 AM, Dave Mazzoni <dav...@gmail.com> wrote: > Wow. You all are incredible -- your suggestion nailed it. Now I'm getting: > > ./peekgo 0x43c00000 > mem[0]:0x3020100 mem[1]:0x7060504 mem[2]:0xb0a0908 > mem[3]:0xf0e0d0c ... > > which is PERFECT. Thanks! > > > On Tue, Jun 14, 2016 at 6:05 PM, Ian Lance Taylor <i...@golang.org> wrote: >> >> On Tue, Jun 14, 2016 at 2:47 PM, Dave Mazzoni <dav...@gmail.com> wrote: >> > >> > Thanks for the suggestions. I'm a bit confused though since Mmap returns >> > a >> > slice of bytes. I print all the bytes as you can see, but only the first >> > byte at each 32 bit boundary is correct. I don't know casting several of >> > them together would somehow derive the correct value. >> >> Because Mmap returns a []byte, every access using that []byte will >> load a single byte. But device memory is often magic. Doing a byte >> load and doing a word load are two very different things from the >> device's perspective. So what we're suggesting is that you do >> something like >> b := syscall.Mmap(...) >> w := (*[1024]uint32)(unsafe.Pointer(&b[0])) >> and then print w[0]. That will access the memory as a 32-bit word, not a >> byte. >> >> Or conversely change your C program to print out one byte at a time >> and see what you get. >> >> Ian > >
-- 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.
