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

[Chris Ziomkowski]

Following on:

This may be yet another bug in uClibc for x86_64, and nothing to do with 
my build (thus possibly not appropriate for this mailing list). I am 
attempting to confirm the information. I found the following in 
gcc-4.3.2/gcc/config/i386/linux64.h

#ifdef TARGET_LIBC_PROVIDES_SSP
/* i386 glibc provides __stack_chk_guard in %gs:0x14,
   x86_64 glibc provides it in %fs:0x28.  */
#define TARGET_THREAD_SSP_OFFSET        (TARGET_64BIT ? 0x28 : 0x14)
#endif

So the use of the segment register is not indicative of 32 bit code, but 
instead is expected to be set up by the runtime library with the address 
of __stack_chk_guard. In this case, since fs was 0, it appears uClibc 
has not properly set up this address, and is generating a segmentation 
fault.

Is there anyone out there who has experience in this area and can give 
me guidance on how to proceed with this investigation?

Best Regards,

Chris

Chris Ziomkowski wrote:
> 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
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Clfs-support mailing list
> Clfs-support at lists.cross-lfs.org
> http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
>