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

[Rafael Espindola]

> 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,
-- 
Rafael Ávila de Espíndola