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 ea...@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
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
