Atsushi Nemoto wrote: > On Mon, 9 Oct 2006 17:59:20 +0100, Thiemo Seufer <ths@xxxxxxxxxxxx> wrote: >>> Just for clarification: IIRC this optimization needs somewhat >>> up-to-date binutils/gcc and is not enabled on current lmo kernel, >>> right? >> For old toolchains there used to be a gruesome hack (which AFAIR broke >> at some point), for modern toolchains there's -msym32. > > Hmm, I found that the -msym32 is enabled if BUILD_ELF64 was not > selected, since 2.6.17. But does CONFIG_BUILD_ELF64=n really work for > modules? While MAP_BASE is 0xc000000000000000 for most 64-bit > platforms, I suppose modules should not be compiled with -msym32. > heh ? I'm wondering if anybody is using 'CONFIG_BUILD_ELF64=n' config at all... Atsushi, do you have any idea on how address are translated with 'CONFIG_BUILD_ELF64=n' config ? How such code is supposed to work ? code_resource.start = virt_to_phys(&_text); code_resource.end = virt_to_phys(&_etext) - 1; data_resource.start = virt_to_phys(&_etext); data_resource.end = virt_to_phys(&_edata) - 1; Let's say that '&_text' is in KSEG0 and is equal to 0xffffffff80000000. In this case virt_to_phys() returns 0x57ffffff80000000 (with PAGE_OFFSET = 0xa800000000000000). Is this physical address correct ? Thanks Franck
