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

Rafael Espindola espindola at google.com
Mon Feb 22 17:06:36 PST 2010

> 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.

Rafael Ávila de Espíndola

More information about the llvm-dev mailing list