[U-Boot] [PATCH 1/3] arm: make .vectors section allocatable

[Georges Savoundararadj]

Hi Albert,

Le 24/09/2014 09:34, Albert ARIBAUD a écrit :
> Hi Georges,
>
> On Sun, 21 Sep 2014 23:33:48 +0200, Georges Savoundararadj
> <savoundg at gmail.com>  <mailto:savoundg at gmail.com>  wrote:
>
>> Before the commit 41623c91, the exception vector was in a .text
>> section which is allocatable. After this, the .vectors section was
>> introduced to contain the exception vector without specifying it as a
>> .text section but only as a executable section ("x").
>> This fix marks the section .vectors as allocatable as well ("ax") allowing
>> symbols to be relocated.
> Could you explain (on the list, not in the commit message, although I
> might ask you to do it there too later on) the exact effects of adding
> the "a" flag, i.e., what symbol exactly was broken by commit 41623c91,
> how it is broken, and how "a" changes this?
According to [1], the .text section has the attributes allocated and 
executable:
"The attributes used are SHF_ALLOC and SHF_EXECINSTR".

Before commit 41623c91, the exception vectors were not defined in a 
specific section.
For instance, see arch/arm/cpu/arm1176/start.S.
I think, if no specific section type is specified, the symbols will be, 
by default, in a .text section.
It is what we observe thanks to arm-none-eabi-objdump -D 
arch/arm/cpu/arm1176/start.o.

And, we notice that the addresses of the symbols of the exception 
vectors are indeed there:
0003328c <__rel_dyn_end-0x4b00>:
    3328c:       00008020        andeq   r8, r0, r0, lsr #32
    33290:       00000017        andeq   r0, r0, r7, lsl r0
    33294:       00008024        andeq   r8, r0, r4, lsr #32
    33298:       00000017        andeq   r0, r0, r7, lsl r0
    3329c:       00008028        andeq   r8, r0, r8, lsr #32
    332a0:       00000017        andeq   r0, r0, r7, lsl r0
    332a4:       0000802c        andeq   r8, r0, ip, lsr #32
8020 is the address of _undefined_instruction, 8024 of 
_software_interrupt, etc., ...

In commit 41623c91, a specific section is created to contain these 
symbols called .vectors
with the attribute executable (SHF_EXECINSTR or "x").

The symbols of the exception vectors are not referenced in .rel.dyn:
000332ac <__rel_dyn_end-0x4ac8>:
    332ac:       00008538        andeq   r8, r0, r8, lsr r5
    332b0:       00000017        andeq   r0, r0, r7, lsl r0
    332b4:       0000853c        andeq   r8, r0, ip, lsr r5
    332b8:       00000017        andeq   r0, r0, r7, lsl r0
    332bc:       00008540        andeq   r8, r0, r0, asr #10
    332c0:       00000017        andeq   r0, r0, r7, lsl r0
    332c4:       00008548        andeq   r8, r0, r8, asr #10
    332c8:       00000017        andeq   r0, r0, r7, lsl r0
    332cc:       0000854c        andeq   r8, r0, ip, asr #10

What has changed between commit 41623c91^ and 41623c91 is the attribute 
of the section where the exception
vectors are.
If we add the lacking attribute (SHF_ALLOC or "a") for the definition of 
the section .vectors, the problem is solved.
According to [1], a allocatable section is "a section [that] occupies 
memory during process execution" which is
the case of .vectors.

To summarize, the issue is to set the section where the symbols 
_undefined_instruction, _software_interrupt,
_prefetch_abort, _data_abort, _not_used, _irq and _fiq are as 
allocatable because the exception vectors
resides in memory during execution.
If we do not mark it as allocatable, these symbols will no be referenced 
for relocation.

[1] http://man7.org/linux/man-pages/man5/elf.5.html

> On a deeper level, note that many ARM targets around do not have free
> rein on where they can put vectors, e.g., they are limited to base
> addresses of 0x00000000 or 0xFFFF0000. Thus, in many cases, vector are
> relocated along with the rest of the image, but in fact, their base
> address will not be their relocated address, and they will require
> copying into whatever fixed location the target supports.
>
> If you're going to fix general exception handling files (which I am
> quite fine with), I would prefer that you solve the general problem,
> i.e. either relocate vectors along with the code and fix VBAR on
> plaforms that can use it, or relocate them to the fixed location wher
> e the target expects them.
I didn't plan to to do that. But, I am ok to propose you a more general 
patch.

Regards,

Georges

>> Signed-off-by: Georges Savoundararadj<savoundg at gmail.com>  <mailto:savoundg at gmail.com>
>> ---
>>   arch/arm/lib/vectors.S | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S
>> index 0cb87ce..49238ed 100644
>> --- a/arch/arm/lib/vectors.S
>> +++ b/arch/arm/lib/vectors.S
>> @@ -33,7 +33,7 @@
>>    *************************************************************************
>>    */
>>   
>> -	.section ".vectors", "x"
>> +	.section ".vectors", "ax"
>>   
>>   /*
>>    *************************************************************************
> Amicalement,