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

[Jordan Crouse]

Carl-Daniel Hailfinger wrote:
> 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.

Fully agreed.  If we run a linker over the final LAR archive, then we 
will need a way to run the linker every single time the LAR has changed 
(including, mind you, on target, if we are going to go for the "replace 
stages on the fly" thing).  Does not sound appetizing at all.  I also 
don't like abandoning LAR - it is useful for payloads and such.  But I 
don't think thats what you meant - I think you meant to say that we 
should "abandon the stages concept".  And you know what - with all due 
respect to Ron, I tend to be in favor of that option.  Stages continue 
to be rather painful.  Just one guy's opinion.

Jordan