Hello everyone.
I am hoping someone here can point me in the right direction. I have
previously started with the LiveCD and built an x86_64 CLFS system with
glibc which is very stable now and has run without incident for several
weeks. This is now my host system.
I am now trying to build a target x86_64 pure 64 bit system using uClibc
and including the latest GNU 4.3.2 gcc compiler. This project is going
to run on an Atom based system, and even the current gcc has not yet
been optimized for this CPU. Even so, I need the latest compiler so that
I'm prepared when the enhancements do eventually show up.
There are many examples on the net of building uClibc. There are also
many at building x86_64 for glibc. There is basically no support for
building pure 64 x86_64 and uClibc, especially when using the 4.3.2
version of gcc.
After 3 weeks of fighting problems with uClibc (has some issues with
x86_64), and gcc for uClibc, I thought I finally had a good compiler. It
passed all the tests...or as many as you can expect with uClibc. I built
all my native applications and they ran. I was busy congratulating
myself when I tried to rebuild uClibc using the native compiler on the
uClibc system. That is when I ran into problems. uClibc compiles fine,
but as soon as I install the libraries I get a segmentation fault
running any program.
I tracked the problem down to the function isatty() inside of uClibc.
When I compile uClibc with my cross-compiler from the host system I get
the following (correct) code snippet:
__GI_isatty:
.LFB2:
subq $88, %rsp
.LCFI0:
movq %rsp, %rsi
movq __stack_chk_guard(%rip), %rax
movq %rax, 72(%rsp)
xorl %eax, %eax
call __GI_tcgetattr
testl %eax, %eax
sete %al
movq 72(%rsp), %rdx
...
However, when I compile using my native compiler, I get the following
(incorrect) code:
__GI_isatty:
.LFB2:
subq $88, %rsp
.LCFI0:
movq %rsp, %rsi
movq %fs:40, %rax <=== Segmentation fault occurs here
movq %rax, 72(%rsp)
xorl %eax, %eax
call __GI_tcgetattr
testl %eax, %eax
sete %al
movq 72(%rsp), %rdx
...
When the code tries to access fs, it seg faults. (fs is currently 0 ). I
have seen many other instances of the compiler generating 32 bit
compatible code (e.g. movq [EMAIL PROTECTED](%rip), %rax) since I
have started looking for it, but this is the instruction that causes my
immediate problems.
So, I'm guessing I missed a patch somewhere which tells GCC to be
completely 64 bit, or else the uClibc patches overwrote it. This isn't
surprising as there were dozens of patches I tried and many of the
uClibc patches were incompatible with the pure 64 bit patches
recommended by the CLFS project.
Rather than simply specifying yet another patch, can someone help me
understand the principles involved in making GCC generate pure 64 bit
code? Then, at least if the patch doesn't work, I can try to figure out
where it went wrong. For reference, the following patches were applied,
which worked after some massaging:
gcc-4.3.2-pure64-1.patch
200-uclibc-locale.patch
203-uclibc-locale-no__x.patch
204-uclibc-locale-wchar_fix.patch
205-uclibc-locale-update.patch
301-missing-execinfo_h.patch
303-c99-complex-ugly-hack.patch
304-index_macro.patch
305-libmudflap-susv3-legacy.patch
306-libstdc++-namespace.patch
So, is there anyone who can explain to me what needs to be fixed for gcc
to generate real 64 bit code, and how I should go about doing that?
Thank you for any assistance,
Chris
_______________________________________________
Clfs-support mailing list
[email protected]
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
