Re: [U-Boot] [PATCH 0/5] Optimize ARM relocation
Hi Benoît, On Wed, 15 May 2013 01:58:23 +0200 (CEST), Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: Hi Albert, On Tuesday, May 14, 2013 10:16:01 PM, Albert ARIBAUD wrote: On Tue, 14 May 2013 22:02:55 +0200, Albert ARIBAUD albert.u.b...@aribaud.net wrote: *** NOTE: this series applies over the 'Factorize ARM relocate_code instances' series. This series optimizes relocation by ensuring ARM binaries only use one type of relocation record, R_ARM_RELATIVE., then optimizing relocation code accordingly. The only known case where relocation records other than R_ARM_RELATIVE are generated is when a reference is made to a symbol defined in the linker script, e.g. __image_copy_start, __image_copy_end, __rel_dyn_start, __rel_dyn_end, and __dynsym_start. Moving the definition of these symbols from the linker scripts into a C module causes their references' types to become R_ARM_RELATIVE. First, arch/arm/lib/bss.c is replaced by a more generic arch/arm/lib/sections.c where all section symbols will be defined. Second, __image_copy_start and __image_copy_end symbols are moved from linker scripts to arch/arm/lib/sections.c Third, __rel_dyn_start, __rel_dyn_end and __synsym_start are moved from linker scripts into arch/arm/lib/sections.c Fourth, a check is added to the build system to ensure that ELF U-Boot binaries only use R_ARM_RELATIVE records. Last, relocate_code is optimized Hmm, it seems I need to see my work posted on the list to discover how I could have done it better... I just noticed that if ARM binaries only have R_ARM_RELATIVE record types, then all the .dynsym sections can actually be dropped from the binaries. So, if I reorder the series and put patch 5/5 first, then I can eliminate patch 3/5, or more to the point, replace it with one which eliminates all dynsym stuff from linker scripts, further reducing code size. That'll go in V2... Indeed. Correction: if I out patch 4/5, not 5/5 -- 4/5 is the patch that ensures only relative relocations are present, and 5/5 depends on previous patches in the series (at least 1/5 and 2/5). So the new order will be 4/5, 1/5, 2/5, amended 3/5, 5/5. Best regards, Benoît Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] Optimize ARM relocation
*** NOTE: this series applies over the 'Factorize
ARM relocate_code instances' series.
This series optimizes relocation by ensuring ARM
binaries only use one type of relocation record,
R_ARM_RELATIVE., then optimizing relocation code
accordingly.
The only known case where relocation records other
than R_ARM_RELATIVE are generated is when a reference
is made to a symbol defined in the linker script, e.g.
__image_copy_start, __image_copy_end, __rel_dyn_start,
__rel_dyn_end, and __dynsym_start.
Moving the definition of these symbols from the linker
scripts into a C module causes their references' types
to become R_ARM_RELATIVE.
First, arch/arm/lib/bss.c is replaced by a more generic
arch/arm/lib/sections.c where all section symbols will
be defined.
Second, __image_copy_start and __image_copy_end symbols
are moved from linker scripts to arch/arm/lib/sections.c
Third, __rel_dyn_start, __rel_dyn_end and __synsym_start
are moved from linker scripts into arch/arm/lib/sections.c
Fourth, a check is added to the build system to ensure
that ELF U-Boot binaries only use R_ARM_RELATIVE records.
Last, relocate_code is optimized
Albert ARIBAUD (5):
arm: generalize lib/bss.c into lib/sections.c
arm: make __image_copy_{start,end} compiler-generated
arm: make relocation symbols compiler-generated
arm: ensure u-boot only uses relative relocations
arm: optimize relocate_code routine
Makefile |7
arch/arm/config.mk |5 +++
arch/arm/cpu/arm920t/ep93xx/u-boot.lds |6 ++-
arch/arm/cpu/ixp/u-boot.lds| 24 ++--
arch/arm/cpu/u-boot.lds| 25 ++---
arch/arm/lib/Makefile |2 +-
arch/arm/lib/relocate.S| 64 +---
arch/arm/lib/{bss.c = sections.c} |9 -
board/actux1/u-boot.lds| 24 ++--
board/actux2/u-boot.lds| 24 ++--
board/actux3/u-boot.lds| 24 ++--
board/dvlhost/u-boot.lds | 24 ++--
board/freescale/mx31ads/u-boot.lds | 24 ++--
13 files changed, 183 insertions(+), 79 deletions(-)
rename arch/arm/lib/{bss.c = sections.c} (77%)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Optimize ARM relocation
On Tue, 14 May 2013 22:02:55 +0200, Albert ARIBAUD albert.u.b...@aribaud.net wrote: *** NOTE: this series applies over the 'Factorize ARM relocate_code instances' series. This series optimizes relocation by ensuring ARM binaries only use one type of relocation record, R_ARM_RELATIVE., then optimizing relocation code accordingly. The only known case where relocation records other than R_ARM_RELATIVE are generated is when a reference is made to a symbol defined in the linker script, e.g. __image_copy_start, __image_copy_end, __rel_dyn_start, __rel_dyn_end, and __dynsym_start. Moving the definition of these symbols from the linker scripts into a C module causes their references' types to become R_ARM_RELATIVE. First, arch/arm/lib/bss.c is replaced by a more generic arch/arm/lib/sections.c where all section symbols will be defined. Second, __image_copy_start and __image_copy_end symbols are moved from linker scripts to arch/arm/lib/sections.c Third, __rel_dyn_start, __rel_dyn_end and __synsym_start are moved from linker scripts into arch/arm/lib/sections.c Fourth, a check is added to the build system to ensure that ELF U-Boot binaries only use R_ARM_RELATIVE records. Last, relocate_code is optimized Hmm, it seems I need to see my work posted on the list to discover how I could have done it better... I just noticed that if ARM binaries only have R_ARM_RELATIVE record types, then all the .dynsym sections can actually be dropped from the binaries. So, if I reorder the series and put patch 5/5 first, then I can eliminate patch 3/5, or more to the point, replace it with one which eliminates all dynsym stuff from linker scripts, further reducing code size. That'll go in V2... Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Optimize ARM relocation
Hi Albert, On Tuesday, May 14, 2013 10:16:01 PM, Albert ARIBAUD wrote: On Tue, 14 May 2013 22:02:55 +0200, Albert ARIBAUD albert.u.b...@aribaud.net wrote: *** NOTE: this series applies over the 'Factorize ARM relocate_code instances' series. This series optimizes relocation by ensuring ARM binaries only use one type of relocation record, R_ARM_RELATIVE., then optimizing relocation code accordingly. The only known case where relocation records other than R_ARM_RELATIVE are generated is when a reference is made to a symbol defined in the linker script, e.g. __image_copy_start, __image_copy_end, __rel_dyn_start, __rel_dyn_end, and __dynsym_start. Moving the definition of these symbols from the linker scripts into a C module causes their references' types to become R_ARM_RELATIVE. First, arch/arm/lib/bss.c is replaced by a more generic arch/arm/lib/sections.c where all section symbols will be defined. Second, __image_copy_start and __image_copy_end symbols are moved from linker scripts to arch/arm/lib/sections.c Third, __rel_dyn_start, __rel_dyn_end and __synsym_start are moved from linker scripts into arch/arm/lib/sections.c Fourth, a check is added to the build system to ensure that ELF U-Boot binaries only use R_ARM_RELATIVE records. Last, relocate_code is optimized Hmm, it seems I need to see my work posted on the list to discover how I could have done it better... I just noticed that if ARM binaries only have R_ARM_RELATIVE record types, then all the .dynsym sections can actually be dropped from the binaries. So, if I reorder the series and put patch 5/5 first, then I can eliminate patch 3/5, or more to the point, replace it with one which eliminates all dynsym stuff from linker scripts, further reducing code size. That'll go in V2... Indeed. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
