search for: dw_form_ref_addr

...addr] (0x000000006e384c30) DW_AT_high_pc [DW_FORM_data4] (0x000002b4) DW_AT_frame_base [DW_FORM_exprloc] (<0x1> 54 ) DW_AT_name [DW_FORM_strp] ( .debug_str[0x00001616] = "FB_FPUMP at HORIZONTAL") DW_AT_type [DW_FORM_ref_addr] (*0x000000006e440296*) DW_ AT_external [DW_FORM_flag_present] (true) In the original object file the corresponding record was: 0x00000296: DW_TAG_base_type [10] DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000068f] = "void") DW_A...

...ddAttribute(DW_AT_encoding, DW_FORM_data1, DW_ATE_signed); IntDie.addAttribute(DW_AT_byte_size, DW_FORM_data1, 4); DwarfGenDIE ArgcDie = SubprogramDie.addChild(DW_TAG_formal_parameter); ArgcDie.addAttribute(DW_AT_name, DW_FORM_strp, "argc"); //ArgcDie.addAttribute(DW_AT_type, DW_FORM_ref_addr, IntDie); // Crashes here... DG.generate(); auto Obj = object::ObjectFile::createObjectFile(Path); if (Obj) { DWARFContextInMemory DwarfContext(*Obj.get().getBinary()); uint32_t NumCUs = DwarfContext.getNumCompileUnits(); for (uint32_t i=0; i<NumCUs; ++i) { DWARF...

...g, DW_FORM_data1, DW_ATE_signed); > IntDie.addAttribute(DW_AT_byte_size, DW_FORM_data1, 4); > > DwarfGenDIE ArgcDie = SubprogramDie.addChild(DW_TAG_formal_parameter); > ArgcDie.addAttribute(DW_AT_name, DW_FORM_strp, "argc"); > //ArgcDie.addAttribute(DW_AT_type, DW_FORM_ref_addr, IntDie); // Crashes here... > > DG.generate(); > > auto Obj = object::ObjectFile::createObjectFile(Path); > if (Obj) { > DWARFContextInMemory DwarfContext(*Obj.get().getBinary()); > uint32_t NumCUs = DwarfContext.getNumCompileUnits(); > for (uint32...

...; IntDie.addAttribute(DW_AT_byte_size, DW_FORM_data1, 4); >>> >>> DwarfGenDIE ArgcDie = >> SubprogramDie.addChild(DW_TAG_formal_parameter); >>> ArgcDie.addAttribute(DW_AT_name, DW_FORM_strp, "argc"); >>> //ArgcDie.addAttribute(DW_AT_type, DW_FORM_ref_addr, IntDie); // >> Crashes here... >>> >>> DG.generate(); >>> >>> auto Obj = object::ObjectFile::createObjectFile(Path); >>> if (Obj) { >>> DWARFContextInMemory DwarfContext(*Obj.get().getBinary()); >>> uint32_t NumCU...

...anonymous namespaces or declared file-static) con co-exist even if their names collide. GDB does good things with this, except with Fission. Binutils DWP produces usable DWPs from DWO files with multiple CUs 2) Cross-CU references This is where it gets trickier. LLVM produces cross-CU references (DW_FORM_ref_addr) to refer to types or functions defined in one CU used from another. This only happens with (thin or plain) LTO. LLVM's had this for a while. This helps fully express interesting cases outlined in (1) - it's possible that a file-local function is inlined into another CU - by using ref_addr...

...arns/errors/complains if two CUs are in a single .dwo, and ignores all but the first. > > > Binutils DWP produces usable DWPs from DWO files with multiple CUs > > > > 2) Cross-CU references > > This is where it gets trickier. > > LLVM produces cross-CU references (DW_FORM_ref_addr) to refer to types > or functions defined in one CU used from another. This only happens with > (thin or plain) LTO. LLVM's had this for a while. > > This helps fully express interesting cases outlined in (1) - it's > possible that a file-local function is inlined into anothe...

...DW_AT_byte_size, DW_FORM_data1, 4); > >>> > >>> DwarfGenDIE ArgcDie = > >> SubprogramDie.addChild(DW_TAG_formal_parameter); > >>> ArgcDie.addAttribute(DW_AT_name, DW_FORM_strp, "argc"); > >>> //ArgcDie.addAttribute(DW_AT_type, DW_FORM_ref_addr, IntDie); // > >> Crashes here... > >>> > >>> DG.generate(); > >>> > >>> auto Obj = object::ObjectFile::createObjectFile(Path); > >>> if (Obj) { > >>> DWARFContextInMemory DwarfContext(*Obj.get().getBinary())...

