search for: form_addrx

...uite possible that to get the address ranges covered by the CU one would need to look in the DWO, I think? Is that not correct/have I misunderstood something there? The DWO isn't supposed to contain addresses (because it isn't supposed to contain relocations). In DWARF 5 the DWO can have FORM_addrx references to the .debug_addr section in the main .o file, which allows the DWO to contain DIEs/attributes that should have address values, because the actual address values are still in the .o file; but before that anything that's an address really can't go into the DWO. Unless I am also...

...s covered by the CU one would need to look in the DWO, I think? >> >> Is that not correct/have I misunderstood something there? >> >> The DWO isn't supposed to contain addresses (because it isn't supposed to >> contain relocations). In DWARF 5 the DWO can have FORM_addrx references to >> the .debug_addr section in the main .o file, which allows the DWO to >> contain DIEs/attributes that should have address values, because the actual >> address values are still in the .o file; but before that anything that's an >> address really can't...

...to look in the DWO, I > think? > >> > >> Is that not correct/have I misunderstood something there? > >> > >> The DWO isn't supposed to contain addresses (because it isn't supposed > to > >> contain relocations). In DWARF 5 the DWO can have FORM_addrx > references to > >> the .debug_addr section in the main .o file, which allows the DWO to > >> contain DIEs/attributes that should have address values, because the > actual > >> address values are still in the .o file; but before that anything > that's an &gt...

?Hi ! I have a question about code used for collecting ranges. I was trying to fix PR35199. Its issue that it calls unreachable when calls DWARFObject::getFileName(). We do not implement this method in LLD and it fails. Issue appears when we start to provide .debug_str section to DWARF parser. And it is relative to following code (lines 335-339):