Re^2: Accessing Memory-mapped I/O

Here is a snippet of perl code:

open(FH, "<", "/dev/mem");
binmode(FH);
seek(FH,0xff230180,0);  #Fails with bad address
[download]

Here is a snippet of C code:

devmem_fd = open("/dev/mem", O_RDWR | O_SYNC);
bridge_map = (uint32_t*)mmap(NULL, 0x100, PROT_READ|PROT_WRITE, 
    MAP_SHARED, devmem_fd, 0xff230180);
reg = (uint32_t*) bridge_map;
printf("Register contents: 0x08x\n", *reg);
munmap (bridge_map, 0x100);
close(devmem_fd);
[download]

Comment on Re^2: Accessing Memory-mapped I/O Select or Download Code

Replies are listed 'Best First'.
Re^3: Accessing Memory-mapped I/O by Corion (Patriarch) on Oct 31, 2019 at 17:32 UTC
You're doing two completely different thing between the Perl code and the C code. Does the C code still work when using `seek`? Does the Perl code work when using (for example) File::Map?	[reply] [d/l]
Re^4: Accessing Memory-mapped I/O by Anonymous Monk on Oct 31, 2019 at 17:38 UTC
I have not tried C code using seek. Nor have I tried File::Map on my limited system as I don't have access to File::Map. CPAN is not functioning to install it.	[reply]
Re^5: Accessing Memory-mapped I/O by stevieb (Canon) on Oct 31, 2019 at 20:11 UTC
What system is this (OS, 32 or 64 bit etc), and what version of perl? I can't reproduce the Perl issue you describe on Linux Mint 18.3 64-bit, nor Raspbian (armv7l) 32-bit. Both return without any warning or error (even after adding `strict` and `warnings`). On the 64-bit platform I've got Perl 5.26.1, and on the 32-bit one, I've got Perl 5.30.0. Update: I agree with Corion, the Perl code doesn't reflect at all what the C code is doing.	[reply] [d/l] [select]
Re^6: Accessing Memory-mapped I/O by Anonymous Monk on Nov 01, 2019 at 12:16 UTC
Re^7: Accessing Memory-mapped I/O by jcb (Parson) on Nov 01, 2019 at 22:42 UTC
Some notes below your chosen depth have not been shown here
Re^7: Accessing Memory-mapped I/O by Anonymous Monk on Nov 01, 2019 at 12:18 UTC
Some notes below your chosen depth have not been shown here