0

I'm trying to implement the solution suggested in this question

Is it possible to store pointers in shared memory without using offsets?

The proposed solution involves specifying a memory to 0x20000000000 to

void *shmat(int shmid, const void *shmaddr, int shmflg);

The problem is that this mapping may fail because its in use already. I want to know if this can be avoided by making sure 0x20000000000 is not used by

  1. kernel
  2. linker (i.e. .text/.bss etc. regions of executable)

This is what I found so far which isn't very satisfactory

How do I pass virtual address to shmat() function in a guaranteed way

Community
  • 1
  • 1
user1827356
  • 6,764
  • 2
  • 21
  • 30
  • If you do the `shmat(id, NULL, flag);` and follow with a `fork();`, then the parent and child already share memory at the same addresses. If your processes are in completely different address spaces, then your question is wrong. You want to find a unique pointer/shmat for two (or more) processes. You can't pick some address generically. `cat /proc/pid/maps` has this info. Typically the memory split is 3G/1G on 32-bit, so kernel only uses high memory. – artless noise May 07 '13 at 23:59
  • @artlessnoise - I agree fork could work, but its messy. I'm not sure I follow "If your processes are in completely different address spaces, then your question is wrong". Could you explain? I was hoping there would be a way to mark a section of virtual address space to be unavailable to - loader/linker, kernel and heap. Is there some way? – user1827356 May 08 '13 at 14:19
  • You would have to do this for *every executable* that uses this mechanism. The kernel can map shared libraries, like `libc`, to any location that is free. You could create a linker script for all of the *executables* and reserve some common low memory location. I was saying you can not do this if you are writing a library; you need to have control over the address space. A library could search through `/proc/pid/maps` to find a free region in all processes and try to use that. By using a *linker script*, you can reserve some area if you are building all of the main executeables. – artless noise May 08 '13 at 14:30
  • I do have access to the executable(s) using this mechanism. Would you be able to post a startup example of such a script/program? – user1827356 May 08 '13 at 14:40
  • Try `ld --verbose` with your standard linker line. This should dump the linker scripts in use. Lots of on-line resource: [sections when linking](http://stackoverflow.com/questions/9508290/how-to-specify-base-addresses-for-sections-when-linking-or-alternatively-how-to), [Elf object format](http://www.linuxjournal.com/article/1060), etc. – artless noise May 08 '13 at 15:09
  • Fair enough, I can try it out. My reservation is that if the approach is valid i.e. if one reserves memory using the linker script, will shmat on that location work without fail? – user1827356 May 08 '13 at 17:58
  • The question would be will `ld.so` reserve this memory. I tried `man ld.so` and I don't see anyway to reserve memory. If you map a section to a linker script, then the `ld.so` will allocate it via `mmap` or something else. When this happens, `shmat` will fail. You could **statically link** and then reserve a section as `NOLOAD` and I think that would work. Somehow, you will have to free/release a section with `ld.so`, maybe with `munmap`, but that is a guess. – artless noise May 08 '13 at 18:33

0 Answers0