Enable dumping GC tables in release builds

[BruceForstall]

To enable this, change jit.h from:

#define DUMP_GC_TABLES DEBUG

to:

#define DUMP_GC_TABLES 1

and build a Release JIT.

[BruceForstall]

cc @dotnet/jit-contrib

[AndyAyersMS]

Dose the modified build work? I think I had to do more than this , eg verbose is not defined.

[BruceForstall]

It does. E.g.,

f:\gh\runtime\artifacts\tests\coreclr\Windows_NT.x64.Release\JIT\Methodical\Arrays\misc\_il_relarrres>f:\gh\runtime\artifacts\tests\coreclr\Windows_NT.x64.Release\tests\Core_Root\CoreRun.exe _il_relarrres.dll
Set code length to 92.
Set ReturnKind to Scalar.
Set Outgoing stack arg area size to 32.
Register slot id for reg rcx = 0.
Register slot id for reg r8 = 1.
Register slot id for reg rax (byref) = 2.
Register slot id for reg rcx (byref) = 3.
Register slot id for reg rdx = 4.
Set state of slot 0 at instr offset 0x4 to Live.
Set state of slot 1 at instr offset 0x4 to Live.
Set state of slot 2 at instr offset 0x11 to Live.
Set state of slot 0 at instr offset 0x22 to Dead.
Set state of slot 3 at instr offset 0x25 to Live.
Set state of slot 4 at instr offset 0x28 to Live.
Set state of slot 4 at instr offset 0x31 to Dead.
Set state of slot 1 at instr offset 0x31 to Dead.
Set state of slot 3 at instr offset 0x31 to Dead.
Set state of slot 0 at instr offset 0x33 to Live.
Set state of slot 1 at instr offset 0x3b to Live.
Set state of slot 0 at instr offset 0x4d to Dead.
Set state of slot 3 at instr offset 0x4d to Live.
Set state of slot 1 at instr offset 0x56 to Dead.
Set state of slot 2 at instr offset 0x56 to Dead.
Set state of slot 3 at instr offset 0x56 to Dead.
Defining interruptible range: [0x4, 0x28).
Defining interruptible range: [0x31, 0x36).
Defining interruptible range: [0x3b, 0x4d).
Defining interruptible range: [0x56, 0x5c).
...

It's not great because it doesn't print method names, and automatically prints all the GC info for every function, but it's a start.

[BruceForstall]

However, if you are doing exactly one Release mode compile in SuperPMI, it's fine.

[AndyAyersMS]

This is a good start. Probably more we can consider here, eventually (perhaps) splitting DEBUG into DEBUG_DUMP and DEBUG_CHECK so it's possible to have full (or nearly full) dumping from a release build.

In my exploration for #39023 I also ended up thread-prefixing things as it was hard to narrow dumping down to just one method and the app was multithreaded. We're not quite set up for that in some of the dump messaging -- need to consolidate multiple printfs into one or something, so the atomic unit of output can be a full line.

[AndyAyersMS]

LGTM.

[BruceForstall]

Yes, in no way is this complete or comprehensive. More opportunistic. Seemed worthwhile to save this work.