<div dir="ltr">In an effort to fix inlined information for backtraces under DWARF Fission in the absence of the split DWARF (.dwo) files, I'm planning on adding -gmlt-like data to the .o file, alongside the skeleton CU.<br>
<br>Since that will involve teaching the LLVM about -gmlt (moreso than it already has - the debug info LLVM metadata already describes -gmlt for the purposes of omitting pubnames in that case) I figured I'd take the opportunity to move the existing -gmlt functionality to the backend to begin with, and, in doing so, minimize it a little further since we wouldn't need to emit debug info for every function - possibly just those that have functions inlined into them.<br>
<br>So here's an example of some of my ideas about minimized debug info. I'm wondering if I'm right about what's needed for backtracing.<br><br>I've removed uninteresting things, like DW_AT_accessibility (which is a bug anyway), DW_AT_external (there's no reason symbolication needs that, is there?), but also less obviously uninteresting things like DW_AT_frame_base (the location of the frame pointer - is that needed for symbolication?)<br>
<br>Also I've made a frontend (for now) change (see mgmlt_clang.diff) to omit the data that causes DW_AT_decl_file/DW_AT_decl_line to be emitted - are those needed? I don't think so.<br><br>But importantly: the only DW_TAG_subprograms are either functions that have been inlined, or functions that have been inlined into. Is that enough?<br>
<br>Is it OK that I haven't included debug info for out of line definitions of inline functions?<br><br>I'm assuming all that information can be retrieved from the symbol table.<br><br>(one other thing I noticed is that we don't use the mangled names for functions in -gmlt - how on earth does that work? The backtrace would look really strange if it included the unmangled names of functions - or does the symbolizer use the address range of the out of line definition (if there is one?) of the inlined function (in which case I'd need to provide it... ) to find it in the symbol table, get the mangled name, and use that?)<br>
<br>One thing I was thinking of doing as well, is that since the DW_AT_abstract_origin just points to a trivial subprogram with a name and DW_AT_inline - perhaps instead of an abstract origin, we could just use DW_AT_name directly? (with the mangled name, probably) That'd save us emitting the extra indirection and the name is uniqued already anyway. (and DW_FORM_strp is the same size as DW_FORM_ref4 (though DW_FORM_strp would mean extra relocations...) - and perhaps in the near future, DW_FORM_strp could be replaced by DW_FORM_str_index to reduce relocations)<br>
<br>So... yes/no/maybe?</div>