On 20.01.2024 13:40, LIU Hao wrote: > 在 2024-01-19 17:13, Jan Beulich 写道: >> But I see a severe issue with your aim at confining strict mode to >> compiler generated code only: In inline assembly (see your mentioning of >> APP / NO_APP above) you still potentially reference C symbols. So the >> ambiguities don't disappear in APP / NO_APP regions. > > My suggestion is that people who write inline assembly should have been aware > of the existence of > bad names, and should have been careful to avoid them. > > >> And an array happening to be indexed by rcx would then result in >> >> mov eax, DWORD PTR rcx[rcx] # `movl rcx(%rcx), %eax` >> >> ? That's going to be confusing at best. > > This is always confusing, no matter how it is written. > >> I think this whole issue needs >> taking care of differently, and iirc I did already suggest an alternative >> in one of the bugzilla entries involved: Potentially ambiguous names >> (which to a compiler may mean: all symbol names) ought to simply be >> quoted, and it ought to be specified that quoted symbols are never >> registers. Iirc this will require gas changes, yes, but it'll address all >> ambiguities afaict. > > The OP of GCC PR53929 said that 'the problem does _not_ go away even if I > quote the symbol name by > hand in the assembly output' which was 12 years ago. I tried my local > installation and quoting the > symbol turned out to avoid the issue: > > > as --version > GNU assembler (GNU Binutils) 2.41.0.20240108 > > > cat test.s > .intel_syntax noprefix > lea rax, "bx"[rip] > > > as test.s -o test.o > > > objdump -d test.o > test.o: file format pe-x86-64 > (...) > 0: 48 8d 05 00 00 00 00 lea rax,[rip+0x0] # 7 > <.text+0x7> > 7: 90 nop
Right, I did some work in that direction a while ago. But iirc there are still cases left to be addressed. Jan
