llvm-IR 变量和汇编器符号的 llvm 命名策略

Question

As I see llvm supports null-terminated strings including any character (0x01 to 0xff) as valid names for llvm-IR variables and assembler symbols. In my opinion such desicion may cause some problems.

1. It is difficult to edit programms in llvm-IR and assembler using text editors (Vim, Kate and others), when names contains "special" (nonprintable) charecters
2. LLvm and assemblers support escaping with double quotes, for example "AB" is a name with a space character. It would be logically to expect a printf like style in coding of special characters. I mean "\\n" , "\\t" , "\\xAB" , but llvm-IR and assembler doesn't supports this style for names (but llvm suports \\KL for initializers).

• in one hand "A\\n" produces not "A" and newline character but name with all 3 bytes in object elf-file
• in other hand "A\\n" and "A\\\\n" produces identical names for llvm

(So it seems that even llvm doesn't support special naming in a any kind of proper way.)

@"A\n"   = internal constant i32 1
@"A\\n"  = internal constant i32 2

$ clang-9 test.ll -S
test.ll:3:1: error: redefinition of global '@A\n'
@"A\\n"  = internal constant i32 2

3. What is about @GOTOFF , or @plt ? How to differentiate names including @GOTOFF from assembler relocation specification? Why "AB@GOTOFF" can be assembling, but "AB"@GOTOFF doesn't works?

4. Bug https://sourceware.org/bugzilla/show_bug.cgi?id=18581 was opened in 2015 but even now gas doesn't support some characters in names, which llvm supports. For example "A,B" and "A\\B" can't be assembling by gas. So llvm creates assembler dialect, which can't be assembling by gas.

Programming languages (C/C++, Rust, Go, Python, Java, ...) support only letters , digits , '_' , '$' characters in identifiers. Frontends using also '.' , '$' , '#' characters, but in any way they generate names valid in assembler (without any escaping by double quotes).

Probably, only llvm optimizations generate names with special characters. But these names are created only for globals with internal (static in C terms) linkage. So why not to use special pattern like "__llvm_internal_global_Id_*" for such globals (some names are reserved in all cases)?

So what are the reasons to use such naming policy? May be it is better to use a small but simple set of valid characters for naming?

Answer 1

I will try to summarize the interim results.

The llvm supports llvm-IR variable names and asm symbol names as a sequence of any characters. In general it looks as a good solution.

But current realizations has some special moments.

1. Llvm-parser can works with llvm-IR, in which both string initializers and names of the global variables contain escape sequences (using "\\AB"-pattern where 0xAB is hex-code). But in assembler language the escape sequence doesn't used or/and doesn't worked (also there are readelf, objdump, gdb and so on). This fact creates problems for the use of text editors.

2. Assembler language uses special relocation modificators likes @plt , @GOTOFF and others after symbol names. So now it is a collision when a symbol name (in double quotes) includes a substring likes "@plt" . And I propose a simple rule for assembler lexic-parser

A@plt       - symbol with name 'A' and plt-relocation
"A@plt"     - symbol with name 'A@plt'
"A@plt"@plt - symbol with name 'A@plt' and plt-relocation

(so all in double quotes is a part of name, and all after double quotes or just in the end of a symbol name is a relocation modificator).

3. Gas declares the supporting ( https://sourceware.org/binutils/docs/as/Symbol-Intro.html#Symbol-Intro ), but in fact doesn't support "," or "\\" in symbol names. So the set of valid symbol names in gas is less then in llvm-as.

And I want to hope that these moments will be fixed in llvm and gas (if this is a correct description of the current situation).