How to use "&" in CIL .data-declarations

Viewed 85

I am writing a compiler targeting the common intermediate language and want to use .data-declarations for globals. I mean section II.16.3.1 of the Spec.

How can I use what is described as "Address of label"? The following does assemble using .NET-Core's ilasm:

.assembly extern mscorlib
{
    .ver 4:0:0:0
}
.assembly 'string'
{
}
.module 'string'

.data hello_world_data = { int8(72), int8(101), int8(108), int8(108), int8(111), int8(32), int8(87), int8(111), int8(114), int8(108), int8(100), int8(33), int8(0) }

.field static int8 hello_world at hello_world_data

.data addr_of_data = &(hello_world_data)

.field static int8* hello_world_ptr at addr_of_data

.method public static default int32 main () cil managed {
    .entrypoint

    ldc.i4.0
    ret
}

But when I try to execute the code above, I get the following error message (using .NET-Core on Linux):

Unhandled exception. System.BadImageFormatException: Could not load file or assembly '/home/lou/uni/proj/stuff/tests/test-global-arrays/string.exe'. An attempt was made to load a program with an incorrect format.

File name: '/home/lou/uni/proj/stuff/tests/test-global-arrays/string.exe'


[1]    12019 abort (core dumped)  dotnet string.exe

Any ideas/help?

1 Answers

If this is important for you, I would suggest filing an issue in the https://github.com/dotnet/runtime repo.

I assume the reason this doesn't work outside Windows is because these directives generate data with relocations (places within the executable that need to be fixed up with a real address once the executable is loaded into memory). Since the format of the executables in .NET is based on the Windows PE format, the relocation is processed by Windows when it loads the executable.

Outside Windows, CoreCLR ships with a small "Windows loader emulator" that loads the .NET executables the way Windows would load them. But it probably misses the handling for these relocations. The IL format doesn't generate relocations otherwise.

But these relocations are going to be problematic in many places (I fully expect e.g. tools like the IL Linker to miss them and damage them, I assume Mono doesn't have handling for the these either, they are going to be problematic for AOT compilation, etc.).

Related