Erwin, Sorry, I guess my previous post was kind of confusing and didn't tell the whole story.
First I was using the GCC 4.2.1 toolchain from the snapgear website, and for whatever reason compiling without the DISABLE_XIP flag set (in config.arch) produced non-working binaries. I attributed this to XIP issues for this toolchain, so I worked on getting the system up and running with the DISABLE_XIP flag set, and this worked. Then after some postings from others on this mailing list I decided to downgrade to the 3.4.4 toolchain, but I wanted to make sure that I hadn't affected anything by switching to this older toolchain, meaning I wanted to get a stable system up and running with the DISABLE_XIP flag set like before. Now that I have this working, I have commented out DISABLE_XIP in config.arch (so now I have PIC binaries) and re-compiled and everything is still working (so my issue previously was in the GCC 4.2.1 toolchain). As for why busybox wasn't working previously with libgcc.a's PIC code, its because I had DISABLE_XIP active when compiling, meaning that I was missing the linker directives " += -D__PIC__ -fpic -msingle-pic-base" when I compiled it, which I believe is needed for PIC code to execute properly. -JB On Sun, May 31, 2009 at 3:21 AM, Erwin Authried <[email protected]> wrote: > Am Samstag, den 30.05.2009, 23:12 -0400 schrieb Jeff Bacon: >> Erwin, >> >> You were absolutely correct. After going over EVERYTHING with a >> fine-tooth comb I found the issue. >> >> The gcc 3.4.4 toolchain from the snapgear website used the -fPIC >> option when libgcc.a was compiled for the toolchain. When I ran the >> "nm" utility on that file to look at all the symbols I found several >> that had _GLOBAL_OFFSET_TABLE_ listed. >> >> When I compared those entries with the map file for the busybox >> binary, I found that a single file in the libbb directory (xatonum.c) >> generated code that referenced one of these libgcc built-ins that >> utilized the GOT (_udivdi3 for those interested). All other libgcc.a >> references were ok. >> >> So I looked a little further at this file and it turns out that there >> is something in my settings SOMEWHERE for ULONG_MAX and ULLONG_MAX >> that caused the wrong set of function definitions to be included in >> the compilation. Long story short, if I force the secondary set of >> function definitions in that file, the code generates properly and >> busybox links correctly with the proper load-to-ram flag being set >> from elf2flt. I tested it out on my platform and it worked! >> >> On to your second point Erwin, you are correct again, I will NOT want >> to run BB from RAM in the end. After reading through the mailing list >> at all the horror stories with arm7tdmi + XIP, I decided that I first >> wanted to get a system up and running and configured properly without >> messing with any XIP stuff, then once I was satisfied with that, I >> would apply the XIP patches and attempt to replicate my known good >> system using XIP instead. This way if any issue crop up I know that >> it's due to XIP issues and not misconfigurations. > > I'm not sure what you are referring to, but I have made the opposite > experience. I have always used PIC without any trouble. There was just > one special application where I had to use non-pic code recently, and > this made trouble with elf2flt, as you know. > > If you are talking about true XIP (=text segment executed directly in > flash), this may be slightly more complicated. But this isn't a > requirement to use pic code, and often you can't use that anyway because > the flash is too slow or the filesystem is compressed to save space. But > even without that, the text segment is shared in ram if multiple > instances of the same application are running. > > -Erwin > >> _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
