This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Fwd: eglibc/glibc cross-build using llvm-gcc with unsupported -fno-toplevel-reorder
- From: Sergey Yakoushkin <sergey dot yakoushkin at gmail dot com>
- To: libc-alpha at sourceware dot org
- Date: Mon, 22 Feb 2010 02:56:36 +0300
- Subject: Fwd: eglibc/glibc cross-build using llvm-gcc with unsupported -fno-toplevel-reorder
- References: <29ad16f61002211528rb6dd90fq2f31366edc2fe3fc@mail.gmail.com> <29ad16f61002211553h7b4f1b86v46301075568cdd19@mail.gmail.com>
Hello,
I'm cross-compiling eglibc for new processor using llvm tool chain
(llcm-gcc, see www.llvm.org).
Build passes, but creates?miscompiled crt* files due to lack of
-fno-toplevel-reorder support in llvm-gcc.
This option might become deprecated?in gcc (~v 4.6), and seems never
will be supported by llvm.
http://www.llvm.org/bugs/show_bug.cgi?id=6364
Particular affected file is libc/sysdeps/generic/initfini.c. It
contains inlined asm with special markup of prologue/epilogue.
LLVM outputs all top level inlined asm as first bleck, and only after
that outputs functions. As result?sed strips wrong parts into crt*.s.
I've got advice?on llvm-dev maillist (see below) to split files or
avoid these tricks.
Ulrich, could you please share your point of view regarding issues
with -fno-toplevel-reorder?
Regards,
Sergey Yakoushkin
2010/2/22 Török Edwin?<edwintorok@gmail.com>
>
> On 2010-02-21 23:36, Sergey Yakoushkin wrote:
> > Hi, Rafael
> >
> > Inlined asm markup inside functions and on the top level is used to
> > split asm prologue/epilogue parts in very fine-grained manner.
> > So, splitting source c won't give the same result.
>
> You could have 2 files:
> ?- 1 which contains the function, and a marker where prolog ends
> (beginning of file is implicit marker of where it begins)
> ?- 1 which contains the function, and a marker where epilog begins
> (end of file is implicit marker of where it ends)
>
> Or just look at ./sysdeps/x86_64/elf/initfini.c, its a single asm()
> block containing all relevant markers, and no C code.
> I think thats better than all these hacks to get the asm you want out of
> C code.
>
> Best regards,
> --Edwin