Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

gcc option -fno-toplevel-reorder separates top level inline asm which affects eglibc #6736

Closed
llvmbot opened this issue Feb 21, 2010 · 8 comments
Closed

gcc option -fno-toplevel-reorder separates top level inline asm which affects eglibc #6736

llvmbot opened this issue Feb 21, 2010 · 8 comments
Labels
bugzilla Issues migrated from bugzilla llvm:codegen wontfix Issue is real, but we can't or won't fix it. Not invalid

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Feb 21, 2010

Bugzilla Link 6364
Resolution WONTFIX
Resolved on May 09, 2016 15:10
Version 2.6
OS Linux
Attachments source used to create crt code in eglibc
Reporter LLVM Bugzilla Contributor
CC @asl

Extended Description

-fno-toplevel-reorder option is used with by eglibc library (libc/csu) to generate init/fini code for ctr*.

llvm-gcc initfini.c -c -std=gnu99 -fgnu89-inline -O0 -Wall -Winline -Wwrite-strings -fmerge-all-constants -Wstrict-prototypes -mpreferred-stack-boundary=4 -DHAVE_INITFINI -S -g0 -fPIC -fno-inline-functions -fno-toplevel-reorder -fno-section-anchors -finhibit-size-directive -fno-exceptions -o initfini.s

C source file comes with inlined asm having 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 separately in AsmPrinter::doInitialization, and after it outputs all functions. Which results in eglibc fail to build with llvm.

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/");
@asl
Copy link
Collaborator

asl commented Feb 21, 2010

We do not support this flag, and I really doubt this will happen one day.

@lattner
Copy link
Collaborator

lattner commented Feb 21, 2010

Right, this flag is deprecated by GCC and we have no intention of implementing it. The code should be fixed to not depend on it.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 21, 2010

Are there existing patches for glibc/eglibc for llvm?

BTW. Are there any technical issues to support option?

Right, this flag is deprecated by GCC and we have no intention of implementing
it. The code should be fixed to not depend on it.

@lattner
Copy link
Collaborator

lattner commented Feb 21, 2010

I don't know if there are patches, there are many technical reasons to not support this. We don't track the order of inline asm vs functions. Adding it would be significant implementation effort for an option that is deprecated (and never really made sense).

@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 21, 2010

Thanks for your answer, Chris. Ok, option support seems to be unlikely.
But I don't think I'm the first one facing issues with C libraries build. Haven't found info on the web yet. Is there any support person for that? Or appropriate topic to discuss?

@lattner
Copy link
Collaborator

lattner commented Feb 21, 2010

I don't really know, but you can definitely email llvmdev and ask if others have any idea

@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 22, 2010

Wouldn't simple saving of initial lexical order in parser be enough to reorder inlined top level asm to output correctly?

I've contacted eglibc maintainers and got the following answer. Seems they expect this option to be supported by compilers:

2010/2/22 Joseph S. Myers joseph@codesourcery.com:

On Mon, 22 Feb 2010, Sergey Yakoushkin wrote:

This option might become deprecated in gcc (~v 4.6),

That seems an extremely unlikely speculation.  What actual evidence from
GCC development discussions do you have for it?  I think someone has got
confused by some old discussions of -fno-toplevel-reorder as the
replacement for deprecated -fno-unit-at-a-time into thinking it's
-fno-toplevel-reorder that's deprecated; it's not and is hardly likely to
be.

--
Joseph S. Myers
joseph@codesourcery.com

@rnk
Copy link
Collaborator

rnk commented May 9, 2016

*** Bug llvm/llvm-bugzilla-archive#27688 has been marked as a duplicate of this bug. ***

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
@Quuxplusone Quuxplusone added the wontfix Issue is real, but we can't or won't fix it. Not invalid label Jan 20, 2022
Michael137 pushed a commit to Michael137/llvm-project that referenced this issue May 2, 2023
@compnerd
Merge pull request llvm#6736 from compnerd/sdkroot
59b1687 
Host: introduce `GetSDKPath` extension point for Windows
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla llvm:codegen wontfix Issue is real, but we can't or won't fix it. Not invalid
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@rnk @asl @Quuxplusone @lattner @llvmbot