[U-Boot] Relocation size penalty calculation
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?
Regards,
Graeme
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:
1) Top of mainline on XPedite5370: text data bss dec hex filename 308612 24488 33172 366272 596c0 u-boot
2) Top of "reloc" branch on XPedite5370 (ie -mrelocatable): text data bss dec hex filename 303704 28644 33156 365504 593c0 u-boot
For fun: 3) #2 but with s/-mrelocatable/-fpic/ (probably doesn't boot): text data bss dec hex filename 303704 24472 33156 361332 58374 u-boot
There may be some other changes that affect the size between mainline and "reloc", but their sizes are in the same general ballpark.
Best, Peter
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? And both cases (1 and 2) work equivalently?
Best Regards, Bill Campbell.
For fun: 3) #2 but with s/-mrelocatable/-fpic/ (probably doesn't boot): text data bss dec hex filename 303704 24472 33156 361332 58374 u-boot
There may be some other changes that affect the size between mainline and "reloc", but their sizes are in the same general ballpark.
Best, Peter
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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: 1) Top of mainline: text data bss dec hex filename 219968 17052 22992 260012 3f7ac u-boot
2) 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.
Best, Peter
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
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
Hi Graeme, I would be interested in a third option (column), the x86 build with just -mrelocateable but NOT -fpic. It will not be definitive because there will be extra code that references the GOT and missing code to do some of the relocation, but it would still be interesting.
Best Regards, Bill Campbell
Have any metrics been done for PPC?
Regards,
Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
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
Hi Graeme, I would be interested in a third option (column), the x86 build with just -mrelocateable but NOT -fpic. It will not be definitive because there will be extra code that references the GOT and missing code to do some of the relocation, but it would still be interesting.
x86 does not have -mrelocatable. This is a PPC only option :(
Best Regards, Bill Campbell
Have any metrics been done for PPC?
Regards,
Graeme
Once the reloc branch has been merged, how many arches are left which do not support relocation?
Regards,
Graeme
Dear Graeme Russ,
In message d66caabb0910081358h5b013922tf7f9dce4cce41c64@mail.gmail.com you wrote:
Once the reloc branch has been merged, how many arches are left which do not support relocation?
All but PPC ?
Best regards,
Wolfgang Denk
On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk wd@denx.de wrote:
Dear Graeme Russ,
In message d66caabb0910081358h5b013922tf7f9dce4cce41c64@mail.gmail.com you wrote:
Once the reloc branch has been merged, how many arches are left which do not support relocation?
All but PPC ?
Hmm, so commit 0630535e2d062dd73c1ceca5c6125c86d1127a49 is all about removing code that is not used because these arches do not do any relocation at all?
So ultimately, what we are looking at is the complete and utter removal of any code which references a relocation adjustment in lieu of each arch either:
a) Execute in Place from Flash, or; b) Setting a fixed TEXT_BASE at a known RAM location and copying the contents of Flash to RAM, or; c) Implementing full Relocation
Best regards,
Wolfgang Denk
Regards,
Graeme
On Fri, 2009-10-09 at 09:02 +1100, Graeme Russ wrote:
On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk wd@denx.de wrote:
Dear Graeme Russ,
In message d66caabb0910081358h5b013922tf7f9dce4cce41c64@mail.gmail.com you wrote:
Once the reloc branch has been merged, how many arches are left which do not support relocation?
All but PPC ?
Hmm, so commit 0630535e2d062dd73c1ceca5c6125c86d1127a49 is all about removing code that is not used because these arches do not do any relocation at all?
I sent that patch/RFC after noticing none of those architectures performed manual relocation fixups, thus they could save some code space by defining CONFIG_RELOC_FIXUP_WORKS. Similarly the gd->reloc_off field was no longer needed for them.
I'm not familiar with if or how those architectures are relocating, just that they didn't need relocation fixups. So that was the logic...
So ultimately, what we are looking at is the complete and utter removal of any code which references a relocation adjustment in lieu of each arch either:
a) Execute in Place from Flash, or; b) Setting a fixed TEXT_BASE at a known RAM location and copying the contents of Flash to RAM, or; c) Implementing full Relocation
d) Leaving those architectures the way they are now Could be added if a,b,c won't work for some reason too.
I think it would be great to remove any manual relocation adjustments in the long run. This isn't strictly necessary though, as we can still have manual relocations littering the code - its just a bit dirty and prone to issues in the long run.
So my vote would be to shoot for c) for all arches, but I have no idea what impact that would have on them:)
Best, Peter
On Thursday 08 October 2009 18:20:18 Peter Tyser wrote:
On Fri, 2009-10-09 at 09:02 +1100, Graeme Russ wrote:
On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk wd@denx.de wrote:
Graeme Russ wrote:
Once the reloc branch has been merged, how many arches are left which do not support relocation?
All but PPC ?
Hmm, so commit 0630535e2d062dd73c1ceca5c6125c86d1127a49 is all about removing code that is not used because these arches do not do any relocation at all?
I sent that patch/RFC after noticing none of those architectures performed manual relocation fixups, thus they could save some code space by defining CONFIG_RELOC_FIXUP_WORKS. Similarly the gd->reloc_off field was no longer needed for them.
I'm not familiar with if or how those architectures are relocating, just that they didn't need relocation fixups. So that was the logic...
the usage in the Blackfin port is most likely a copy & paste of existing code. deleting malloc_bin_reloc() from lib_blackfin/board.c and adding CONFIG_RELOC_FIXUP_WORKS results in a working boot. ive never really looked into relocation as no one has asked for it. -mike
On Fri, Oct 9, 2009 at 9:20 AM, Peter Tyser ptyser@xes-inc.com wrote:
On Fri, 2009-10-09 at 09:02 +1100, Graeme Russ wrote:
On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk wd@denx.de wrote:
Dear Graeme Russ,
In message d66caabb0910081358h5b013922tf7f9dce4cce41c64@mail.gmail.com you wrote:
Once the reloc branch has been merged, how many arches are left which do not support relocation?
All but PPC ?
Hmm, so commit 0630535e2d062dd73c1ceca5c6125c86d1127a49 is all about removing code that is not used because these arches do not do any relocation at all?
I sent that patch/RFC after noticing none of those architectures performed manual relocation fixups, thus they could save some code space by defining CONFIG_RELOC_FIXUP_WORKS. Similarly the gd->reloc_off field was no longer needed for them.
Maybe CONFIG_RELOC_NOT_IMPLEMENTED would be more descriptive
I'm not familiar with if or how those architectures are relocating, just that they didn't need relocation fixups. So that was the logic...
So ultimately, what we are looking at is the complete and utter removal of any code which references a relocation adjustment in lieu of each arch either:
a) Execute in Place from Flash, or; b) Setting a fixed TEXT_BASE at a known RAM location and copying the contents of Flash to RAM, or; c) Implementing full Relocation
d) Leaving those architectures the way they are now Could be added if a,b,c won't work for some reason too.
Which is essentially either a) or b) depending on which way the arch was implemented. For x86, it has been b) but it is going towards c)
I think it would be great to remove any manual relocation adjustments in the long run. This isn't strictly necessary though, as we can still have manual relocations littering the code - its just a bit dirty and prone to issues in the long run.
So my vote would be to shoot for c) for all arches, but I have no idea what impact that would have on them:)
So the big question now is - How many arches do partial relocation and really need gd->reloc_off
Best, Peter
Regards,
Graeme
Graeme Russ wrote:
On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
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
Hi Graeme, I would be interested in a third option (column), the x86 build with just -mrelocateable but NOT -fpic. It will not be definitive because there will be extra code that references the GOT and missing code to do some of the relocation, but it would still be interesting.
x86 does not have -mrelocatable. This is a PPC only option :(
Hi Graeme, You are unfortunately correct. However, I wonder if we can get essentially the same result by executing the final ld step with the --emit-relocs switch included. This may also include some "extra" sections that we would want to strip out, but if it works, it could give all ELF-based systems a way to a relocatable u-boot.
Best Regards, Bill Campbell **
Best Regards, Bill Campbell
Have any metrics been done for PPC?
Regards,
Graeme
Once the reloc branch has been merged, how many arches are left which do not support relocation?
Regards,
Graeme
On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
Graeme Russ wrote:
On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
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
Hi Graeme, I would be interested in a third option (column), the x86 build with just -mrelocateable but NOT -fpic. It will not be definitive because there will be extra code that references the GOT and missing code to do some of the relocation, but it would still be interesting.
x86 does not have -mrelocatable. This is a PPC only option :(
Hi Graeme, You are unfortunately correct. However, I wonder if we can get essentially the same result by executing the final ld step with the --emit-relocs switch included. This may also include some "extra" sections that we would want to strip out, but if it works, it could give all ELF-based systems a way to a relocatable u-boot.
I don't think --emit-relocs is necessary with -pic. I haven't gone through all the permutations to see if there is a smaller option, but gcc -fpic and ld -pie creates enough information to perform relocation on the x86 platform
Regards,
Graeme
Best Regards, Bill Campbell **
Best Regards, Bill Campbell
Have any metrics been done for PPC?
Regards,
Graeme
Once the reloc branch has been merged, how many arches are left which do not support relocation?
Regards,
Graeme
On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
Graeme Russ wrote:
On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
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
Hi Graeme, I would be interested in a third option (column), the x86 build with just -mrelocateable but NOT -fpic. It will not be definitive because there will be extra code that references the GOT and missing code to do some of the relocation, but it would still be interesting.
x86 does not have -mrelocatable. This is a PPC only option :(
Hi Graeme, You are unfortunately correct. However, I wonder if we can get essentially the same result by executing the final ld step with the --emit-relocs switch included. This may also include some "extra" sections that we would want to strip out, but if it works, it could give all ELF-based systems a way to a relocatable u-boot.
I don't think --emit-relocs is necessary with -pic. I haven't gone through all the permutations to see if there is a smaller option, but gcc -fpic and ld -pie creates enough information to perform relocation on the x86 platform
Try -fvisibility=hidden
Jocke
Joakim Tjernlund wrote:
On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
Graeme Russ wrote:
On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
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
Hi Graeme, I would be interested in a third option (column), the x86 build with just -mrelocateable but NOT -fpic. It will not be definitive because there will be extra code that references the GOT and missing code to do some of the relocation, but it would still be interesting.
x86 does not have -mrelocatable. This is a PPC only option :(
Hi Graeme, You are unfortunately correct. However, I wonder if we can get essentially the same result by executing the final ld step with the --emit-relocs switch included. This may also include some "extra" sections that we would want to strip out, but if it works, it could give all ELF-based systems a way to a relocatable u-boot.
I don't think --emit-relocs is necessary with -pic. I haven't gone through all the permutations to see if there is a smaller option, but gcc -fpic and ld -pie creates enough information to perform relocation on the x86 platform
It is true that --emit-relocs is not required when -pic and -pie are used instead. However, pic and pie are designed to allow shared code (libraries) to appear at different logical addresses in several programs without altering the text. This is grand overkill for what we need, which is the ability to relocate the code. The -pic and -pie code will be larger than the code without pic and pie. How much larger is a good question. On the PPC, it is larger but not much larger, because there are lots of registers available and one is almost for sure got (no pun intended) the magic relocation constant(s) in it. On the 386 with many fewer registers, pic and pie will cause the code to be percentage-wise larger than on the PPC. Thus avoiding pic and pie is a Good Thing in most cases.
Try -fvisibility=hidden
I assume the -fvisibility=hidden is suggested in order to reduce (eliminate) the symbol table from the output, which we don't need because there are assumed to be no undefined symbols in our final ld. If that works, great! I was assuming we might need a custom "strip" program to delete any sections that we don't need, but this sounds easier if it gets them all.
Best Regards, Bill Campbell
Jocke
On Fri, Oct 9, 2009 at 10:12 AM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
Graeme Russ wrote:
On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
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
Hi Graeme, I would be interested in a third option (column), the x86 build with just -mrelocateable but NOT -fpic. It will not be definitive because there will be extra code that references the GOT and missing code to do some of the relocation, but it would still be interesting.
x86 does not have -mrelocatable. This is a PPC only option :(
Hi Graeme, You are unfortunately correct. However, I wonder if we can get essentially the same result by executing the final ld step with the --emit-relocs switch included. This may also include some "extra" sections that we would want to strip out, but if it works, it could give all ELF-based systems a way to a relocatable u-boot.
I don't think --emit-relocs is necessary with -pic. I haven't gone through all the permutations to see if there is a smaller option, but gcc -fpic and ld -pie creates enough information to perform relocation on the x86 platform
Try -fvisibility=hidden
Thanks - Shaved another 2539 bytes off the binary
Also found out how to get rid of .eh_frame (crept in when I upgraded to gcc 4.4.1) with -fno-dwarf2-cfi-asm, so that shaves another 13452 bytes
Total saving of 15.6k
Jocke
Regards,
Graeme
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 06:43:52:
On Fri, Oct 9, 2009 at 10:12 AM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
Graeme Russ wrote:
On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
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 > >
Hi Graeme, I would be interested in a third option (column), the x86 build with just -mrelocateable but NOT -fpic. It will not be definitive because there will be extra code that references the GOT and missing code to do some of the relocation, but it would still be interesting.
x86 does not have -mrelocatable. This is a PPC only option :(
Hi Graeme, You are unfortunately correct. However, I wonder if we can get essentially the same result by executing the final ld step with the --emit-relocs switch included. This may also include some "extra" sections that we would want to strip out, but if it works, it could give all ELF-based systems a way to a relocatable u-boot.
I don't think --emit-relocs is necessary with -pic. I haven't gone through all the permutations to see if there is a smaller option, but gcc -fpic and ld -pie creates enough information to perform relocation on the x86 platform
Try -fvisibility=hidden
Thanks - Shaved another 2539 bytes off the binary
Also found out how to get rid of .eh_frame (crept in when I upgraded to gcc 4.4.1) with -fno-dwarf2-cfi-asm, so that shaves another 13452 bytes
Total saving of 15.6k
Great, so now you are back at just a few percent added I guess?
On Sat, Oct 10, 2009 at 7:07 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 06:43:52:
On Fri, Oct 9, 2009 at 10:12 AM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
Graeme Russ wrote:
On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
> > 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 >> >> > > Hi Graeme, > I would be interested in a third option (column), the x86 build with > just -mrelocateable but NOT -fpic. It will not be definitive because > there > will be extra code that references the GOT and missing code to do some of > the relocation, but it would still be interesting. >
x86 does not have -mrelocatable. This is a PPC only option :(
Hi Graeme, You are unfortunately correct. However, I wonder if we can get essentially the same result by executing the final ld step with the --emit-relocs switch included. This may also include some "extra" sections that we would want to strip out, but if it works, it could give all ELF-based systems a way to a relocatable u-boot.
I don't think --emit-relocs is necessary with -pic. I haven't gone through all the permutations to see if there is a smaller option, but gcc -fpic and ld -pie creates enough information to perform relocation on the x86 platform
Try -fvisibility=hidden
Thanks - Shaved another 2539 bytes off the binary
Also found out how to get rid of .eh_frame (crept in when I upgraded to gcc 4.4.1) with -fno-dwarf2-cfi-asm, so that shaves another 13452 bytes
Total saving of 15.6k
Great, so now you are back at just a few percent added I guess?
Not really - The .eh_frame saving applies to both relocated and non relocated builds
Regards,
Graeme
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 10:46:52:
On Sat, Oct 10, 2009 at 7:07 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 06:43:52:
On Fri, Oct 9, 2009 at 10:12 AM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
Graeme Russ wrote: > > On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell > jwilliamcampbell@comcast.net wrote: > >> >> 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 >>> >>> >> >> Hi Graeme, >> I would be interested in a third option (column), the x86 build with >> just -mrelocateable but NOT -fpic. It will not be definitive because >> there >> will be extra code that references the GOT and missing code to do some of >> the relocation, but it would still be interesting. >> > > x86 does not have -mrelocatable. This is a PPC only option :( >
Hi Graeme, You are unfortunately correct. However, I wonder if we can get essentially the same result by executing the final ld step with the --emit-relocs switch included. This may also include some "extra" sections that we would want to strip out, but if it works, it could give all ELF-based systems a way to a relocatable u-boot.
I don't think --emit-relocs is necessary with -pic. I haven't gone through all the permutations to see if there is a smaller option, but gcc -fpic and ld -pie creates enough information to perform relocation on the x86 platform
Try -fvisibility=hidden
Thanks - Shaved another 2539 bytes off the binary
Also found out how to get rid of .eh_frame (crept in when I upgraded to gcc 4.4.1) with -fno-dwarf2-cfi-asm, so that shaves another 13452 bytes
Total saving of 15.6k
Great, so now you are back at just a few percent added I guess?
Not really - The .eh_frame saving applies to both relocated and non relocated builds
OK, so you didn't use PIC before at all?
Anyway I think you can do more. Using -Bsymbolic you should get away with RELATIVE relocs only and be able to skip a lot of segments above. Have a look at uClibc ldso/ldso/dl-startup.c
On Sat, Oct 10, 2009 at 8:27 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 10:46:52:
On Sat, Oct 10, 2009 at 7:07 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 06:43:52:
On Fri, Oct 9, 2009 at 10:12 AM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell jwilliamcampbell@comcast.net wrote: > Graeme Russ wrote: >> >> On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell >> jwilliamcampbell@comcast.net wrote: >> >>> >>> 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 >>>> >>>> >>> >>> Hi Graeme, >>> I would be interested in a third option (column), the x86 build with >>> just -mrelocateable but NOT -fpic. It will not be definitive because >>> there >>> will be extra code that references the GOT and missing code to do some of >>> the relocation, but it would still be interesting. >>> >> >> x86 does not have -mrelocatable. This is a PPC only option :( >> > > Hi Graeme, > You are unfortunately correct. However, I wonder if we can get > essentially the same result by executing the final ld step with the > --emit-relocs switch included. This may also include some "extra" sections > that we would want to strip out, but if it works, it could give all > ELF-based systems a way to a relocatable u-boot. >
I don't think --emit-relocs is necessary with -pic. I haven't gone through all the permutations to see if there is a smaller option, but gcc -fpic and ld -pie creates enough information to perform relocation on the x86 platform
Try -fvisibility=hidden
Thanks - Shaved another 2539 bytes off the binary
Also found out how to get rid of .eh_frame (crept in when I upgraded to gcc 4.4.1) with -fno-dwarf2-cfi-asm, so that shaves another 13452 bytes
Total saving of 15.6k
Great, so now you are back at just a few percent added I guess?
Not really - The .eh_frame saving applies to both relocated and non relocated builds
OK, so you didn't use PIC before at all?
Anyway I think you can do more. Using -Bsymbolic you should get away with RELATIVE relocs only and be able to skip a lot of segments above. Have a look at uClibc ldso/ldso/dl-startup.c
My build options thus far are:
PLATFORM_RELFLAGS += -fpie -fvisibility=hidden PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm PLATFORM_LDFLAGS += -pie
-fpic / -pic make no difference
Interestingly, -Bsymbolic adds exactly 8 bytes to .dynamic, but doesn't change the size of any other section
Pulling apart the relocation sections, it seems that all relocations are already RELATIVE even without -Bsymbolic
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 12:38:19:
On Sat, Oct 10, 2009 at 8:27 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 10:46:52:
On Sat, Oct 10, 2009 at 7:07 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 06:43:52:
On Fri, Oct 9, 2009 at 10:12 AM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
> > On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell > jwilliamcampbell@comcast.net wrote: > > Graeme Russ wrote: > >> > >> On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell > >> jwilliamcampbell@comcast.net wrote: > >> > >>> > >>> 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 > >>>> > >>>> > >>> > >>> Hi Graeme, > >>> I would be interested in a third option (column), the x86 build with > >>> just -mrelocateable but NOT -fpic. It will not be definitive because > >>> there > >>> will be extra code that references the GOT and missing code to do some of > >>> the relocation, but it would still be interesting. > >>> > >> > >> x86 does not have -mrelocatable. This is a PPC only option :( > >> > > > > Hi Graeme, > > You are unfortunately correct. However, I wonder if we can get > > essentially the same result by executing the final ld step with the > > --emit-relocs switch included. This may also include some "extra" sections > > that we would want to strip out, but if it works, it could give all > > ELF-based systems a way to a relocatable u-boot. > > > > I don't think --emit-relocs is necessary with -pic. I haven't gone through > all the permutations to see if there is a smaller option, but gcc -fpic and > ld -pie creates enough information to perform relocation on the x86 > platform
Try -fvisibility=hidden
Thanks - Shaved another 2539 bytes off the binary
Also found out how to get rid of .eh_frame (crept in when I upgraded to gcc 4.4.1) with -fno-dwarf2-cfi-asm, so that shaves another 13452 bytes
Total saving of 15.6k
Great, so now you are back at just a few percent added I guess?
Not really - The .eh_frame saving applies to both relocated and non relocated builds
OK, so you didn't use PIC before at all?
Anyway I think you can do more. Using -Bsymbolic you should get away with RELATIVE relocs only and be able to skip a lot of segments above. Have a look at uClibc ldso/ldso/dl-startup.c
My build options thus far are:
PLATFORM_RELFLAGS += -fpie -fvisibility=hidden PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm PLATFORM_LDFLAGS += -pie
-fpic / -pic make no difference
not on x86, on ppc it is a big difference.
Interestingly, -Bsymbolic adds exactly 8 bytes to .dynamic, but doesn't change the size of any other section
Pulling apart the relocation sections, it seems that all relocations are already RELATIVE even without -Bsymbolic
Ah, that is because you built an exe with -pie Then you should be able to drop everything but the RELATIVE from the linking, or almost in any case.
Jocke
On Sat, Oct 10, 2009 at 9:47 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 12:38:19:
On Sat, Oct 10, 2009 at 8:27 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 10:46:52:
On Sat, Oct 10, 2009 at 7:07 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 06:43:52:
On Fri, Oct 9, 2009 at 10:12 AM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote: >> >> On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell >> jwilliamcampbell@comcast.net wrote: >> > Graeme Russ wrote: >> >> >> >> On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell >> >> jwilliamcampbell@comcast.net wrote: >> >> >> >>> >> >>> 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 >> >>>> >> >>>> >> >>> >> >>> Hi Graeme, >> >>> I would be interested in a third option (column), the x86 build with >> >>> just -mrelocateable but NOT -fpic. It will not be definitive because >> >>> there >> >>> will be extra code that references the GOT and missing code to do some of >> >>> the relocation, but it would still be interesting. >> >>> >> >> >> >> x86 does not have -mrelocatable. This is a PPC only option :( >> >> >> > >> > Hi Graeme, >> > You are unfortunately correct. However, I wonder if we can get >> > essentially the same result by executing the final ld step with the >> > --emit-relocs switch included. This may also include some "extra" sections >> > that we would want to strip out, but if it works, it could give all >> > ELF-based systems a way to a relocatable u-boot. >> > >> >> I don't think --emit-relocs is necessary with -pic. I haven't gone through >> all the permutations to see if there is a smaller option, but gcc -fpic and >> ld -pie creates enough information to perform relocation on the x86 >> platform > > Try -fvisibility=hidden
Thanks - Shaved another 2539 bytes off the binary
Also found out how to get rid of .eh_frame (crept in when I upgraded to gcc 4.4.1) with -fno-dwarf2-cfi-asm, so that shaves another 13452 bytes
Total saving of 15.6k
Great, so now you are back at just a few percent added I guess?
Not really - The .eh_frame saving applies to both relocated and non relocated builds
OK, so you didn't use PIC before at all?
Anyway I think you can do more. Using -Bsymbolic you should get away with RELATIVE relocs only and be able to skip a lot of segments above. Have a look at uClibc ldso/ldso/dl-startup.c
My build options thus far are:
PLATFORM_RELFLAGS += -fpie -fvisibility=hidden PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm PLATFORM_LDFLAGS += -pie
-fpic / -pic make no difference
not on x86, on ppc it is a big difference.
Interestingly, -Bsymbolic adds exactly 8 bytes to .dynamic, but doesn't change the size of any other section
Pulling apart the relocation sections, it seems that all relocations are already RELATIVE even without -Bsymbolic
Ah, that is because you built an exe with -pie Then you should be able to drop everything but the RELATIVE from the linking, or almost in any case.
Jocke
Hmm, so its seems I may have hit the limit. I tried:
PLATFORM_LDFLAGS += -r --emit-relocs
but there is not enough information left to complete the relocation. It seems as though I need .rel.got, .got.plt, .dynsym and .rel.dyn in order to find the actual bytes that need modifying (it also seems to mess with the size of the stripped binary for some reason)
Looks like I'll have to proceed with my original plan - a bit bloated, but it works
Graeme
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 13:21:10:
On Sat, Oct 10, 2009 at 9:47 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 12:38:19:
On Sat, Oct 10, 2009 at 8:27 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 10:46:52:
On Sat, Oct 10, 2009 at 7:07 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 06:43:52: > > On Fri, Oct 9, 2009 at 10:12 AM, Joakim Tjernlund > joakim.tjernlund@transmode.se wrote: > >> > >> On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell > >> jwilliamcampbell@comcast.net wrote: > >> > Graeme Russ wrote: > >> >> > >> >> On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell > >> >> jwilliamcampbell@comcast.net wrote: > >> >> > >> >>> > >> >>> 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 > >> >>>> > >> >>>> > >> >>> > >> >>> Hi Graeme, > >> >>> I would be interested in a third option (column), the x86 build with > >> >>> just -mrelocateable but NOT -fpic. It will not be definitive because > >> >>> there > >> >>> will be extra code that references the GOT and missing code todo some of > >> >>> the relocation, but it would still be interesting. > >> >>> > >> >> > >> >> x86 does not have -mrelocatable. This is a PPC only option :( > >> >> > >> > > >> > Hi Graeme, > >> > You are unfortunately correct. However, I wonder if we can get > >> > essentially the same result by executing the final ld step with the > >> > --emit-relocs switch included. This may also include some "extra" sections > >> > that we would want to strip out, but if it works, it could give all > >> > ELF-based systems a way to a relocatable u-boot. > >> > > >> > >> I don't think --emit-relocs is necessary with -pic. I haven't gone through > >> all the permutations to see if there is a smaller option, but gcc -fpic and > >> ld -pie creates enough information to perform relocation on the x86 > >> platform > > > > Try -fvisibility=hidden > > Thanks - Shaved another 2539 bytes off the binary > > Also found out how to get rid of .eh_frame (crept in when I upgraded to > gcc 4.4.1) with -fno-dwarf2-cfi-asm, so that shaves another 13452 bytes > > Total saving of 15.6k
Great, so now you are back at just a few percent added I guess?
Not really - The .eh_frame saving applies to both relocated and non relocated builds
OK, so you didn't use PIC before at all?
Anyway I think you can do more. Using -Bsymbolic you should get away with RELATIVE relocs only and be able to skip a lot of segments above. Have a look at uClibc ldso/ldso/dl-startup.c
My build options thus far are:
PLATFORM_RELFLAGS += -fpie -fvisibility=hidden PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm PLATFORM_LDFLAGS += -pie
-fpic / -pic make no difference
not on x86, on ppc it is a big difference.
Interestingly, -Bsymbolic adds exactly 8 bytes to .dynamic, but doesn't change the size of any other section
Pulling apart the relocation sections, it seems that all relocations are already RELATIVE even without -Bsymbolic
Ah, that is because you built an exe with -pie Then you should be able to drop everything but the RELATIVE from the linking, or almost in any case.
Jocke
Hmm, so its seems I may have hit the limit. I tried:
PLATFORM_LDFLAGS += -r --emit-relocs
but there is not enough information left to complete the relocation. It seems as though I need .rel.got, .got.plt, .dynsym and .rel.dyn in order to find the actual bytes that need modifying (it also seems to mess with the size of the stripped binary for some reason)
Looks like I'll have to proceed with my original plan - a bit bloated, but it works
Relocation costs :(
I am not sure why you need .got.plt, it should be empty, what is in it? Same with dynsym, what is in it?
Memory fails me, but since u-boot is a freestanding app it I think these two might not be needed. Perhaps there are weak unresolved syms in there?
Jocke
On Sun, Oct 11, 2009 at 2:38 AM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 13:21:10:
On Sat, Oct 10, 2009 at 9:47 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 12:38:19:
On Sat, Oct 10, 2009 at 8:27 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 10:46:52:
On Sat, Oct 10, 2009 at 7:07 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote: > Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 06:43:52: >> >> On Fri, Oct 9, 2009 at 10:12 AM, Joakim Tjernlund >> joakim.tjernlund@transmode.se wrote: >> >> >> >> On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell >> >> jwilliamcampbell@comcast.net wrote: >> >> > Graeme Russ wrote: >> >> >> >> >> >> On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell >> >> >> jwilliamcampbell@comcast.net wrote: >> >> >> >> >> >>> >> >> >>> 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 >> >> >>>> >> >> >>>> >> >> >>> >> >> >>> Hi Graeme, >> >> >>> I would be interested in a third option (column), the x86 build with >> >> >>> just -mrelocateable but NOT -fpic. It will not be definitive because >> >> >>> there >> >> >>> will be extra code that references the GOT and missing code todo some of >> >> >>> the relocation, but it would still be interesting. >> >> >>> >> >> >> >> >> >> x86 does not have -mrelocatable. This is a PPC only option :( >> >> >> >> >> > >> >> > Hi Graeme, >> >> > You are unfortunately correct. However, I wonder if we can get >> >> > essentially the same result by executing the final ld step with the >> >> > --emit-relocs switch included. This may also include some "extra" sections >> >> > that we would want to strip out, but if it works, it could give all >> >> > ELF-based systems a way to a relocatable u-boot. >> >> > >> >> >> >> I don't think --emit-relocs is necessary with -pic. I haven't gone through >> >> all the permutations to see if there is a smaller option, but gcc -fpic and >> >> ld -pie creates enough information to perform relocation on the x86 >> >> platform >> > >> > Try -fvisibility=hidden >> >> Thanks - Shaved another 2539 bytes off the binary >> >> Also found out how to get rid of .eh_frame (crept in when I upgraded to >> gcc 4.4.1) with -fno-dwarf2-cfi-asm, so that shaves another 13452 bytes >> >> Total saving of 15.6k > > Great, so now you are back at just a few percent added I guess? > >
Not really - The .eh_frame saving applies to both relocated and non relocated builds
OK, so you didn't use PIC before at all?
Anyway I think you can do more. Using -Bsymbolic you should get away with RELATIVE relocs only and be able to skip a lot of segments above. Have a look at uClibc ldso/ldso/dl-startup.c
My build options thus far are:
PLATFORM_RELFLAGS += -fpie -fvisibility=hidden PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm PLATFORM_LDFLAGS += -pie
-fpic / -pic make no difference
not on x86, on ppc it is a big difference.
Interestingly, -Bsymbolic adds exactly 8 bytes to .dynamic, but doesn't change the size of any other section
Pulling apart the relocation sections, it seems that all relocations are already RELATIVE even without -Bsymbolic
Ah, that is because you built an exe with -pie Then you should be able to drop everything but the RELATIVE from the linking, or almost in any case.
Jocke
Hmm, so its seems I may have hit the limit. I tried:
PLATFORM_LDFLAGS += -r --emit-relocs
but there is not enough information left to complete the relocation. It seems as though I need .rel.got, .got.plt, .dynsym and .rel.dyn in order to find the actual bytes that need modifying (it also seems to mess with the size of the stripped binary for some reason)
Looks like I'll have to proceed with my original plan - a bit bloated, but it works
Relocation costs :(
I am not sure why you need .got.plt, it should be empty, what is in it? Same with dynsym, what is in it?
Memory fails me, but since u-boot is a freestanding app it I think these two might not be needed. Perhaps there are weak unresolved syms in there?
Jocke
Well, I'm in the middle of a pretty intense analysis of what is going on.
Compile flags are:
PLATFORM_RELFLAGS += -fpic -fvisibility=hidden PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm PLATFORM_LDFLAGS += -pic -Bsymbolic
So far I have found that the only sections that have changes as a result of a change in TEXT_BASE are: .text .rodata .data.rel .got .got.plt .rel.text .rel.got .rel.dyn .dynsym .dynamic .u_boot_cmd
Changes in .text are covered by .rel.text (see below) or as a result of CONFIG_SYS_MONITOR_BASE being equal to TEXT_BASE (used in cfi_flash.c)
Changes in .rodata are a result of version_string changing for each compile
.rel.text - Contains a list of pointers into .got - All entries are R_386_RELATIVE - All entries (8 of) are in cpu/i386/start.o - cpu/i386/start.o only used during initial bootstrap - not needed after execution starts in RAM - Can be safely discarded
.rel.got - Contains a list of pointers into .got - All entries are R_386_RELATIVE - Not all entries change with TEXT_BASE. Some entries are symbols exported from the linker script (in particular section size exports) while the others are in the somewhat 'special' BIOS and Real Mode sections which are located in a fixed RAM location (these sections are used for real-mode trampolining into Linux by providing a limited PC 'BIOS' - All entries that are not linked to TEXT_BASE are easily identified because they are 'located' below TEXT_BASE (specically between 0x00000000 and 0x00001A34) - This section is not needed in the final binary - Direct processing of .got will achieve the required end result
.rel.dyn - Contains a list of pointers into .data.rel and .u_boot_cmd - Like .rel.got, not all entries in .data.rel need relocating. Again, like .rel.got, these are easily identified - This section not needed
Another 5.5k saved
So, all that is left are .dynsym and .dynamic ... .dynsym - Contains 70 entries (16 bytes each, 1120 bytes) - 44 entries mimic those entries in .got which are not relocated - 21 entries are the remaining symbols exported from the linker script - 4 entries are labels defined in inline asm and used in C - 1 entry is a NULL entry
.dynamic - 88 bytes - Array of Elf32_Dyn - typedef struct { Elf32_Sword d_tag; union { Elf32_Word d_val; Elf32_Addr d_ptr; } d_un; } Elf32_Dyn; - 0x11 entries [00] 0x00000010, 0x00000000 DT_SYMBOLIC, (ignored) [01] 0x00000004, 0x38059994 DT_HASH, points to .hash [02] 0x00000005, 0x380595AB DT_STRTAB, points to .dynstr [03] 0x00000006, 0x3805BDCC DT_SYMTAB, points to .dynsym [04] 0x0000000A, 0x000003E6 DT_STRSZ, size of .dynstr [05] 0x0000000B, 0x00000010 DT_SYMENT, ??? [06] 0x00000015, 0x00000000 DT_DEBUG, ??? [07] 0x00000011, 0x3805A8F4 DT_REL, points to .rel.text [08] 0x00000012, 0x000014D8 DT_RELSZ, ??? [09] 0x00000013, 0x00000008 DT_RELENT, ??? [0a] 0x00000016, 0x00000000 DT_TEXTREL, ??? [0b] 0x6FFFFFFA, 0x00000236 ???, Entries in .rel.dyn [0c] 0x00000000, 0x00000000 DT_NULL, End of Array [0d] 0x00000000, 0x00000000 DT_NULL, End of Array [0e] 0x00000000, 0x00000000 DT_NULL, End of Array [0f] 0x00000000, 0x00000000 DT_NULL, End of Array [10] 0x00000000, 0x00000000 DT_NULL, End of Array
I think some more investigation into the need for .dynsym and .dynamic is still required...
Regards,
Graeme
On Saturday 10 October 2009 06:47:42 Joakim Tjernlund wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 12:38:19:
-fpic / -pic make no difference
not on x86, on ppc it is a big difference.
i think you guys mean -fpic and -fPIC because there is no -pic flag ... while the two make a big diff on some arches like ppc, they make pretty much no different on x86 last i looked -mike
Mike Frysinger vapier@gentoo.org wrote on 10/10/2009 18:52:29:
On Saturday 10 October 2009 06:47:42 Joakim Tjernlund wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 12:38:19:
-fpic / -pic make no difference
not on x86, on ppc it is a big difference.
i think you guys mean -fpic and -fPIC because there is no -pic flag ... while the two make a big diff on some arches like ppc, they make pretty much no different on x86 last i looked
Yes, this was what I was thinking(-fpic vs. -fPIC). These will probably only make a difference on RISC like arches.
Jocke
On Sun, Oct 11, 2009 at 4:45 AM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Mike Frysinger vapier@gentoo.org wrote on 10/10/2009 18:52:29:
On Saturday 10 October 2009 06:47:42 Joakim Tjernlund wrote:
Graeme Russ graeme.russ@gmail.com wrote on 10/10/2009 12:38:19:
-fpic / -pic make no difference
not on x86, on ppc it is a big difference.
i think you guys mean -fpic and -fPIC because there is no -pic flag ... while the two make a big diff on some arches like ppc, they make pretty much no different on x86 last i looked
Sorry for the confusion - by -fpic / -pic I was referring to -fpic (gcc) / -pic (ld) flags versus -fpie (gcc) / -pie (ld) flags.
Yes, this was what I was thinking(-fpic vs. -fPIC). These will probably only make a difference on RISC like arches.
There appears to be no difference (on x86) between pic, PIC, and pie. The big difference is when I drop ld's -pic and use ld's --emit-relocs instead
Jocke
Regards,
Graeme
participants (6)
-
Graeme Russ -
J. William Campbell -
Joakim Tjernlund -
Mike Frysinger -
Peter Tyser -
Wolfgang Denk