Do not indiscriminately create text section

[MichalStrehovsky]

If we ended up with nothing in the text section, this line would error LLVM out in:

llvm-project/llvm/lib/MC/ELFObjectWriter.cpp

Lines 1458 to 1459 in 3db8d68

	Ctx.reportError(Fixup.getLoc(),
	"Cannot represent a difference across sections");

...because we generate a reference to the empty text section in the aranges section where SetCodeSectionAttribute registered it.

I double checked and debugging on Linux still works fine without this. SetCodeSectionAttribute is an objwriter API and we have access to it from the managed side. We should be calling it from there if it's needed for something that I didn't realize (we do call it from the managed side for the .managed section, but that one actually has debug information generated, unlike .text).

Cc @BrianBohe @markples

[MichalStrehovsky]

(I followed the problematic line all the way to dotnet/llilc#1073 where it was changed from being lazy (when we call SwitchSection) to eager (do it as part of init). It didn't look purposeful.)

[MichalStrehovsky]

@BrianBohe if you would like to shadow me on this ObjWriter bugfix, the repro steps are following:

1. Download and extract zerosharp.zip
2. Run ILCompiler with the following command line arguments: path\to\extracted\zerosharp.exe --systemmodule:zerosharp --targetos:linux -o:some\path\for\output\foo.o -g (Obviously, replace path\to\extracted and some\path\for\output).

You should see the Cannot represent a difference across sections error message that is generated in the above referenced file of the LLVM tree. We can debug this together over Teams.

[BrianBohe]

I was able to repro it, it would be great to see how you debug it anyway. Also, changes look good to me. What are these pipelines checking? Do we have code IL code to compile? Do we check the generated object files?

[MichalStrehovsky]

I was able to repro it, it would be great to see how you debug it anyway. Also, changes look good to me. What are these pipelines checking? Do we have code IL code to compile? Do we check the generated object files?

When you get it under a debugger, ping me over teams and we can screen share it.

The pipelines only do a build. They don't check anything - the validation will only happen once the bits make it to the runtime repo. Given the frequency of changes (https://github.com/dotnet/corert/commits/master/src/Native/ObjWriter - ~6 changes a year) setting up any other validation doesn't look like an investment that would pay off any time soon.