Peter Tyser wrote:
On Thu, 2009-10-08 at 08:53 -0700, J. William Campbell wrote:
Peter Tyser wrote:
On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote:
Out of curiosity, I wanted to see just how much of a size penalty I am incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are the results (fixed width font will help - its space, not tab, formatted):
Section non-reloc reloc
.text 000118c4 000137fc <- 0x1f38 bytes (~8kB) bigger .rodata 00005bad 000059d0 .interp n/a 00000013 .dynstr n/a 00000648 .hash n/a 00000428 .eh_frame 00003268 000034fc .data 00000a6c 000001dc .data.rel n/a 00000098 .data.rel.ro.local n/a 00000178 .data.rel.local n/a 000007e4 .got 00000000 000001f0 .got.plt n/a 0000000c .rel.got n/a 000003e0 .rel.dyn n/a 00001228 .dynsym n/a 00000850 .dynamic n/a 00000080 .u_boot_cmd 000003c0 000003c0 .bss 00001a34 00001a34 .realmode 00000166 00000166 .bios 0000053e 0000053e ======================================= Total 0001d5dd 00022287 <- 0x4caa bytes (~19kB) bigger
Its more than a 16% increase in size!!!
.text accounts for a little under half of the total bloat, and of that, the crude dynamic loader accounts for only 341 bytes
Have any metrics been done for PPC?
Things actually improve a little bit when we use -mrelocatable and get rid of all the manual "+= gd->reloc_off" fixups:
- Top of mainline on XPedite5370: text data bss dec hex filename
308612 24488 33172 366272 596c0 u-boot
- Top of "reloc" branch on XPedite5370 (ie -mrelocatable): text data bss dec hex filename
303704 28644 33156 365504 593c0 u-boot
Hi Peter, Just to be clear, the total text+data length of u-boot with the "manual" relocations (#1) is LARGER than the text+data length of u-boot with the "manual" relocations removed and the necessary centralized relocation code added, along with any additional data sections required by -mrelocateable (#2), by 768 (dec) bytes?
Hi Bill, Doah, looks like I chose a bad board as an example. The XPedite5370 already had -mrelocatable defined in its own board/xes/xpedite5370/config.mk in mainline, so the above comparison should be ignored as both builds used -mrelocatable.
Here's some *real* results from the MPC8548CDS:
- Top of mainline: text data bss dec hex filename
219968 17052 22992 260012 3f7ac u-boot
- Top of "reloc" branch (ie -mrelocatable) text data bss dec hex filename
219192 20640 22980 262812 4029c u-boot
So the reloc branch is 2.7K bigger for the MPC8548CDS.
Hi Peter, OK, that's more like it! A 1.2 % size increase in ROM seems like a very small price to pay for a truly relocatable u-boot image that will run on any size memory without the programmer having to actively worry about what may need relocating as code is written. . Also, it should be noted that the size increase in 2) is mostly in relocation segments that do not need to be copied into ram, so the ram footprint should be smaller for 2) than 1). The relocation code itself could also be placed is a segment that is not copied into ram, although that may be more trouble than it is worth. I am looking forward to Graeme's results with the 386. I expect that it will not be quite so favorable, perhaps a 4 or 5% size increase for -mrelocatable over an absolute build. However, -mrelocatable vs. -fpic may be comparable, with -mrelocatable actually winning. But then again, I could be totally wrong!
Best Regards, Bill Campbell
Best, Peter