[LLVMdev] [LLVM] Forward temp label references on ARM in LDR with .ltorg in inline assembly are broken in trunk

[Gordon Keiser]

Gas isn't able to handle quotes in label names, and chokes on 0x02 regardless of whether the label is quoted or not:

Unquoted:
lolwut.s: Assembler messages:
lolwut.s:23: Error: junk at end of line, first unrecognized character valued 0x2
lolwut.s:25: Error: unknown pseudo-op: `.l1'

Quoted:
lolwut.s: Assembler messages:
lolwut.s:23: Error: bad expression
lolwut.s:23: Error: junk at end of line, first unrecognized character is `.'
lolwut.s:25: Error: junk at end of line, first unrecognized character is `"'


Additionally, I'm not sure this should be done with the numbered local labels at all.  I know this has to be done at some point, but the semantics of these labels allows duplicates within a single function / .s file because they are all relative to the instructions referencing them.    For example, there is nothing wrong with the following as far as the assembler is concerned (aside from being pointless and unreadable :-) ):  

lolwut:
    b 1f
1:
    b 1b
    b 1f
1:

LLVM expands them into different temp labels properly aside from the 0x02, but since this form of numbered labels are designed such that they don't need to be uniqued, why bother?  In the case of those labels, a problem that doesn't exist is being solved. 

Cheers,
-Gordon Keiser




> The mangling you see is the assembler generating a private label. It 
> includes the unprintable character 0x2 so that it cannot conflict with 
> any user crated label.
>
>> I'll file a bug on this after I track down my bugzilla password but I 
>> wanted to ask here first because I'm willing to fix it if someone can 
>> point me in the right direction.
>
> It looks like this is behavior is not particular to just .ltorg, but 
> shows up when printing the private labels.
>
> $ cat tt.s
> .syntax unified
> foo:
>   b 1f
> 1:
>   add r0, r0, r0
> $ llvm-mc < tt.s
>         .text
> foo:
>         b       ".L11"
> ".L11":
>         add     r0, r0, r0
> $ llvm-mc < tt.s | hexdump -C
> 00000000  09 2e 74 65 78 74 0a 0a  0a 66 6f 6f 3a 0a 09 62
> |..text...foo:..b|
> 00000010  09 22 2e 4c 31 02 31 22  0a 22 2e 4c 31 02 31 22
> |.".L1.1".".L1.1"|
> 00000020  3a 0a 09 61 64 64 09 72  30 2c 20 72 30 2c 20 72  
> |:..add.r0, r0,
> r|
> 00000030  30 0a                                             |0.|
> 00000032
>
> I'm not sure if this is a bug or the intended behavior for printing 
> these labels.

I am pretty sure this is a bug. It was found by the recent change to parse assembly, but it is an independent bug.

Would you mind reporting it with your simple "b 1f" example in llvm.org/bugs?

Thanks,
Rafael