You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We do read some internal stuff, specifically runtime.buildVersion, runtime.firstmoduledata, runtime.reflectOffs, runtime._type and associates and runtime.g. We also look up the entry point for a number of internal runtime functions (runtime.gopanic, runtime.deferreturn, runtime.breakpoint,runtime.stackBarrier that doesn't exist anymore and runtime.goexit).
We don't use those two, in general things that have unspecified type probably aren't very useful.
And just by coincidence, a heap viewer tool I've seen (that I'm not going to link here because I'm not sure the author wants it publicized) actually uses runtime.enoptrbss too. I think it's going to be very difficult to reliably predict whether a given field/type is useful or not.
It's sort of funny that a format as size-obsessed as DWARF has no way to reference a string from the symbol table. Not that I'd want to write that linker code.
...I wonder if you could declare a .debug_str section that overlapped .strtab...
Run
dwarfdump helloworld
and poke through the results. I see entries like:and
I don't see how these could ever arise in a debugging context; they're purely internals with no associated variables.
Depending on how many of these there are, it might be worth a bit of effort to avoid generating them.
@heschik @aarzilli @mdempsky
The text was updated successfully, but these errors were encountered: