Andreas, Sorry if I'm just adding more confusion for everyone!
The _original_ toolchain was compiled with these flags: TARGET_LIBGCC2_CFLAGS = -fomit-frame-pointer -fPIC -Dinhibit_libc -D__gthr_posix I re-compiled with these NEW flags: TARGET_LIBGCC2_CFLAGS = -fomit-frame-pointer -fPIC -fpic -msingle-pic-base -Dinhibit_libc -D__gthr_posix The two problems I was having were similar but not the same. In the previous thread that you were referring to, I was attempting to get a system up and running that ONLY contained FLT binaries with _only_ the "Load to Ram" flag set in the header. This was not happening because the original libgcc.a was compiled with "-fPIC" as you can see from above. When I was compiling busybox, it generated code that referenced PIC code from that libgcc.a, and the system would crash. My hypothesis was that the issue was because libgcc.a was compiled with -fPIC, but without the added "-msingle-pic-base" that I think is required for arm7tdmi (correct me if I'm wrong on that). Since code in busybox was linking to the PIC functions in libgcc.a, it was generating a PIC binary. So the first solution was to correct an issue in busybox so that I could compile everything without any PIC code, which I was able to do. Once I did this (confirmed by running arm-linux-flthdr on all binaries and confirming only the Load-to-Ram flag was set), busybox ran fine on my board, no crashing. That was just a first step however, as my ultimate goal was a system running userland XIP. For this case, I searched the mailing list on how to do this for my processor and applied everyone's knowledge which led me to patching ROMFS and MTD and re-compiling the 3.4.4 toolchain with the proper, additional "-msingle-pic-base" flag, which was that this second thread was about. After (finally) recompiling and running the system, everything seems to work correctly (PIC code runs fine, and is XIP from flash). So to me it would appear that the issue was having libgcc.a compiled with -fPIC, but WITHOUT -msingle-pic-base, when for arm7tdmi it needs both. Does that clear up everything? -JB Andreas Fenkart wrote: > On Thu, Jun 11, 2009 at 10:07:01AM -0400, Jeff Bacon wrote: > >> Sorry, I meant to post back on this topic, but yes, the fixes worked as >> advertised. I haven't tested every little piece of the compiler, but I >> can confirm that it gives me working userland XIP now, and nothing else >> seems broken. The whole reason I had to re-compile in the first place >> was to add the "-msingle-pic-base" flag to libgcc in order to get >> everything working correctly. >> > > I'm confused here, did you mean to leave out -msingle-pic-base. > In another thread "Busybox and arm7tdmi" you mentionned > that libgcc.a is compiled with: > > >> 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. >> > > Andi > _______________________________________________ > 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
