Variables with the same name as registers break Intel assembly about lensorcompilercollection HOT 18 CLOSED

from lensorcompilercollection.

It seems that GCC avoids dealing w/ this by simply emitting object files instead 👁️

from lensorcompilercollection.

I guess the ‘solution’ to this is to disallow .intel_syntax noprefix and require .intel_syntax prefix instead when emitting assembly for GAS as GAS doesn’t seem to have a way of handling these kinds of symbols... If we ever add a NASM backend, we can solve this problem as described in the previous paragraph.

I guess the ‘easiest’ way of solving this issue would be to simply add a flag to the codegen context (bool intel_syntax_use_prefix or sth like that) and then depending on that, we choose whether to emit a prefix in femit_*(). That flag can then be set or not depending on a command line option. Speaking of, we should probably add an option like --assembler or sth like that that accepts different values (GAS being the only one atm), and depending on that and on the assembly dialect, we can choose whether to use prefixes or not, as well as what directives to emit etc.

from lensorcompilercollection.

so that shouldn’t be too bad

I forgot for a second that this also entails assembling the code, so er, that might take a bit longer haha

from lensorcompilercollection.

I feel like if GCC doesn’t handle this case, then we don’t really need to care too much about handling it either. I recall LLVM-generated assembly not being particularly compilable either if you use... less orthodox label names...

from lensorcompilercollection.

Interesting; it seems the intel dialect has quite a few of these cases due to it's ambiguous nature (no way in the syntax to determine whether something is a register, immediate, symbol, etc).

I believe it's in the plans to mangle not only function names, but also variable names, with the caveat of anything ext being left unmangled. This means that eventually we'll end up with something like _Xv3rax, which wouldn't have such conflicts.

from lensorcompilercollection.

I find the best solution to this problem is to ask GCC for advice

from lensorcompilercollection.

... thanks GCC

from lensorcompilercollection.

It’s worth noting that GCC uses AT&T by default, so it doesn’t normally suffer from this problem unless you use intel syntax

from lensorcompilercollection.

Clang straight-up just generates incorrect assembly:

from lensorcompilercollection.

NASM can deal with this problem it seems:

An identifier may also be prefixed with a $ to indicate that it is intended to be read as an identifier and not a reserved word; thus, if some other module you are linking with defines a symbol called eax, you can refer to $eax in NASM code to distinguish the symbol from the register.

from lensorcompilercollection.

@LensPlaysGames Not sure how familiar you are w/ NASM, but I can take a look at implementing a NASM backend if you’d like 👀

from lensorcompilercollection.

This means that eventually we'll end up with something like _Xv3rax, which wouldn't have such conflicts.

Finally, this is definitely true and I doubt conflicts like this one would be common, but that doesn’t change the fact that 1. they’re possible, and 2. more assembler backends and options is probably a good idea anyway, because maybe someone would prefer to just use NASM or some other assembler...

from lensorcompilercollection.

I guess the ‘solution’ to this is to disallow .intel_syntax noprefix and require .intel_syntax prefix instead when emitting assembly for GAS

This is probably the first step to take; it would fix this issue for the default backend, and therefore for most users of the Intercept compiler.

Not sure how familiar you are w/ NASM

I learned NASM first, then GAS. That's why LensorOS has a mix of NASM .asm and GAS .S, haha. But yeah: I'm familiar :).

I can take a look at implementing a NASM backend if you'd like

I mean, don't let me stop you (support for more backends is always highly appreciated), but this isn't necessarily top priority to me. Personally, I envision that what will be most useful is an object file backend, as those object files can then be used by any assembler, compiler, linker, etc.; but that is an entire project in itself, hehe. However that's just my perspective: someone who doesn't really know C all that well would probably greatly appreciate a backend for an easier-to-obtain assembler like NASM (it has prebuilt binaries readily available, whereas binutils... yeah).

1. they’re possible, and 2. more assembler backends and options is probably a good idea anyway

💯. It's only a bad thing to support more backends when it is something that won't be maintained. I think NASM is close enough to the existing default backend (GAS) that it really won't be too difficult to maintain; it'll basically be a translation job more than anything, when implementing new codegen.

from lensorcompilercollection.

Personally, I envision that what will be most useful is an object file backend

on it

Seriously tho, I’m sort of familiar w/ object file layout, so that shouldn’t be too bad. ELF files that is. I happen to know that you’re at least somewhat familiar w/ COFF, so I’ll leave that up to you 👀

from lensorcompilercollection.

And adding an asm backend would just entail changing the directives, so that should be fairly simple imo

from lensorcompilercollection.

The machine_code branch takes care of this the same way GCC does; by emitting object files instead :P

#66

  D:/Programming/strema/2023/Interceptmachine_code  24                            Garry 2023-05-27 12:14:28
╰─> .\bld\intc examples\register_variable_name.int -t coff_object -v -o code.obj
GObj dump:
  Sections:
    .text Data: 34 bytes:
      55 48 89 e5 48 8b 05 00  00 00 00 48 89 c1 51 48      |UH..H......H..QH|
      83 ec 28 e8 00 00 00 00  48 83 c4 28 59 48 89 ec      |..(.....H..(YH..|
      5d c3                                                 |].|
    .rodata EMPTY
    .data Data: 8 bytes:
      45 00 00 00 00 00 00 00                               |E.......|
    .bss Fill 0 bytes with '0'
  Relocations:
    0: rax in .text at offset 7 : None
    0: putchar in .text at offset 20 : Function
  Symbols:
    rax in .data at offset 0 : Static
    main in .text at offset 0 : Function
    putchar in .text at offset 34 : External

Generated code at output filepath "code.obj"
  D:/Programming/strema/2023/Interceptmachine_code  24                            Garry 2023-05-27 12:16:38
╰─> gcc code.obj -o code.exe
  D:/Programming/strema/2023/Interceptmachine_code  24                            Garry 2023-05-27 12:16:41
╰─> .\code.exe
E
  D:/Programming/strema/2023/Interceptmachine_code  24                            Garry 2023-05-27 12:16:44
╰─> echo $env.LAST_EXIT_CODE
69

from lensorcompilercollection.

#66 has closed, main now behaves as GCC does (and LLVM's clang, presumably), so we are good to go with closing this bad boi.

from lensorcompilercollection.