On 14.11.2008 19:54, Jordan Crouse wrote: > 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 >>>> <[EMAIL PROTECTED]> wrote: >>>> >>>>> Carl-Daniel Hailfinger wrote: >>>>> >>>>>> On 14.11.2008 18:14, [EMAIL PROTECTED] 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.
Yes, I'd like to keep LAR and I'd also like to avoid linker runs on the final LAR. > But I don't think thats what you meant - I think you meant to say that > we should "abandon the stages concept". Abandoning stages won't fix this, unfortunately. The problem is PIC in a LAR. (Okay, if we merged initram into the boot block, it would work, but that would kill the ability to have fallback/normal initram). > 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. I found stages rather useful, but that's only my personal opinion. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
