Messages in this thread | | | Date | Sun, 7 Nov 1999 15:15:09 +0000 (GMT) | From | Eleonora Autore <> | Subject | 2.3.26: high_memory and vmalloc()'d stuff (modules in particular) |
| |
Hello David and the World,
I am trying to enhance your ELF /proc/kcore read routine to deal with the kernel virtual addresses corresponding to dynamically loaded modules.
I managed to successfully dump data structures in gdb vmlinux /proc/kcore by making the size very large (260M). Obviously this is not a perfect solution but is tied to this particular machine. Besides, I want to be able to dd if=/proc/kcore of=kcore.img and dumping 260M of stuff most of which is garbage is not very elegant.
So, the question (to everyone) is:
How do we determine the value similar to high_memory but one that covers modules as well? I.e. currently size is calculated as:
size = ((size_t)high_memory - PAGE_OFFSET) + PAGE_SIZE;
so, if high_memory=0xc4000000 and module's data structure is at 0xc4815a6c we can't dump it in gdb because dhdr->p_memsz/p_filesz are set accordingly in the ELF core header.
Any ideas anyone? Ideally, there would be (or is there already?!) something called highvm_memory that would be used instead of high_memory and would make /proc/kcore's size lazy-dynamically-adjustable on the fly as new modules are loaded. I could hack vmalloc()/vfree() to do that but perhaps it is already done, so I am asking you (in the meantime I will go and try to find a way of determining it).
Regards, Tigran.
PS. I don't submit the patch even though it works for me because this "solution" is obviously only a temporary workaround - I want a proper "highvm_memory" or something...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |