Cédric Bonhomme via llvm-dev
2016-Nov-28  13:41 UTC
[llvm-dev] [MC assembler] unexpected behavior of labels in nested macros
Dear LLVM Community,
I am currently facing an issue with the expansion of nested macros, using local
labels. Considering the following example, in which a macro PARENT invokes its
DAUGHTER macro:
.macro PARENT
    jmp 1f // jump to local label 1
    DAUGHTER
1:
    ...
.endmacro
.macro DAUGHTER
    jmp 1f // jump to local label 1
    ...
1:
    ...
.endmacro
PARENT
The label used by the jmp instruction of DAUGHTER is the one defined in PARENT,
which is not what I expect:
llvm-mc -arch=x86 -show-encoding < test.asm:
      jmp   .Ltmp0     # encoding: [0xeb,A]
                            #   fixup A - offset: 1, value: .Ltmp0-1, kind:
FK_PCRel_1
      jmp   .Ltmp0     # encoding: [0xeb,A]
                            #   fixup A - offset: 1, value: .Ltmp0-1, kind:
FK_PCRel_1
.Ltmp0:
      ...
.Ltmp1:
      ...
This issue is part of the generic MC implementation, as I could reproduce the
same behavior for different target architecture (the example above is x86).
Is this a known issue ? Is there any workaround for this problem ?
Thanks in advance,
Best regards,
Cédric
 ------------------------------------------------------------------------------
E-MAIL DISCLAIMER
The present message may contain confidential and/or legally privileged
information. If you are not the intended addressee and in case of a transmission
error, please notify the sender immediately and destroy this E-mail. Disclosure,
reproduction or distribution of this document and its possible attachments is
strictly forbidden.
SPACEBEL denies all liability for incomplete, improper, inaccurate, intercepted,
(partly) destroyed, lost and/or belated transmission of the current information
given that unencrypted electronic transmission cannot currently be guaranteed to
be secure or error free.
Upon request or in conformity with formal, contractual agreements, an originally
signed hard copy will be sent to you to confirm the information contained in
this E-mail.
SPACEBEL denies all liability where E-mail is used for private use.
SPACEBEL cannot be held responsible for possible viruses that might corrupt this
message and/or your computer system.
 -------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161128/974ba1ac/attachment-0001.html>