how to build eglibc using llvm-gcc without unsupported -fno-toplevel-reorder

Hi,

Are there any existing patches (or instructions) for eglibc(may be glibc/uclibc) to build it correctly with llvm-gcc?

Could you please point to them?

I’m cross-compiling eglibc for new processor using llvm-gcc.
Build passes, but creates mis-optimized crt* files due to lack of -fno-toplevel-reorder support.
Seems there are reasons to skip support of this option in llvm.
http://www.llvm.org/bugs/show_bug.cgi?id=6364

Particular issue is with libc/sysdeps/generic/initfini.c file which contains inlined asm with special markup. C is compiled into
asm and then gawk is used to strip different parts for different crt* files.

However, llvm outputs all top level inlined asm first, and only after it outputs code for functions. As result
gawk strips wrong parts into crt*.s.

Exmple initfini.c fragment:
 asm (".section " ".init" );

 extern void __attribute__ ((section (".init"))) _init (void);
 void
 _init (void)
 {
  call_gmon_start ();

  asm ("ALIGN");
  asm("END_INIT");

  asm ("\n/*@_init_PROLOG_ENDS*/");
  asm ("\n/*@_init_EPILOG_BEGINS*/");
  asm (".section " ".init" );
 }
 asm ("END_INIT");
 asm ("\n/*@_init_EPILOG_ENDS*/");
 asm ("\n/*@_fini_PROLOG_BEGINS*/");

Regards,
Sergey Yakoushkin

I haven't looked at the code, but why can't you split the .c files
into multiple files instead of splitting the generated asm? Not
running gawk on produced assembly should be a nice cleanup anyway.

Cheers,

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.

Regards,Sergey Y.

2010/2/22 Rafael Espindola <espindola@google.com>

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

Hi,

llvm doesn't support -fno-toplevel-reorder option which affects
glibc/eglibc for some targets.
http://www.llvm.org/bugs/show_bug.cgi?id=6364

From conversations with gcc and eglibc maintainers, seems option is

highly expected and is not going to deprecate.

If option is going to deprecate in gcc in near future as well, than it
make sense to consider changes in glibc(eglibc).
So, there are no plans to deprecate option. Did I understand correctly?

Correct. There are no plans to deprecate the -fno-toplevel-reorder
option.

Are there any reasons why option can't be supported by llvm?

Regards,
Sergey Yakoushkin

Are there any reasons why option can't be supported by llvm?

It is hard and has very few users. For this to work you would have to
add ordering information to the LLVM IL. It looks easier to patch
eglibc.

Regards,
Sergey Yakoushkin

Cheers,

Hi,

Are there any reasons why option can't be supported by llvm?

It is hard and has very few users. For this to work you would have to
add ordering information to the LLVM IL. It looks easier to patch
eglibc.

I agree, impact of issue is limited. But it prevents out of the box
compilation of libraries for some targets.
Also, looks like glibc and eglibc maintainers do not welcome patches
for llvm (yet).

In general, saving order of appearance doesn't seem to be bad thing.
Are there any technical issues with addition of ordering?
I guess class Module and it's uses in parser (and linker) will be
mostly affected.
Currently Module stores different entities separately and concatenates
all top level asm into single string.
  FunctionListType FunctionList; ///< The Functions in the module
  std::string GlobalScopeAsm; ///< Inline Asm at global scope.

Are there any other issues?

Regards,
Sergey Y.

I agree, impact of issue is limited. But it prevents out of the box
compilation of libraries for some targets.
Also, looks like glibc and eglibc maintainers do not welcome patches
for llvm (yet).

I would be very surprised if glibc ever does. I don't have any
experience with eglibc.

In general, saving order of appearance doesn't seem to be bad thing.
Are there any technical issues with addition of ordering?
I guess class Module and it's uses in parser (and linker) will be
mostly affected.
Currently Module stores different entities separately and concatenates
all top level asm into single string.
FunctionListType FunctionList; ///< The Functions in the module
std::string GlobalScopeAsm; ///< Inline Asm at global scope.

Are there any other issues?

Take a look at gcc's implementation. They need to keep the order of
every definition they see. It also has other issues:

1654 /* Output all functions, variables, and asm statements in the order
1655 according to their order fields, which is the order in which they
1656 appeared in the file. This implements -fno-toplevel-reorder. In
1657 this mode we may output functions and variables which don't really
1658 need to be output. */

Regards,
Sergey Y.

Cheers,

Hi,

Are there any other issues?

Take a look at gcc's implementation. They need to keep the order of
every definition they see. It also has other issues:
1656 ... This implements -fno-toplevel-reorder. In
1657 this mode we may output functions and variables which don't really
1658 need to be output. */

Ok, option support requires to keep order of definitions and for some
reason that is undesirable in LLVM.
Then, it would be helpful to get at least some diagnostic message from
llvm-gcc on unsupported option.

Regards,
Sergey Y.