On 01/29/2011 11:42 AM, Carmelo Amoroso wrote: >> That's a show-stopper bug for me. >> >> Rob > > In understand. > An option could be to transform all .cfi_xxx pseudo ops in a corresponding > macro cfi_xxx > that expands to nothing if the binutils or arch does not support (or the user > does not want) CFI. > > A lot of CFI ops are already managed in this way. There is a define under > uClibc_arch_feature that could be used for this > > /* define if target supports CFI pseudo ops */ > #undef __UCLIBC_HAVE_ASM_CFI_DIRECTIVES__ > > Does it sound reasonable ?
Ooh, yes please! Sparc, i386, x86_64, and sh. This implies that if I build the simple armv5l target (without building a second stage cross compiler), it should work... My buildall.sh script builds an x86 cross compiler first, and then builds the other target cross compiler twice doing the gcc stage1/stage2 thing except taking manual control and supplying a uClibc-based host compiler so it can statically link the compiler binaries against uClibc on the host. This is part of letting you grab the tarball and run it out of your home directory on an arbitrary Linux system. (Alas, this involves building an i686 compiler, which is where I hit this. Because statically linked 32 bit code runs on just about all x86-64 systems, and due to exerting less L1 cache pressure it isn't actually noticeably slower than a native 64 bit version, although I haven't benched them recently...) And the uClibc build broke for armv5l target: # # configuration written to ./.config # MKDIR include/bits make: *** No rule to make target `libc/sysdeps/linux/arm/crtreloc.c', needed by `lib/crtreloc.o'. Stop. make: *** Waiting for unfinished jobs.... Ok, that didn't work. Is it due to the make -j 6? Try with CPUS=1... AS lib/crt1.o AS lib/Scrt1.o AS lib/crti.o cc1: error: unrecognized command line option "-mfdpic" make: *** [lib/crti.o] Error 1 Well, at least it died in a different place... Let's see how a mips build does: AS lib/crt1.o libc/sysdeps/linux/mips/crt1.S: Assembler messages: libc/sysdeps/linux/mips/crt1.S:117: Warning: No .cprestore pseudo-op used in PIC code AS lib/Scrt1.o libc/sysdeps/linux/mips/crt1.S: Assembler messages: libc/sysdeps/linux/mips/crt1.S:117: Warning: No .cprestore pseudo-op used in PIC code AS lib/crti.o cc1: error: unrecognized command line option "-mfdpic" make: *** [lib/crti.o] Error 1 Exiting due to errors (mips simple-cross-compiler uClibc) Died in the same place, but emitted more warnings first. > We should review all the code and transform the missing one. Um, dunno what that means? > I had a similar problem with ARM/NPTL where my binutils 2.10 does not support > .cfi_sections that is used > in some the unwdiner asm code. I have a my own patch for this, not yet fully > complete. > > I'll see to find some time to come with a proposal patch. Cool. I'm eager to test this as soon as you've got something for me, although I don't see why a config option or build-time compiler probe to switch off the #define wouldn't work too... By the way, what do cfi_sections _do_? Google found this: http://us.generation-nt.com/patch-x86-use-cfi-sections-help-198180281.html http://stackoverflow.com/questions/3564752/what-is-cfi-and-lfe-in-assembly-code-produced-by-gcc-from-c-program Both of which imply it's to do with stack unwinding, either for debug purposes or for c++. Isn't half the code lin libgcc_eh.a already to do with stack unwinding? This is at least fourth stack unwinding mechanism they've introduced (frame pointers, sjlj, dwarf2). Not to mention the original setjmp not needing this at all before c++ crapped all over the C spec... Oh well, I'm sure they'll have rewritten it all over again in five years. A bit like the C++ String class... (I've still got my compiler configured for sjlj exceptions because it worked, I've never had cause to revisit it, and it doesn't really come up much with pure C code which includes the runtimes for higher level languages like Perl and Python. I'm just now getting around to swithing from pthreads to NPTL in part because glibc's code to build under a non-NTPL Linux system bit-rotted about 3 years ago and no longer works, so I can't bootstrap current glibc on a uClibc-0.9.31 system. My aboriginal project is designed to make cross compiling go away, I.E. all about getting a native development environment on the target which you can then completely replace via native building if you want to, either on appropriate native hardware or under QEMU. I even provide a few example bootstrap scripts to show you how to do it. Bit of a hole in the design if you can't build glibc.) Rob _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
