[coreboot] r1026 - in coreboot-v3: mainboard/kontron/986lcd-m southbridge/intel/i82801gx

[Carl-Daniel Hailfinger]

On 14.11.2008 19:06, Stefan Reinauer wrote:
> ron minnich wrote:
>   
>> On Fri, Nov 14, 2008 at 9:53 AM, Stefan Reinauer <stepan at coresystems.de> wrote:
>>   
>>     
>>> Carl-Daniel Hailfinger wrote:
>>>     
>>>       
>>>> On 14.11.2008 18:14, svn at coreboot.org wrote:
>>>>
>>>>       
>>>>         
>>>>> Author: rminnich
>>>>> New Revision: 1026
>>>>>
>>>>> /home/rminnich/coreboot-v3/build/coreboot.initram_partiallylinked.o: section .data.rel.ro.local: dual_channel_slew_group_lookup.3242 single_channel_slew_group_lookup.3243
>>>>>         
>>>>>           
>>>> Basic rule: If you want to have arrays of pointers in initram, you lose.
>>>> Pointers are not relocatable by definition. const is not going to help
>>>> you there.
>>>>       
>>>>         
>>> Hm. This is bad. 'nother regression in v3 that wasn't in v2.
>>>     
>>>       
>> it's not acceptable as a rule. We have to fix it one way or another.
>> Why gcc is marking it as writeable is a puzzle but points to a bug
>> somewhere.
>>
>>     
> We could try and use indices instead of pointers. That's the easiest
> rewrite i can think of to get the problem done without wasting the code.
>
> This is clearly a gcc weakness. This stuff should not happen when
> compiling PIC. That's what PIC is for.
>   

We're missing one crucial piece which is necessary to get PIC to work:
The linker. PIC code must be linked _after_ its location is known. That
means a linker would have to pass over the final LAR archive. Right now,
we circumvent that requirement by using early linker tricks and by
prohibiting the use of arrays of pointers.

If we insist on using arrays of pointers, we must either run a linker
over the final LAR archive or abandon LAR completely and go for v2
linker magic.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/