[Bug inline-asm/96081] New: changed placement of file scope asm() contents

jbeulich at suse dot com gcc-bugzilla@gcc.gnu.org
Mon Jul 6 15:45:17 GMT 2020


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96081

            Bug ID: 96081
           Summary: changed placement of file scope asm() contents
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: inline-asm
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jbeulich at suse dot com
  Target Milestone: ---

>From 9.2 to 9.3 (and presumably then also to 10.1) a change in when, inside the
resulting assembly, file scope asm()-s get output has caused a breakage in one
of the Xen Project's auxiliary tools. What I can observe is that, with any kind
of optimization enabled, all asm()-s get processed first, whereas the data that
we want them to control gets output last.

I realize the output order is really unspecified, but I'd still like to
understand if there's at least a workaround here. What we want to achieve is
control over the ELF type of certain symbols, and this without triggering
modern gas'es "symbol '...' already has its type set" warnings (which the new
behavior not triggers, thus becoming aware of the change in the first place).
Up to gcc 9.2 we simply could put

        .type <symbol>, STT_NOTYPE;
        .type <symbol>, STT_FUNC;

after the data definition and get gcc's respective ".type <symbol>, @object"
overridden this way.

But of course in the more general case it may also be necessary / desirable to
have certain asm()-s take effect _after_ compiler output.


More information about the Gcc-bugs mailing list