...le. (Unless we can refer to everything via signatures). > >> >> > Binutils DWP produces usable DWPs from DWO files with multiple CUs >> > >> > 2) Cross-CU references >> > This is where it gets trickier. >> > LLVM produces cross-CU references (DW_FORM_ref_addr) to refer to types or functions defined in one CU used from another. This only happens with (thin or plain) LTO. LLVM's had this for a while. >> > This helps fully express interesting cases outlined in (1) - it's possible that a file-local function is inlined into another CU - by u...

...clude "llvm/Support/Dwarf.h" #include "llvm/Support/Format.h" #include "llvm/Support/raw_ostream.h" @@ -98,8 +99,16 @@ DWARFFormValue::extractValue(DataExtractor data, uint32_t *offset_ptr, indirect = false; switch (Form) { case DW_FORM_addr: - case DW_FORM_ref_addr: - Value.uval = data.getUnsigned(offset_ptr, cu->getAddressByteSize()); + case DW_FORM_ref_addr: { + RelocAddrMap::const_iterator AI + = cu->getContext().relocMap().find(*offset_ptr); + if (AI != cu->getContext().relocMap().end()) { + const std::pair<uint...

...inLTO, to create 'more unique' identifiers... but I don't know exactly how it'd all look there. > Binutils DWP produces usable DWPs from DWO files with multiple CUs > > 2) Cross-CU references > This is where it gets trickier. > LLVM produces cross-CU references (DW_FORM_ref_addr) to refer to types or functions defined in one CU used from another. This only happens with (thin or plain) LTO. LLVM's had this for a while. > This helps fully express interesting cases outlined in (1) - it's possible that a file-local function is inlined into another CU - by using ref_...

On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote: > For llvm-dwarfdump we need to handle relocations inside the debug info > sections in order to successfully dump the dwarf info including strings. > Nick sent out a partial patch that did this not too long ago and I've taken > it and gone in a bit of a different direction, but kept the same basic

...Null(); + if (!DieCU) + // We assume that Die belongs to this CU, if it is not linked to any CU yet. + DieCU = getCUDie(); + if (!EntryCU) + EntryCU = getCUDie(); + Die->addValue(Attribute, EntryCU == DieCU ? dwarf::DW_FORM_ref4 : + dwarf::DW_FORM_ref_addr, Entry); } If we made the correct assumptions inside addDIEEntry, we would make the correct decision between ref4 and ref_addr, so when we emitting a ref4, the two DIEs must belong to the same CU. If when emitting a ref4, the two DIEs do not belong to the same CU, it means we made the wrong assum...

...anks, Manman -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131004/11693025/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Debug-Info-support-for-DW_FORM_ref_addr.patch Type: application/octet-stream Size: 7495 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131004/11693025/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Debug-Info-remove-duplication-of-DIEs...

...om-addDIEEntry.patch Type: application/octet-stream Size: 8647 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131009/b37505fe/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Debug-Info-support-for-DW_FORM_ref_addr.patch Type: application/octet-stream Size: 7495 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131009/b37505fe/attachment-0001.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Debug-Info-remove-duplication-of...

On Thu, Dec 15, 2016 at 11:35 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have

17.09.2019 3:12, David Blaikie пишет: > > > On Wed, Sep 11, 2019 at 3:32 PM Alexey Lapshin via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Debuginfo and linker folks, we (AccessSoftek) would like to > suggest a proposal for removing obsolete debug info. If you find > it useful we will be happy to work on

...>         DW_TAG_subprogram >           DW_AT_name "f1" > 0x6e: DW_TAG_compile_unit >         DW_AT_name "b.cpp" > 0x8d:   DW_TAG_subprogram >           DW_AT_name "main" > 0xa6:     DW_TAG_inlined_subroutine >             DW_AT_abstract_origin [DW_FORM_ref_addr] > (0x0000000000000056 "_Z2f1v") > > ueaueoa > ueaoueoa > > Notice that the inlined_subroutine's abstract_origin uses a linker > relocation into the debug_info section to give an absolute offset > within the finally linked debug_info section (since the debug...

David, Thanks for reviewing! On Wed, Oct 9, 2013 at 11:36 AM, David Blaikie <dblaikie at gmail.com> wrote: > Might be easier if these were on Phabricator, but here are some thoughts: > > 0001: > This patch generally, while separated for legibility, is untested & > difficult to discuss in isolation. > I agree, this patch adds the functionality but does not use it,

...nce. Manman -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131015/9e50594a/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Debug-Info-support-for-DW_FORM_ref_addr.patch Type: application/octet-stream Size: 8150 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131015/9e50594a/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Debug-Info-remove-duplication-of-DIEs...

On Wed, Oct 16, 2013 at 9:10 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Wed, Oct 16, 2013 at 1:58 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> >> On Wed, Oct 16, 2013 at 1:21 PM, Manman Ren <manman.ren at gmail.com> wrote: >> >>> >>> There are a few places where we break the assumption: