[U-Boot] [PATCH RFC] armv7: fixloop: don't fixup if location is NULL

[Andreas Bießmann]

Hi Albert,

Am 09.01.2011 um 10:00 schrieb Albert ARIBAUD:

> Hi Andreas,
> 
> Le 08/01/2011 17:51, Andreas Bießmann a écrit :
>> Dear Albert ARIBAUD,
>> 
>> Am 08.01.2011 um 13:18 schrieb Albert ARIBAUD:
>> 
>>> Le 08/01/2011 11:49, Albert ARIBAUD a écrit :
>>> 
>>>>> In my investigations for 'NULL fixup' (->  see
>>>>> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/89864/focus=89906)
>>>>> pointed out that only symbols in 'absolute fixup' loop could be 'NULL'
>>>>> if there is a not aliased/empty weakly linked symbol.
>>> 
>>> BTW: is such a situation normal? IIUC, it means there is a weakly linked symbol without *any* defintion, *and* it is referenced in the code.
>> 
>> Yes you may have a weakly linked symbol which was declared but nowhere
>> implemented. See http://patchwork.ozlabs.org/patch/73647, this fixed such
>> a situation for arm920t/at91 style SoC.
> 
> Not sure I follow you there.

Ok, so I may got you wrong before.

> The example you give has a definition, admittedly for an empty function, right above the weak definition. My question is about cases where the weak symbol is declared and has no definition at all. Were you meaning to give an example of an undefined
> weak symbol being fixed so that it has at least a default definition?

The mentioned patch did define an empty function stub to have a default definition for this case (board_reset()). This fixed two points
 a) the patch sets an address for board_reset() in .dynsym section other than '0' as it was before that patch
 b) the patch fixed an (maybe) linker bug which let the linker segfault if no .plt section was placed in linker script

The real point behind that is the fact that I could never see a '0' in .rel.dyn section's first 4 bytes. But I did see the value '0' in address part of .dynsym section when I did have a undefined weakly linked symbol.

Therefore I doubt the 'armv7: fixloop: don't fixup if location is NULL' patch do something meaningful. My first approach to get my board working was similar to that patch. But further investigation pointed out that it was wrong! In my case the .rel.dyn section got corrupted due to some bss manipulation before bss setup. That corruption did set the address segment of .rel.dyn entry to another value which lead to an aborted write later on (you know the story).

>> BTW: Without the mentioned patch there was another issue with linking
>> (->  see http://patchwork.ozlabs.org/patch/73563). The linker introduced
>> a .plt section which could not be placed and lead to a segfault of linker.
> 
> That's more of a linker bug to me.

Maybe ..

> The plt sections are unused that I know of.

could not find any meaningful definition about that. AFAIR one doc showed some connection to runtime library loading ... Nevertheless the content of .plt section in my case was not really clear to me.

> They could probably be put after BSS and marked NOLOAD -- giving it a try would be a nice thing.

I needed to add .plt to my linker script, did not try NOLOAD til now.

regards

Andreas Bießmann