NPTL not building?

[Rob Landley]

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