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 [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
_______________________________________________
Clfs-support mailing list
[email protected]
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
