Hi, On Wed, Sep 22, 2010 at 11:48 AM, Wolfgang Denk <w...@denx.de> wrote:
[...] >> Because U-Boot doesn't build PIC for ARM (I notice it does for some >> other arches). > You are referring to old code. John explitly mentioned that he was > working on the "next" branch, which has this: > > # needed for relocation > PLATFORM_RELFLAGS += -fPIC Ah! Apologies, I missed that... looks like I'm out of date on some assumptions. This tells the compiler to generate PIC code, but it doesn't tell the linker to generate PIC output... which matters if the linker needs to add extra code during the link. Two solutions come to mind: a) In order for linker-added stuff to be PIC, you could link with -shared. This will definitely PIC-ify any veneers added by the linker and push related relocations into the GOT. Strictly speaking it might be wrong not to do this if you expect the output from the linker to be fully PIC -- if so, this may apply to all arches where the linker may generate code. Naturally, it's necessary to ensure that the U-Boot ELF image doesn't accidentally get linked against any shared libs. Checking for DT_NEEDED entries in the u-boot ELF image would be a way to sanity-check this, but the way the U-Boot drives the link looks pretty safe (no -l options; explicit references to .a libs only etc.) b) For ARM specifically, there is also a --pic-veneer option which may also Do The Right Thing in the specific case of these veneers, even when not using ld -shared. Again, I don't know precisely which toolchain versions support this; if we want to be really safe it may be necessary to probe for support for this option at configure-time. --use-blx is probably still a good idea in either case, but this is more about optimisation than correctness. The optimisation is probably still worthwhile though, if it might speed up calls into libgcc. Cheers ---Dave _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
