Messages in this thread | | | Date | Sun, 7 Nov 1999 17:36:50 +0000 (GMT) | From | Eleonora Autore <> | Subject | Re: 2.3.26: high_memory and vmalloc()'d stuff (modules in particular) |
| |
the function below assumes that module_list always points to the module with the highest virtual address in module_info->addr. Now that I think of it, it is not a fair assumption (though true if you never unload any modules), so get_kcore_size should really walk through the list and pick up the highest address.
I will adjust it, test it and send the patch later.
Regards, Tigran.
On Sun, 7 Nov 1999, Eleonora Autore wrote:
> Hi, > > I have just solved this problem (and tested both with and without modules > loaded). Here is what the size should be: > > unsigned long get_kcore_size(void) > { > unsigned long size; > > if (module_list == &kernel_module) > size = ((size_t)high_memory - PAGE_OFFSET); > else > size = (unsigned long)module_list + module_list->size - > PAGE_OFFSET; > size += PAGE_SIZE; /* for the ELF header */ > return size; > } > > this function should live in kernel/module.c because kernel_module is > static to that compilation unit. So, now one can dump module's structures > in gdb via /proc/kcore :) > > I will make a patch and send to you and Linus if you don't object? > > Regards, > Tigran. > > PS. This solution wastes a few M of "holes" if one dd's the image because > vmalloc maps addresses beyond physical memory on 8M boundary (or so) but > this is far better than having hardcoded 2G or 4G or whatever... > > > PPS. Btw, does anyobody know if it is possible to tell gdb to load symbol > table in "ksymoops -s map" style instead of having to read it off the ELF > binary via "file" command? That would be useful (i.e. to have module's > symbols as well). > > On Sun, 7 Nov 1999, Eleonora Autore wrote: > > > 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/
| |