Odp: Re: AlphaCore 2.0 vs. AlphaServer 4100

[Sergey Tikhonov]

Sergey Tikhonov wrote:

> Michal Jaegermann wrote:
>
>>> Yes, as soon as I figure out what to do with famost "Relocation" 
>>> problem with modules on Alpha.
>>>   
>>
>>
>> By any chance this will not be the following (I got that a long
>> time ago with an obvious white-space damage so if this cast is
>> really missing then it has to be added with an editor)?
>>
>> ---------------------------
>>
>> On Mon, Jan 05, 2004 at 02:21:37AM +0100, Måns Rullgård wrote:
>>  
>>
>>> I compiled Linux 2.6.0 for Alpha, and it mostly works, except the
>>> somewhat large modules. They fail to load with the message
>>> "Relocation overflow vs section 17", or some other section number.
>>>   
>>
>>
>> This failure happens with GPRELHIGH relocation, which is *signed*
>> short, but relocation overflow check in module.c doesn't take into
>> account the sign extension.
>> Appended patch should help.
>>
>> Ivan.
>>
>> --- 2.6/arch/alpha/kernel/module.c Wed May 28 01:05:20 2003
>> +++ linux/arch/alpha/kernel/module.c Mon Aug 11 23:23:02 2003
>> @@ -259,7 +259,7 @@ apply_relocate_add(Elf64_Shdr *sechdrs,
>> *(u64 *)location = value;
>> break;
>> case R_ALPHA_GPRELHIGH:
>> - value = (value - gp + 0x8000) >> 16;
>> + value = (long)(value - gp + 0x8000) >> 16;
>> if ((short) value != value)
>> goto reloc_overflow;
>> *(u16 *)location = value;
>>
>> ---------------------------
>>
>> I would think that this was applied a long time ago but maybe
>> not?  I cannot check at this moment.
>>  
>>
> Yes, this one is applied.
> There are other relocation problems related to "per_cpu data" 
> reference ipv6 module (this easily fixed by compiling module in).
> Another one I got today while testing qboot3 iso image with recent 
> fixes to kernel. It is "cramfs" module and relocation type is
> R_ALPHA_LITERAL. It seems it depens on size of .text and .data 
> sections plus where .got section is allocated. I am still trying
> to understand all of this.

Well, I got "relocation" problem in cramfs module fixed. As I suspected 
it was due how different sections of module layouted in memory.
In general it was like this:
.text
.data
.got
.small data sections
.bss

The size of .got section was calculated during module loading (for all 
symbols that required "literal" relocation), so the sections that followed
.got section were moved down. The arch specific module relocation logic 
calculated value for GP register as start address of
core sections (text + all data sections) + their total size - 0x8000. 
This allow to use GPRELLOW relocation (which is just 16 bit offset).
For "cramfs" module failure it couldn't calculate relocation from GP 
pointer to the begining of .got section, because offset to .got section 
was more
than 16 bit value. I think it happened because of size of .got section 
was known in advance and during module loading it became big.
Actually, we need just first address of .got section - all other data in 
it is addressed by index from first address. So, I just made module loading
logic to load .got section after the all data section and everything 
started to work. :)

Now about "per_cpu" relocation problem. I have no idea how to fix it, so 
may be someone has some idea.
Here what is going on. A module declare "per_cpu" data in special 
per_cpu section. Since that section is available during
compilation and linking there is simple 32 relation is used to access 
that data. The problem is that the real space for that data is reserved
in kernel address space and 32 bit offset is not enough to get to this 
reserved space. :(

I am going to make another test of qboot3 disc on monday and if 
everythink is fine - released to public to test on AS4100/AS1200 machines.

Regards,
Sergey.