[llvm] [LLVM][DWARF] Chnage order for .debug_names abbrev print out (PR #80229)

[David Blaikie via llvm-commits]

dwblaikie wrote:

> I was mostly commenting that .debug_abbrev code lookup is O(1) where if we don't use indexes for the abbrev codes we must do some sort of search and if this happens in .debug_abbrev the search is linear. And of course any code that tries to find abbrevs should work (linear or direct access) depending on what the input is. The main point is it is much more efficient to use 1 based indexes since zero is reserved so that we _can_ do effecient lookups. Most of what I was pointing out was around what .debug_abbrev does right and how it is different from what we are doing for .debug_names abbrev codes.

Fair - thanks for helping me understand what we're doing today (on the LLVM emission side - we aren't emitting monotonically increasing debug_names abbrevation numbers, compared to debug_abbrev where we do use monotonically increasing abbrev numbers).

I think that's a mistake in LLVM's emission code, and not one we should worry about when designing llvm-dwarfdump. Both sides (LLVM DWARF emission, and llvm-dwarfdump parsing) should be fixed (to behave similarly to - but I don't think we need to wait for the emission to get better/fixed before we make llvm-dwarfdump handle things well)

I'd prefer to see the llvm-dwarfdump code not use a hash map, ideally reuse a generalized form of the debug_abbrev handling code - that's efficient for monotonically increasing abbrev numbers, and falls back to a linear search otherwise - and the printing should print from that list that's stored in the same order it's read from the input - and that list can be directly indexed if it's monotonically increasing, or linearly searched if it's not.

https://github.com/llvm/llvm-project/pull/80229