[llvm-dev] [MC assembler] unexpected behavior of labels in nested macros

[Cédric Bonhomme via llvm-dev]

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>