I'm also not quite yet sold on using separate DWARF tooling, such as libabigail or STG, to actually understand why gendwarfksyms produced a different CRC for some symbol. Using these tools makes sense in the genksyms world, where genksyms operates on the source code level and this additional tooling can only work on debug data. With gendwarfksyms working directly with DWARF data, it doesn't seem appealing to me to first run gendwarfksyms to produce CRCs, compare them with their reference, and if they are different, use a second tool to process the same DWARF data again and with some luck hopefully get an actual answer why the CRCs changed. I'm worried that users might encounter inaccurate answers if the two tools interpret the input data differently. > > One more thing to note about the current --debug output is that it > directly correlates with the debugging information and thus may not > contain all aliases. For example, the Rust compiler deduplicates > identical function implementations (e.g. Deref::deref and > DerefMut::deref_mut etc.), but only one of the symbol names appears in > DWARF. We use symbol addresses to print out #SYMVERs also for the > aliases, but they don't show up in the debugging output right now. Thanks, Petr
