[U-Boot] [RFC PATCH] arm: lds: Remove libgcc eabi exception handling tables

[Albert ARIBAUD]

Hi Michal,

On Mon, 13 May 2013 09:45:12 +0200, Michal Simek <monstr at monstr.eu>
wrote:

> On 05/10/2013 09:07 PM, Albert ARIBAUD wrote:
> > Hi Michal,
> > 
> > On Thu,  9 May 2013 11:35:33 +0200, Michal Simek
> > <michal.simek at xilinx.com> wrote:
> > 
> >> Remove ARM eabi exception handling tables (for frame unwinding).
> >> AFAICT, u-boot stubs away the frame unwiding routines, so the tables will
> >> more or less just consume space. It should be OK to remove them.
> >>
> >> Signed-off-by: Edgar E. Iglesias <edgar.iglesias at xilinx.com>
> >> Signed-off-by: Michal Simek <michal.simek at xilinx.com>
> >> ---
> >> Other options could be to complete u-boot/arch/arm/lib/* so that
> >> libgcc routines with exception handling dont get pulled in. Or
> >> to avoid user code (like the mentioned patch) which causes external
> >> libgcc functions to get pulled in...
> > 
> > Er... which mentioned patch?
> 
> Ah yeah. Let me give you background.
> After adding:
> "arm: zynq: U-Boot udelay < 1000 FIX"
> (sha1: d54cc007878697a92e7f696b71a3eb203c0386e2)
> 
> we have found that new program header is added to u-boot for zynq.
> 
> Program Header:
> 0x70000001 off    0x000405fc vaddr 0x040385fc paddr 0x040385fc align 2**2
>          filesz 0x00000020 memsz 0x00000020 flags r--
>     LOAD off    0x00008000 vaddr 0x04000000 paddr 0x04000000 align 2**15
>          filesz 0x00041240 memsz 0x00041240 flags rwx
>    STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
>          filesz 0x00000000 memsz 0x00000000 flags rwx
> 
> Tracing down this we found that uldivmod is used
>     27: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __aeabi_uldivmod
> 
> Based on that Edgar proposed this patch.

Ok, so Michal and I just did some fiddling with zynq builds and
*exidx* sections.

By default the *exidx* sections are between rodata and data, so
removing them causes many apparent changes at the binary level.
However, builds of zynq based on ARM master with the patch above vs
master with a patch mapping *exidx* sections after BSS gives identical
binaries. Thus the RFC has no functional effect. 

Also, ARM EHABI states that [exception] Tables are not required for ABI
compliance at the C/Assembler level but are required for C++.

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf

So as long as we don't put any C++ code in U-Boot (a prospect that I
don't see happening any time soon), this RFC is safe and either is a
no-op or removes useless bytes from the binary.

Amicalement,
-- 
Albert.