On Sun, 2011-06-05 at 22:35 -0400, Jon Masters wrote: > The only item up for (some) discussion seems to be use of Thumb2. Builds > so far have been having problems when turning on T2. For various > reasons, I'm not particularly desperate to see us build with T2. A todo > of mine is to confirm that the GCC interworking trampolines mean it > doesn't matter and we can make changes to have some T2 bits later (which > is how I understand that this should be working, but I want to verify by > spending some quality time with objdump and a few compiled libraries). For the record, after re-learning way too much about how the dynamic linker, GOT, PLT, etc. work, and going through a bunch of example objdumps so far...and then also discovering section 3.1.3.2 of the AAELF, I think I can answer the question with the following quotes: 1). "A PLT entry must be able to branch any distance to either instruction-set state. The span and state are fixed when the executable is linked dynamically. A PLT entry must therefore end with code similar to the following." (snip example using ip for linkage) 2). " ...it is generally pointless trying to construct a PLT entry entirely in 16-bit Thumb instructions. Even with the overhead of an inline Thumb-to-ARM state change, an ARM-state entry is usually smaller and always faster". Which gels with the ARM-state PLTs I've seen generated from builds (even with Thumb2 enabled during build time). I still want to actually finish testing Thumb2 build libraries used with a non-Thumb application, but I think it's now reasonable to say we don't need to make the call on Thumb2, should just complete the v7 bringup without Thumb2 and then turn on Thumb2 later/fix up bugs we find it doing that at that point. Please tell me if I am wildly off the mark on this technically. Jon. P.S. It seems that interworking is a requirement for Linux AAPCS built toolchains and will necessarily enable this as part of the build - am I wrong or are the GCC docs are out of date in this respect? _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
