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. Plus this became a personal crusade for me once I realized it didn't want to "just work" :) I tend to get like that and will hack away at a problem until I figure it out, even if I won't end up using it in the end! Thanks again. -JB On Sat, May 30, 2009 at 5:07 AM, Erwin Authried <[email protected]> wrote: > most probably, at least one of your object files/libraries has been > compiled with the -fpic option. You have to fix that, overriding the > flag with flthdr doesn't work. Do you have a special reason why you want > to build busybox without xip? You know that the large text segment of > busybox is allocated seperately for each instance of busybox that you > are running? > > -Erwin > > Am Freitag, den 29.05.2009, 19:03 -0400 schrieb Jeff Bacon: >> Is anyone currently running busybox on and ARM7TDMI using NON_XIP? I >> have been banging my head against a wall all day because I cannot seem >> to get it to run correctly. I'm using the Snapgear 3.4.4 arm-linux >> toolchain and it compiles everything correctly for the non XIP case, >> all userland binaries are showing up with the "ram load" flag when >> running them through arm-linux-flthdr EXCEPT for busybox. For some >> reason, this keeps showing up with the "Has-PIC-GOT" flag and I think >> that this is what's causing me troubles, but I have no idea why >> elf2flt is throwing in this flag. All of my libraries were compiled >> without XIP as well, and like I said before, all my other non-busybox >> binaries are showing the correct flags. >> >> My BB binary contains only one applet, ls, and only for testing. If I >> try to run it as is, I get a kernel bug: >> >> Unhandled fault: vector exception (0x000) at 0x00000000 >> >> Ok fine, so I try to force a ram load by running "arm-linux-flthdr -r >> busybox" and it adds the ram load flag in there, but I still get the >> kernel bug. >> >> Next, I try running arm-linux-elf2flt directly on the >> busybox_unstripped.gdb elf image and it gives me a FLAT file with the >> correct ram load flag only, but of course running THAT one gives me >> other errors (I also put in the kernel trace flag) >> >> /var> ./busyboxb --help >> BINFMT_FLAT: Loading file: ./busybox >> Mapping is 4e0000, Entry point is 690, data_start is fd20 >> Load ./busybox: TEXT=4e0040-4efd20 DATA=4efd24-4f23a4 BSS=4f23a4-4f5994 >> BINFMT_FLAT: reloc outside program 0x1f978 (0 - 0x15954/0xfce0), >> killing busybox! >> >> I'm lost now and sure could use some help/pointers. Is this a hopeless >> scenario? Do I HAVE to have XIP in order to use busybox? >> >> -JB >> _______________________________________________ >> 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 > > _______________________________________________ > 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 > _______________________________________________ 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
