From mboxrd@z Thu Jan 1 00:00:00 1970 From: Georges Savoundararadj Date: Thu, 25 Sep 2014 22:11:09 +0200 Subject: [U-Boot] [PATCH 1/3] arm: make .vectors section allocatable In-Reply-To: References: <1411335230-26907-1-git-send-email-savoundg@gmail.com> <1411335230-26907-2-git-send-email-savoundg@gmail.com> Message-ID: <542476DD.8030609@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > 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 >> --- >> 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,