Could someone on #1041 please test this to see if it resolves the issue at hand? The other options available are to hard code our own version of that type, or force dwarf2json to inject it, neither of which seem all that clean...

Welp, that didn't work. Looks like I'll need to investigate what went wrong...
Seems to be returning no results for linux plugins (but not throw an issue). Should be easy to check the difference between the working version and the patched version.

Ok, turns out this doesn't work for a number of reasons. Firstly, it's being done on the physical layer, which still comes out with the right pointer size, but the pointer is then limited to the size of the layer it's in, so it gets cropped. Secondly, the symbol space has been loaded, but the higher layer hasn't been decided yet (because that depends on the init_task, which is what we're trying to make) so there's no way of using it as the native_layer for the pointer.

So now I'm doing a little bit of ugly gymnastics to cast the pointer to bytes (to get the original value) and then read the integer value from it the same way the pointer would, but without the address layer mask. Shouldn't be necessary for the other use because just wants the size, which should match the system's pointer size (not sure if that holds true for 32-bit systems, I'm not sure what long unsigned int is defined as in 32-bit systems). There may still be other places where the core depends on symbols that may not be present in the final symbol table. Some will be in plugins, but I care less about them than the core.