There is no harm in calling dwarf_get_aranges() each time you need to use it. libdwarf's implementation first checks to see if it has already initialized the arange array for this particular dbg handle, and simply returns it if so. The first call does the initialization. So this caching that you're doing doesn't really help with anything, I believe.

I also don't think it makes sense to print a warning if dwarf_get_aranges() returns DW_DLV_NO_ENTRY. If you get anything other than DW_DLV_OK or DW_DLV_NO_ENTRY it should probably be a fatal error.

I think this comment could be a bit more descriptive. :)

I think this block can be written without a goto:

if (tag != DW_TAG_label) {
   <something>
        goto cont_search;
}

Also, what happens when we have a label without a low_pc attribute?

I think a high-level description of what this function is doing would be useful.

Style: indentation should be by four spaces here.

"die" should be written "DIE".

There's no need to cast the return value of calloc() in C.

Indentation by four spaces.

I think these comments ("free memory", "return status", "add to cache", etc.) which describe *what* the code is doing are not useful. It's better to ensure that the high-level algorithm is documented, and to write comments that explain *why* the code is doing something when it's not clear.

This s/CU/range/ is just for clarity? I'm curious about reordering so die and dbg are at the top now. (Sorry if I missed something in the earlier discussion.)

Yes, I think I asked for the rename since we no longer really assume that a CU can be represented by a single address range. I'm not sure about the purpose of reordering the fields.

Is this die -> range->die an incidental fix?

It would seem so. I don't remember exactly the reason for this change but when translating an address and at label out, range->die will be set to the correct die to use either from a cache lookup or a linear scan. I believe either die and range->die are both ok.

Swapped these around in FreeBSD in rS367853

could we actualy return anything other than DW_DLV_OK or DW_DLV_NO_ENTERY before?

I believe this function has always been returning either DW_DLV_OK or DW_DLV_NO_ENTRY