[uClinux-dev] Busybox and arm7tdmi

Jeff Bacon jbac.uc.dev at gmail.com
Mon Jun 1 09:14:32 EDT 2009


  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.


On Sun, May 31, 2009 at 3:21 AM, Erwin Authried <eauth at softsys.co.at> 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

More information about the uClinux-dev mailing list