How 8 bit memory access behaves when we replace replace the /dev/mem mapping with a normal memory allocation

Question

0.00/5 (No votes)

See more:

This is the code and it gives segmentation fault (core)

static uint32_t map_size = 0x08000000;
static uint32_t map_base = 0x18000000;
static uint32_t map_addr = 0x00000000;
static uint64_t cycle_count = 0x1000000;


static char *dev_mem = "/dev/mem";

int main(int argc, char **argv) {
int fd;
uint8_t *buf;
if ((fd = open(dev_mem, O_RDWR | O_SYNC)) == -1) {
    printf("can't open /dev/mem .\n");
    exit(EXIT_FAILURE);
}

buf = (uint8_t *) malloc(sizeof(uint8_t));
if (buf == 0) {
    printf("Can't be mapped. \n");
    exit(EXIT_FAILURE);
} else
    map_addr = (long unsigned) buf;

uint8_t sum = 0;

while (cycle_count-- > 0)
    sum += *buf++;

printf("%u\n", sum);
close(fd);
exit(EXIT_SUCCESS);


return 0;
  }

What I have tried:

So, I was observing how execution time behaves for various bit word, below is example of a program that read 8 bits word. I wanted to check how it behaves when we replace the /dev/mem mapping with a 'normal' memory allocation (i.e by malloc/calloc). But my code started giving segmentation fault (Core dump). Any help?

I am new to this, so sorry if the errors are silly.

Posted 6-Jun-18 9:58am

Member 13861762

Updated 6-Jun-18 21:44pm

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Rick York · Answer 1 · 2018-06-06T10:39:00

Study carefully what is going in this code. The reason for the fault is obvious to me. To begin, the file that is opened, /dev/mem, is not used for anything. Remove all references to it and you will see the code still compiles. The problem is you are allocating a buffer of size one byte (sizeof(uint8_t)), assuming that is 8 bits, assigning a pointer to it, and then trying to access 0x1000000 bytes of that buffer. The only way that might possibly run without faulting is on a processor with an unprotected, flat address space. The buffer has to be a minimum of 0x1000000 bytes for the code to run correctly.

Actually, it appears to me that you are attempting to map a file into the memory space of your app. Look up the functions MapViewOfFile and CreateFileMapping to do this.

Jochen Arndt · Answer 2 · 2018-06-06T21:45:00

You have to know how memory is managed on your (Linux) system. When calling malloc(), it will be checked if there is enough space on the heap of the application to satisfy the request. If not, the heap of your program will be increased by requesting more memory from the system. The actual heap is assigned to your application by the operating system so that it can do anything with that memory. But accessing memory not assigned to your application is guarded and results in a segmentation fault.

That is what happens here as described in solution 1: you are allocating a buffer of 1 byte but accessing 0x100000 = 1 MB.

While accessing the first bytes of that 1 byte buffer usually works because there might be some remaining (unsused) memory on the heap, the segmentation fault occurs once your buf pointer leaves the heap of your application (more precise: leaves the range of memory that has been assigned to your application by the operating system).

How 8 bit memory access behaves when we replace replace the /dev/mem mapping with a normal memory allocation

2 solutions

Solution 1

Solution 2

Add your solution here

Preview 0