Hi Albert, On 05/14/2013 05:44 PM, Albert ARIBAUD wrote: > Hi Michal, > > On Mon, 13 May 2013 09:45:12 +0200, Michal Simek <[email protected]> > wrote: > >> On 05/10/2013 09:07 PM, Albert ARIBAUD wrote: >>> Hi Michal, >>> >>> On Thu, 9 May 2013 11:35:33 +0200, Michal Simek >>> <[email protected]> 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 <[email protected]> >>>> Signed-off-by: Michal Simek <[email protected]> >>>> --- >>>> 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.
Any update on this? Have you decided to add or not to add to this release? If you I need to fix zynq timer code do not use exception handling table. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
