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/