<div dir="ltr">Sorry I'm not really following all these pieces.<br><br>There's two basic ways these APIs are predominantly used:<br><br>1) llvm-dwarfdump: This opens one file/context at a time, and generally doesn't open other files - such as dwos or o/exe for skeleton. (indeed, there's no reliable way to find a skeleton, given a dwo - only to find dwos given skeletons)<br>2) llvm-symbolizer: this opens executable files (or .o files) and from there can load dwo/dwp/dsym related files as needed<br><br>What sort of use case do you have? I guess it can/should look something like (2) so can you use the LLVM debug info APIs in a similar manner to llvm-symbolizer to achieve your goals?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 16, 2021 at 6:39 PM Alexander Yermolovich <<a href="mailto:ayermolo@fb.com">ayermolo@fb.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
I was hoping you will see this. <span id="gmail-m_1677693868165934654🙂">🙂<br>
<br>
Digging some more this is also affected for DW_TAG_subprogram </span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<span>
<div style="color:rgb(212,212,212);background-color:rgb(30,30,30);font-family:Menlo,Monaco,"Courier New",monospace;font-weight:normal;font-size:12px;line-height:18px">
<span><span style="color:rgb(78,201,176)">DWARFDie</span><span>::</span><span style="color:rgb(220,220,170)">getLowAndHighPC</span></span></div>
<br>
</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<span>Under the hood it eventually calls </span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<span>
<div style="color:rgb(212,212,212);background-color:rgb(30,30,30);font-family:Menlo,Monaco,"Courier New",monospace;font-weight:normal;font-size:12px;line-height:18px">
<span><span style="color:rgb(78,201,176)">DWARFUnit</span><span>::</span><span style="color:rgb(220,220,170)">getAddrOffsetSectionItem</span></span></div>
<br>
</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<span>I played/hacked around with things some more, and would like opinions on potential fixes.<br>
One is to add SkeletonCU to the DWO CU when it is created.<br>
<a href="https://reviews.llvm.org/D96826" id="gmail-m_1677693868165934654LPlnk730239" target="_blank">https://reviews.llvm.org/D96826</a><br>
<br>
It kind of follows logic in getAddrOffsetSectionItem in a sense that if Unit is DWO, it looks in to NormalUnits, and uses that to get the address.<br>
<br>
Alternatively there is just adding a check in getAddrOffsetSectionItem itself.<br>
<a href="https://reviews.llvm.org/D96827" id="gmail-m_1677693868165934654LPlnk395790" target="_blank">https://reviews.llvm.org/D96827</a><br>
<br>
Reason this works is that when parseDWO, by way of getNonSkeletonUnitDIE, is invoked the AddrOffsetSection and AddrOffsetSectionBase get set correctly. The <span style="color:rgb(0,0,0);background-color:rgb(255,255,255);display:inline">AddrOffsetSection
points to the base of .debug_addr in the binary A, and <span style="color:rgb(0,0,0);background-color:rgb(255,255,255);display:inline">AddrOffsetSectionBase is proper offset for this unit within it.<br>
<br>
So when <span style="color:rgb(0,0,0);background-color:rgb(255,255,255);display:inline">getAddrOffsetSectionItem is invoked address is looked up correctly in the section. Kind of weird part is that Obj is A.o since we are using the DWO
unit Context.<br>
<br>
I am just digging into these APIs, so maybe I am missing something, and there is a better option.<br>
<br>
Thank You<br>
Alex</span></span></span></span></div>
<div id="gmail-m_1677693868165934654appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_1677693868165934654divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>><br>
<b>Sent:</b> Monday, February 15, 2021 10:09 PM<br>
<b>To:</b> Alexander Yermolovich <<a href="mailto:ayermolo@fb.com" target="_blank">ayermolo@fb.com</a>>; Pavel Labath <<a href="mailto:pavel@labath.sk" target="_blank">pavel@labath.sk</a>><br>
<b>Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [llvm-dev] Extracting LocList address ranges from DWO .debug_info</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>This stuff is a bit ad-hoc at best.<br>
<br>
I believe some of these APIs have been generalized enough to be usable<br>
for your use-case, but it might be at a lower level - specifically I<br>
think the loclist infrastructure is used by lldb when parsing DWARFv5.<br>
But it might be used without some of the LLVM DWARF Unit abstractions<br>
you're using. (those abstractions are used in llvm-dwarfdump - which<br>
often isn't dealing with both .o and .dwo, but only dumping one of the<br>
files & doing what it can (or sometimes dumping one file containing<br>
both sets of sections, in which case it can do some address lookup,<br>
etc, more conveniently))<br>
<br>
On Fri, Feb 12, 2021 at 6:07 PM Alexander Yermolovich via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hello<br>
><br>
> I am wondering if this is a bug, or more likely something I am doing wrong/using wrong APIs.<br>
> I have binary A, and object file A.o, compiled with Clang debug fission single mode. So .dwo sections are in the object file. Although with split mode it would bre the same behavior.<br>
> Relevant parts of the code:<br>
> for (const auto &CU : DwCtx->compile_units()) {<br>
> auto *const DwarfUnit = CU.get();<br>
> if (llvm::Optional<uint64_t> DWOId = DwarfUnit->getDWOId()) {<br>
> auto *CUDWO = static_cast<DWARFCompileUnit*>(DwarfUnit->getNonSkeletonUnitDIE(false).getDwarfUnit());<br>
> ...<br>
> }<br>
> }<br>
><br>
> Later in the code I iterate over DIEs for .debug_info.dwo and call<br>
> DIE.getLocations(dwarf::DW_AT_location);<br>
><br>
> Alternatively can manually extract offset and call<br>
> CUnit->findLoclistFromOffset(Offset);<br>
><br>
> It fails because it tries to look up address using DWARFUnit in NormalUnits that it extracts from A.o.<br>
> Under the hood vistAsoluteLocationList is called with getAddrOffsetSectionItem passed in.<br>
> Since this DWARFUnit is DWO, it invokes Context.info_section_units(). Which uses A.o to create DW_SECT_INFO and DW_SECT_EXT_TYPES.<br>
> Then calls itself, but from the newly constructed Debug DWARFUnit. The skeleton CU that is in A.o.<br>
><br>
> Since the way it's constructed the AddrOffsetSectionBase is never set, so getAddrOffsetSectionItem returns None. Eventually error is returned from high level API call.<br>
><br>
> I ended up doing this to get address ranges:<br>
> DWARFLocationExpressionsVector LocEVector;<br>
> auto CallBack = [&](const DWARFLocationEntry &Entry) -> bool {<br>
> auto StartAddress =<br>
> BaseUnit->getAddrOffsetSectionItem(Entry.Value0);<br>
> if (!StartAddress) {<br>
> //TODO: Handle Error<br>
> return false;<br>
> }<br>
> LocEVector.emplace_back(DWARFLocationExpression{DWARFAddressRange{<br>
> (*StartAddress).Address, (*StartAddress).Address + Entry.Value1,<br>
> Entry.SectionIndex}, Entry.Loc});<br>
> return true;<br>
> };<br>
><br>
> if(Unit->getLocationTable().visitLocationList(&Offset, CallBack))<br>
> ...<br>
><br>
><br>
> But back to original API calls. Are they just not designed to work with DWO CUs, or am I missing something?<br>
><br>
> Even if AddrOffsetSectionBase was set to 0, the address section it is accessing is in A.o and is not relocated. One would still need to get base address from the address from Skeleton CU to get fully resolved address ranges, or what I did to use index to
access binary .debug_addr section directly (with appropriate AddrOffsetSectionBase).<br>
><br>
> Thank You<br>
> Alex<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
<br>
</div>
</span></font></div>
</div>
</blockquote></div>