cmd/compile: generate correct DW_AT_external flag #22399
Comments
Thank you @thanm for the report! I've tweaked the title just a little and I'll page some of compiler folks @mdempsky @heschik @randall77 @griesemer. |
If it matters, I presume this is just a matter of checking the first rune of the name to see if it's upper case. But unless the flag is actually used for something somewhere, I might be inclined to just get rid of it instead. |
Well, hmm. I looked at the delve sources and it looks as though it's being relied on in github.com/derekparker/delve/pkg/dwarf/reader/reader.go right at the moment for variables. So at the moment it is being interpreted as a "this is interesting" flag and not a "this symbol visible outside its translation unit" flag. hmm. |
FWIW, it's unfortunately a little trickier than that, because of method symbols (e.g., "T.m"), method expression wrappers ("T.m-fm"), function value symbols ("f·f"), and function closures ("f.func1"). |
The current (1.9) Go compiler emits DWARF records for subprograms and variables that contain the "DW_AT_external" attribute, a flag which DWARF defines as:
If the name of the subroutine described by an entry with the tag ... is visible
outside of its containing compilation unit, that entry has a DW_AT_external attribute,
which is a flag.
The compiler is assigning a value to DW_AT_external based on whether the LSym in question is marked as static (AttrStatic), which I don't think is the same as the definition above. When I look at the generated DWARF for things like the Go compiler, the only things being marked as non-external are a small number of vars and functions from assembly files.
Not sure this makes a huge amount of difference (as far as I can tell there is no degradation to the debugging experience as a result of package-local functions being marked as external), but it might be worth fixing this up just for consistency / POLA.
The text was updated successfully, but these errors were encountered: