[Clfs-support] Help My x86_64 uClibc gcc is outputting 32 bit code

[Chris Ziomkowski]

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  __locale_mmap at GOTPCREL(%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