Hopefully a simple question on /proc/pid/mem

Hopefully this is a simple question. I'm trying to work on an external debugger that can bind to an external process, and open up memory locations on the heap to allow reading of data.

Now I've tried using ptrace(), mmap() & lseek/read all with no success. The closest I've been able to get is to use ptrace() to do an attach to the target process, but couldn't read much of anything from it. Plus I've seen tons of conflicting reports saying that each on is the best, and the other two are deprecated.

So what I'd appreciate help in is:

1) Which approach to use?
2) Maybe a sample program that lets me read address 0x8000000 from another process. I know this address is an integer, but I can't ever mmap, read or do a PEEKDATA on it.

Thanks in Advance to any pointers or help you can provide.I can provide sample code to stuff I've tried, or any other information if it will help. Thanks.

--Rich

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Hi,

ptrace is what other debuggers use. It really ought to work.

Cheers,
Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Well ptrace connects, but getting the data out is what seems to be the really tough part. I've seen some examples of opening up the /proc/pid/mem file just using the

.................
int addr=0x<some memory address>;
char buffer[255];

proc_file=open ("/proc/pid/mem",O_RDONLY);
lseek(proc_file,addr,SEEK_SET);
read (proc_file,buffer,sizeof(buffer));
.................

But then the system complains about "No Such Process". I know the process is working and this fails as both the user running the target process, as well as root. I'm also using a 2.2.16 kernel stock from RH7.0 (but I didn't think that would really matter). I don't need register access (at least not yet).

The only other thing I'm wondering is if there is some permission that must be granted by the target process, but I've already tried the ptrace(PTRACE_TRACEME) line.

Thanks.

--Rich

I wonder what's wrong with reading from /proc/<pid>/mem, though - it's using the same code as ptrace.

Al, considering adding /proc/<pid>/{regs,fpregs,ctl} and moving ptrace() entirely to userland...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

We can actually do this cleanly now that we have proper page_dirty semantics for raw io. The original reason for disabling /proc/*/mem was that it left big gaping holes in the mm code in 2.0, and it hasn't been repaired since.

-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

ITYM "disabling _write_ on /proc/*/mem". Read is OK. Anyway, current mem_write() uses the same code as PTRACE_POKEDATA, so if the latter works, the former also should be OK.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Actually, even read on /proc/*/mem caused problems in 2.0: the elevated usage could would prevent memory from being reclaimed by the swapper properly. Things are so much better now it's not even funny.

-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

ISTR removing some rather nasty code during the procfs rewrite. From mem_read() and mem_write() - basically, made them wrappers around access_process_vm().

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Hi,

It was mmap of /proc/*/mem which was busted. read/write should be OK.

Hint: think about what happens if you make a shared mapping of a private proc/*/mem region...

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Now that we have reusable swap cache pages we could make it work correctly, except for the case of the first write a private mapping of
file. Not that we would want to...

Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Hi,

Think about fork. If a parent forks and then touches a private page before the child does, it's the parent which gets a new page. The supposed shared mmap of the parent now points to the child's page, not the parent's. COW basically just can't do the right thing if a page is both shared and private at the same time.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Right. This is a different context but it has the same properties of what I was thinking of. The fact that fork has the problem too, means it's definitely not doable right now. At least not with the intuitive semantics. If we either denied shared mappings of private mappings or simply promoted them to shared mappings we could easily do a non-buggy implementation.

The problem isn't really COW, the copy on write is easy. The hard part it to appropriately share the resulting copy. If we really had to do this it might be possible by playing with the open method in the vma_operations. Implementation wise I think a shared private mapping of a file is really a harder case than fork COW pages.

I think it is a better argument that since nothing except a mmap of /proc/pid/mem needs the complexity of simultaneously shared and private mappings, it isn't worth supporting them.

Eric

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/