Re: [Dwarf-Discuss] DW_LANG_C11
On Wed, Sep 25, 2013 at 3:38 AM, Mark Wielaard wrote: > Hi, > > I saw the following issue which proposed DW_LANG_C_plus_plus_03 and > DW_LANG_C_plus_plus_11. It appears to have been accepted for DWARF4 > according to this page: > http://www.dwarfstd.org/Issues.php?type=closed3 > But apparently didn't make it into the actual DWARF4 spec. > > Now I notice DWARF4 came out in 2010, so at least DW_LANG_C_plus_plus_11 > would be speculative. Was it misfiled and is this a proposal for DWARF5 > instead? It's marked as accepted as of 11/27/12 so ... > > Asking because I was wondering if it would make sense to propose > DW_LANG_C11 (ISO/IEC 9899:2011) for DWARF5? I guess? Were there any language specific changes that would be important for consumers of debug info? -eric > > Thanks, > > Mark > > ___ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Add file attributes to debug-line file table (proposal 130701.1)
FWIW I fully agree with this line of reasoning. I was going to propose it as well (though not as comperhensively) since we may decide that we want to use something other than "the low 64-bits of an md5 hash" to represent the file. Speaking of which, the particular hash and such should be explicitly changeable in the header. -eric On Tue, Mar 18, 2014 at 7:33 AM, Mark Wielaard wrote: > Hi, > > I was reading the suggestion for adding MD5 digests to the .debug_line > program header. http://dwarfstd.org/ShowIssue.php?issue=130701.1 > > Adding more attributes of files seems like a good thing, but as > specified this isn't extensible without changing the version number > again and defining new formats. Would it be possible to make this a > little more generic and vendor extensible? > > The .debug_macro proposal includes some language for defining > extensibility that could possibly be used. > http://dwarfstd.org/ShowIssue.php?issue=110722.1 > > So instead of a fixed file_entry_format (ubyte) field that just allows > one attribute (group) to be defined we could change it to something > like: > > file_attributes (ubyte) > - Possibly zero, number of attributes added to each file in the > file_names table. > file_attribute_description (sequence of attribute descriptions) > - Entries in this description describe which attributes and in what > format those attributes are encoded for each file entry. It has > file_attributes entries. Each entry consists of: > - file_attribute (ubyte). One of DW_LNF_timestamp, > DW_LNF_length, DW_LNF_MD5, ... > - file_attribute_format. A uleb128 describing the number of > arguments for the format followed a single byte describing the > form of the argument. The allowed values are DW_FORM_data1, > DW_FORM_data2, DW_FORM_data4, DW_FORM_data8, DW_FORM_sdata, > DW_FORM_udata, > DW_FORM_block, DW_FORM_block1, DW_FORM_block2, DW_FORM_block4, > DW_FORM_flag, > DW_FORM_string, DW_FORM_strp and DW_FORM_sec_offset. > > file_names (sequence of file entries) > - Each entry consists of the following values: > - A null-terminated string containing the full or relative path name > of a source file. > - An unsigned LEB128 number representing the directory index of a > directory in the include_directories section. > - For each file_attribute_format described in the > file_attribute_description entries the value encoded in the format > given by file_attribute_format. > > For example DW_LNF_timestamp and DW_LNF_length would have as format 1 > DW_FORM_udata. DW_LNF_MD5 could by described by 2 DW_FORM_data8. > > That would allow extending the number of attributes in later DWARF > versions or as vendor extensions and give consumers a way to skip over > any unknown attributes. > > Would something like the above suggestion be useful? Then I can work it > out a bit more. Did I miss any subtle corner cases? What is the status > of the .debug_macro proposal (110722.1)? It would be good to match the > descriptions of both extension mechanisms as much as possible. > > Thanks, > > Mark > > ___ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Interaction between aranges and unit proposals
On Tue, Apr 1, 2014 at 4:38 AM, Mark Wielaard wrote: > Hi, > > I have been pondering the various aranges proposals and how they > interact with the change to merge the units proposal. It looks like the > intent of two proposals is diminished by two other proposals. > > To make it possible to quickly see whether an address (range) is covered > by an ELF file containing DWARF information two proposals were made: > > aranges does not have debug info length > http://dwarfstd.org/ShowIssue.php?issue=100430.1 > > debug_aranges and address-less CUs > http://dwarfstd.org/ShowIssue.php?issue=100430.2 > > Together when adopted makes life for a debugger much easier. You would > scan the .debug_aranges section, note the addresses, see whether all CUs > from the .debug_info section are covered and then don't need to load any > other information if no address match is found. Given that the > main .debug_info/.debug_abbrev sections are often huge and that some > programs contain lots of modules not having to map them all in is a > great benefit. > > But then there are also the following proposals: > > Type Unit Merge > http://dwarfstd.org/ShowIssue.php?issue=130526.1 > > Ambiguity in DWARF4 of debug_info_offset in .debug_aranges > http://dwarfstd.org/ShowIssue.php?issue=100816.1 > > Together these proposals counter the first two proposals. Since when > adopted the first would introduce type units in the main .debug_info > section and then the second would remove .debug_aranges for those units. > Which would bring us back to the original situation that you cannot just > scan the .debug_aranges for an address and check whether all units > in .debug_info are covered. So you will again need to load and scan them > too when trying to match an address. > > Is there a way to reconcile these proposals so they keep the benefit of > both (quick/complete address scan without having to load/parse bulk data > and simplifying the DWARF data structures by combining various units in > one section)? > Absolutely a fan. Knowing what various consumers need is going to be key for any tables to speed up access. > One way might be to reverse the last proposal. Instead of removing the > aranges for type units (which did indeed not make much sense in the > split .debug_info/.debug_type approach), add an empty aranges header if > a type unit appears in .debug_info in the way of the second proposal for > address-less CUs. > We could do this, but I think adding one for every type unit would be a bit wasteful. Since type units are going to have a flag in the header would it be possible for you to notice that when looking through the units? I'm not sure how you know that you have complete coverage so I'm just throwing out words here, could you provide a bit of a description of how this works for me if you don't mind? -eric ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] About a Windows port
As a quick note, you're aware that Windows in general doesn't use dwarf right? -eric On Mon, Nov 16, 2015 at 11:26 AM Vincent Torri wrote: > Hello > > I have begun to write a valgrind-like on Windows, and I use libbfd to > get the stack trace (file, function and line of a frame). > > I would like to use libdwarf for that. But I need to port libdwarf to > Windows. > > On the website, it is said to contact this mailing list before > contributing any code. > > So what I suppose to do ? :-) > > regards > > Vincent Torri > ___ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] About a Windows port
You didn't specify what compiler you were using to build the debug sources you cared about. Keep in mind you won't be able to look through the system libraries for things, but you'll be able to look at what you built at least. -eric On Mon, Nov 16, 2015 at 12:16 PM Vincent Torri wrote: > afaik, gnu windows toolchain stores debug informations in DWARF > format. Am I wrong ? > > Vincent Torri > > On Mon, Nov 16, 2015 at 8:44 PM, Eric Christopher > wrote: > > As a quick note, you're aware that Windows in general doesn't use dwarf > > right? > > > > -eric > > > > On Mon, Nov 16, 2015 at 11:26 AM Vincent Torri > > wrote: > >> > >> Hello > >> > >> I have begun to write a valgrind-like on Windows, and I use libbfd to > >> get the stack trace (file, function and line of a frame). > >> > >> I would like to use libdwarf for that. But I need to port libdwarf to > >> Windows. > >> > >> On the website, it is said to contact this mailing list before > >> contributing any code. > >> > >> So what I suppose to do ? :-) > >> > >> regards > >> > >> Vincent Torri > >> ___ > >> Dwarf-Discuss mailing list > >> Dwarf-Discuss@lists.dwarfstd.org > >> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] About a Windows port
No, it implies you were using bfd to read dwarf, nothing else. On Mon, Nov 16, 2015, 9:22 PM Vincent Torri wrote: > Hello > > On Mon, Nov 16, 2015 at 11:05 PM, Eric Christopher > wrote: > > You didn't specify what compiler you were using to build the debug > sources > > you cared about. > > I've mentioned libbfd, which implicitely specifies that i'm using a > GNU toolchain. > > Vincent Torri > > > Keep in mind you won't be able to look through the system > > libraries for things, but you'll be able to look at what you built at > least. > > > > -eric > > > > On Mon, Nov 16, 2015 at 12:16 PM Vincent Torri > > wrote: > >> > >> afaik, gnu windows toolchain stores debug informations in DWARF > >> format. Am I wrong ? > >> > >> Vincent Torri > >> > >> On Mon, Nov 16, 2015 at 8:44 PM, Eric Christopher > >> wrote: > >> > As a quick note, you're aware that Windows in general doesn't use > dwarf > >> > right? > >> > > >> > -eric > >> > > >> > On Mon, Nov 16, 2015 at 11:26 AM Vincent Torri < > vincent.to...@gmail.com> > >> > wrote: > >> >> > >> >> Hello > >> >> > >> >> I have begun to write a valgrind-like on Windows, and I use libbfd to > >> >> get the stack trace (file, function and line of a frame). > >> >> > >> >> I would like to use libdwarf for that. But I need to port libdwarf to > >> >> Windows. > >> >> > >> >> On the website, it is said to contact this mailing list before > >> >> contributing any code. > >> >> > >> >> So what I suppose to do ? :-) > >> >> > >> >> regards > >> >> > >> >> Vincent Torri > >> >> ___ > >> >> Dwarf-Discuss mailing list > >> >> Dwarf-Discuss@lists.dwarfstd.org > >> >> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] About a Windows port
Excuse me? I, and others, have been polite and trying to help you with minimal information. This is unacceptable behavior and I request that you cease the unprofessional behavior immediately. On Mon, Nov 16, 2015, 10:19 PM Vincent Torri wrote: > better shut up instead of saying helpless remarks, you're absolutely of no > help > and i doubt you can compile binutils with vc++ > that's my last answer to you > > > > On Tue, Nov 17, 2015 at 6:51 AM, Eric Christopher > wrote: > > No, it implies you were using bfd to read dwarf, nothing else. > > > > > > On Mon, Nov 16, 2015, 9:22 PM Vincent Torri > wrote: > >> > >> Hello > >> > >> On Mon, Nov 16, 2015 at 11:05 PM, Eric Christopher > >> wrote: > >> > You didn't specify what compiler you were using to build the debug > >> > sources > >> > you cared about. > >> > >> I've mentioned libbfd, which implicitely specifies that i'm using a > >> GNU toolchain. > >> > >> Vincent Torri > >> > >> > Keep in mind you won't be able to look through the system > >> > libraries for things, but you'll be able to look at what you built at > >> > least. > >> > > >> > -eric > >> > > >> > On Mon, Nov 16, 2015 at 12:16 PM Vincent Torri < > vincent.to...@gmail.com> > >> > wrote: > >> >> > >> >> afaik, gnu windows toolchain stores debug informations in DWARF > >> >> format. Am I wrong ? > >> >> > >> >> Vincent Torri > >> >> > >> >> On Mon, Nov 16, 2015 at 8:44 PM, Eric Christopher < > echri...@gmail.com> > >> >> wrote: > >> >> > As a quick note, you're aware that Windows in general doesn't use > >> >> > dwarf > >> >> > right? > >> >> > > >> >> > -eric > >> >> > > >> >> > On Mon, Nov 16, 2015 at 11:26 AM Vincent Torri > >> >> > > >> >> > wrote: > >> >> >> > >> >> >> Hello > >> >> >> > >> >> >> I have begun to write a valgrind-like on Windows, and I use libbfd > >> >> >> to > >> >> >> get the stack trace (file, function and line of a frame). > >> >> >> > >> >> >> I would like to use libdwarf for that. But I need to port libdwarf > >> >> >> to > >> >> >> Windows. > >> >> >> > >> >> >> On the website, it is said to contact this mailing list before > >> >> >> contributing any code. > >> >> >> > >> >> >> So what I suppose to do ? :-) > >> >> >> > >> >> >> regards > >> >> >> > >> >> >> Vincent Torri > >> >> >> ___ > >> >> >> Dwarf-Discuss mailing list > >> >> >> Dwarf-Discuss@lists.dwarfstd.org > >> >> >> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Read an .axf file on windows with LibDwarf
FWIW you can use cmake to compile LLVM for windows with a VS project output. It has a support library for reading dwarf sections, but you may need to do a little bit of work to make sure it can understand the object file reading it if it isn't just a plain ELF file. Feel free to follow up with me or the llvm-dev list if you have any problems. Thanks! -eric On Mon, May 16, 2016 at 11:47 PM Ane wrote: > DavidA writes: > > > > > On 05/16/2016 12:43 AM, Ane wrote: > > > 've seen a lot of webpages to have an idea of what the libdwarf > library > > > can do, but I can't find the way to compile it in windows. The > reason to > > > do this, is that I want to read and understand an .axf file in my C# > > > program that I'm developing in Visual Studio 10 in Windows (I can > use VS15 > > > too). I don't need to debug anything, I only want read an .axf file, > so if > > > there is a way to do this, please I want to know it, and how to do > it. > > > > There is no simple way. At least one organization has done so, but > > their code is not part of the distribution. > > > > I do not know the details of what that organization did. > > I have no idea what a .axf file is. > > > > struct Dwarf_Obj_Access_Methods_s (libdwarf.h) > > is probably involved. > > > > Sorry, I have no further information. > > David Anderson > > > > -- > > From the attic came an unearthly howl. The whole scene had an eerie, > > surreal quality, like when you're on vacation in another city and > > "Jeopardy" comes on at 7:00 p.m. instead of 7:30. -- Roy Ashley > > > > An .AXF file is an ARM eXecutable File which has an ELF/DWARF structure. > I've tried a few libraries (libdwarf, libelf, examples in VC for both of > them, libelfin in c++) and none of them can I compile correctly in > windows (it doesn't matter if there was in VS15 / VS10 / as a makefile > project with MinGW or normal project / just MinGW in command window ... > ). > > I've just finded another library in C# "ElfSharp" and it seems to be > good for reading my .axf file, but I'm looking for decode the DWARF > sections. If anyone could help me, I'm all ears. > > Thanks for the info anyway. > > Ane. > > ___ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Read an .axf file on windows with LibDwarf
On Tue, May 17, 2016, 1:30 AM Ane wrote: > Eric Christopher writes: > > > > > > > FWIW you can use cmake to compile LLVM for windows with a VS project > output. It has a support library for reading dwarf sections, but you may > need to do a little bit of work to make sure it can understand the > object file reading it if it isn't just a plain ELF file. > > Feel free to follow up with me or the llvm-dev list if you have any > problems. > > > > Thanks! > > > > -eric > > > > > > On Mon, May 16, 2016 at 11:47 PM Ane 2u8bcb4tnbuavxtiumw...@public.gmane.org> wrote: > > > > DavidA ...> writes: > > > > > > On 05/16/2016 12:43 AM, Ane wrote: > > > > 've seen a lot of webpages to have an idea of what the libdwarf > > library > > > > can do, but I can't find the way to compile it in windows. The > > reason to > > > > do this, is that I want to read and understand an .axf file in my > C# > > > > program that I'm developing in Visual Studio 10 in Windows (I can > > use VS15 > > > > too). I don't need to debug anything, I only want read an .axf > file, > > so if > > > > there is a way to do this, please I want to know it, and how to do > > it. > > > > > > There is no simple way. At least one organization has done so, but > > > their code is not part of the distribution. > > > > > > I do not know the details of what that organization did. > > > I have no idea what a .axf file is. > > > > > > struct Dwarf_Obj_Access_Methods_s (libdwarf.h) > > > is probably involved. > > > > > > Sorry, I have no further information. > > > David Anderson > > > > > > -- > > > From the attic came an unearthly howl. The whole scene had an eerie, > > > surreal quality, like when you're on vacation in another city and > > > "Jeopardy" comes on at 7:00 p.m. instead of 7:30. -- Roy Ashley > > > > > An .AXF file is an ARM eXecutable File which has an ELF/DWARF > structure. > > I've tried a few libraries (libdwarf, libelf, examples in VC for both > of > > them, libelfin in c++) and none of them can I compile correctly in > > windows (it doesn't matter if there was in VS15 / VS10 / as a makefile > > project with MinGW or normal project / just MinGW in command window > ... > > ). > > I've just finded another library in C# "ElfSharp" and it seems to be > > good for reading my .axf file, but I'm looking for decode the DWARF > > sections. If anyone could help me, I'm all ears. > > Thanks for the info anyway. > > Ane. > > ___ > > Dwarf-Discuss mailing listDwarf-Discuss- > 94Vl1yqA2cm9tDkVm8dgcB2eb7JE58TQ@public.gmane.orghttp://lists.dwarfstd.o > rg/listinfo.cgi/dwarf-discuss-dwarfstd.org > > > > > > > > > > ___ > > Dwarf-Discuss mailing list > > Dwarf-Discuss@... > > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > > > > I think I haven't explained myself very well. I want to do everything in > Windows 7, and as far as I understood about LLVM, is for Unix Systems. I > You have misunderstood. LLVM supports both running on and targeting windows systems. don't need the compiler to go faster, I need just compiling the source > code, or at least, find some code which has no dependency of Unix > libraries. Maybe I didn't understand your idea of doing it, so if it is > so, please could you explain it to me again? Did you mean this about > LLVM http://llvm.org/docs/GettingStartedVS.html ? > That page isn't the best, that's why I suggested mailing llvm-dev with any problems. That said, i think it should work to build for your needs. -eric > Rigth now I'm looking for DWARF info in this library > http://elfsharp.hellsgate.pl/examples.shtml , and I just read a section > content but all of them are bytes and I need to read them as a dwarf > info (and I'm thinking how to decode that part). If I haven't explained > it better, please let me know. > > Thanks for the help, > Ane. > ___ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Does any compiler implement Split DWARF as described in the current DWARF5 draft standard?
On Fri, Feb 3, 2017 at 2:56 PM John DelSignore < john.delsign...@roguewave.com> wrote: > On 02/03/17 17:29, David Anderson wrote: > > On 02/03/2017 12:21 PM, John DelSignore wrote: > >> Hi, > >> > >> I've been poking around looking for Split DWARF producers. As far as I > >> can tell, no compiler or tool chain currently implements Split DWARF as > >> described in the current DWARF5 draft standard. Is that correct? > >> > >> > > gcc did it for DWARF4. I have a couple test objects > > that were contributed for libdwarf testing. > > Are you referring to the vendor extensions GNU added for the DebugFission > flavor of Split DWARF described here < > https://gcc.gnu.org/wiki/DebugFission>? AFAIK, the DWARF4 Standard had no > support for Split DWARF at all. > > > It would be...impossible? to have done DWARF5 > > yet since we made major changes in the last few weeks (CU header > > lengths and contents (contents a bit further in the past), > > for example). > > OK, fair enough. But I guess I'm trying to also figure out where Split > DWARF is headed. Are all of the producer going to converge on DWARF5 > eventually, and if so when? And in the meantime, is it worth supporting the > DebugFission flavor of Split DWARF, and where is that headed? > > Probably on both. Lots of producers already emit the existing split dwarf support and while the changes aren't major they're at least "something". Basically I'd suggest supporting both just on the "there are released compilers that emit something". -eric > > > > > > DavidA. > > ___ > > Dwarf-Discuss mailing list > > Dwarf-Discuss@lists.dwarfstd.org > > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > > > > ___ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] debug_names - what should go in ?
I have nothing to add to what Paul just said :)
This is definitely the intent and what we should do.
-eric
On Tue, Apr 10, 2018 at 10:26 AM Paul Robinson via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> The intent of the index is given pretty plainly in the non-normative text
> at the bottom of p.137; you should be able to look up any unqualified name
> in the index. If the normative text doesn't accomplish that, we have an
> opportunity to improve the spec. J
>
>
>
> FWIW here's my take:
>
>
>
> Enumerations are a bit unusual in that the enumerators are children of the
> enumeration type, but the enumerator names are not qualified by the type
> name (usually—a C++ enum-class should not put enumerators into the index, I
> think). But you need some rule that excludes enumerations that are not
> otherwise "global" (e.g., they are contained in a class or local to a
> function).
>
>
>
> For imported entities, I'd say if the imported entity would have satisfied
> the criteria for inclusion in the index if it had been "inlined" at the
> point where it was imported, then it ought to be in the index.
>
> --paulr
>
>
>
>
>
> *From:* Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] *On
> Behalf Of *David Blaikie via Dwarf-Discuss
> *Sent:* Tuesday, April 10, 2018 12:30 PM
> *To:* Pavel Labath
> *Cc:* dwarf-discuss@lists.dwarfstd.org
> *Subject:* Re: [Dwarf-Discuss] debug_names - what should go in ?
>
>
>
> Yep - sounds like it to me.
>
> I suppose, arguably, one could say that successful name lookups of things
> in the index can be fast, while lookups that fail, or find names not in the
> index may be slow - but that seems unacceptable to me (in many cases "slow"
> would be "prohibitively slow" especially the first time - since it'd amount
> to the non-index case: the consumer having to build its own index from
> scratch)
>
> Maybe Adrian or Eric can talk to how the Apple indexes worked in these
> cases.
>
>
>
> On Tue, Apr 10, 2018 at 9:24 AM Pavel Labath wrote:
>
> On Tue, 10 Apr 2018 at 16:44, David Blaikie wrote:
>
> I'd say any case where a consumer couldn't actually rely on the table to
> do name resolution would be a bug - or at least something that needs to be
> seriously considered/discussed/figured out how the name table can be used
> in those situations.
>
>
>
> Agreed.
>
>
>
> This question can be demonstrated on a simple c++ program
>
>
>
> namespace namesp1 { int var; }
>
> namespace namesp2 = namesp1; // DW_TAG_imported_declaration
>
>
>
> enum enum_type { enumerator }; // DW_TAG_enumeration_type,
> DW_TAG_enumerator
>
>
>
> int main() {
>
> return namesp2::var + enumerator;
>
> }
>
>
>
>
>
> Debugging with gdb (without any indexes), the following 4 expressions
> succeed
>
> 1) namesp1::var
>
> 2) namesp2::var
>
> 3) (enum_type)0
>
> 4) enumerator
>
>
>
> The question is how should an index-aware debugger find the entities
> referenced by expressions 2 and 4 if they are not present in the index?
>
>
>
> They way I see it -- it can't. Which would be a bug in the spec by your
> definition.
>
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] .debug_frame and the base address
Dwarf 5, 7.3.1 "A DWARF expression may contain a DW_OP_addr (see Section 2.5.1.1 on 31 page 26) which contains a location within the virtual address space of the 32 program, and require relocation." On Mon, Sep 24, 2018 at 10:35 AM Robert Harris via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > > > > On 24 Sep 2018, at 16:59, Greg Clayton wrote: > > > > > > > >> On Sep 24, 2018, at 8:44 AM, Robert Harris > wrote: > >> > >> > >> > >>> On 24 Sep 2018, at 15:33, Greg Clayton wrote: > >>> > >>> > >>> > On Sep 24, 2018, at 7:15 AM, Robert Harris via Dwarf-Discuss < > dwarf-discuss@lists.dwarfstd.org> wrote: > > I'd like some clarification regarding what precisely needs to be > relocated relative to > the object load address when interpreting .debug_frame. I'm > interested in versions > 2, 3 and 4. > > I think the only explicit mention of relocation in DWARF 4 is § 6.4.1: > > Abstractly, this mechanism describes a very large table... > ... > The first column indicates an address for every location that > contains > code in a program. (In shared objects, this is an object-relative > offset.) > > Thus adjustments need to be made to only > > An FDE's initial_location field > DW_CFA_set_loc's operand > > Have I missed anything? I see some ambiguity in the definition of > DW_CFA_def_cfa_expression and it's making me wonder if there are any > other occasions when a result would require relocation. > >>> > >>> Any DWARF expression can contain a DW_OP_addr, which has an address > argument, and would need to be relocated. > >> > >> Do you mean that DW_OP_addr's argument should be relocated in all > instances > >> of a DWARF expression, i.e. in other .debug_ sections, or just in the > context of > >> .debug_frame? > > > > I was specifically talking about DWARF expressions in any .debug_frame > info. > > Well, that would preclude relocating the *result* of any DWARF expression > in > .debug_frame. For some expressions, e.g. DW_CFA_expression, the use > of the CFA to initialise the stack implies as much but this would be a > useful > blanket constraint. > > > > But in general, yes, any DWARF expression that contains a DW_OP_addr > might need a relocation for its address argument. > > Are you aware of where in the standard this is documented? It sounds > reasonable > but I'm returning to this after a long time and I don't remember my way > around as > well as I used to. > > ___ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] .debug_frame and the base address
On Mon, Sep 24, 2018 at 10:55 AM Michael Eager via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > On 09/24/2018 09:19 AM, Robert Harris via Dwarf-Discuss wrote: > >> But in general, yes, any DWARF expression that contains a DW_OP_addr > might need a relocation for its address argument. > > > > Are you aware of where in the standard this is documented? It sounds > reasonable > > but I'm returning to this after a long time and I don't remember my way > around as > > well as I used to. > > DW_OP_addr is described in Section 2.5.1.1 of the DWARF 5 Standard: > >2. DW_OP_addr > > The DW_OP_addr operation has a single operand that encodes a > machine address and whose size is the size of an address on the > target machine. > > The most common way in which the machine address is provided as the > operand is by generating a relocatable value pointing to the target > address. This is not really a DWARF specification; it is how > relocations work in assemblers and linkers. > > Yes. This is where 7.3.1 comes in handy :) -eric ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] line table dir/file
Hi Paul, I too remember this discussion and clang's implementation is how I saw this being added when we did. -eric On Mon, Feb 24, 2020 at 11:34 AM Robinson, Paul via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Hmmm. > > When the committee was reworking the file/dir tables for DWARF v5, > one thing that came up was that the root file/directory were *not* > in the .debug_line section, and therefore the line table could not > be interpreted fully without a .debug_info section, because that > was where the root file and compilation directory were kept--not > in the line table itself. Am I imagining this discussion? We > added text to the document specifically describing file/dir 0 and > that they were to be explicitly kept (duplicated from .debug_info) > so that the .debug_line section could be fully dumped even in the > absence of a corresponding .debug_info section. This was the > "strip all but the line table" scenario. > > I can easily believe that nobody *actually uses* file/dir 0, but > that's a different question from what producers are supposed to > produce in v5 and how consumers are supposed to interpret it. > > Offhand it looks like there are three possibilities: > a) Clang got it right and everyone else got it wrong. > b) The spec is ambiguous and we're observing the consequences. > c) Clang got it wrong and everyone else got it right. > > But in all three cases, we need to settle on (i) what the spec > actually says, (ii) does it say what the committee intended, > (iii) if not, what to do about it. > > I don't think we should start with (iii). > --paulr > > > -Original Message- > > From: Dwarf-Discuss On Behalf > > Of David Anderson via Dwarf-Discuss > > Sent: Friday, February 21, 2020 5:40 PM > > To: dwarf-discuss@lists.dwarfstd.org > > Subject: [Dwarf-Discuss] line table dir/file > > > > I've attached a pdf that > > shows some cases of current usage of the line > > table directory and file arrays and of indexes. > > > > clang seems (with my limited access to other compilers) > > the outlier in treating a index of 0 (from file [N] to > > the directory) as > > a 0 origin references. > > Only 0-origin for DWARF5. > > > > So reserving 0 as an index to the directories table > > to mean 'no directory available' would > > seem to be the right course. > > > > The standard (or an errata, if we do such a thing) > > needs works to establish 1-origin for these indexes into > > the directory table and clarifies the 1-origin > > indexes by referencing such in more places > > in the document. > > > > A tar.gz of the test setup is available by email > > if anyone cares. It is about 1 MiB in size (most > > of the size is in two ancient IRIX Elf files).. > > > > David Anderson > > > > ___ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] DWP mixed (DWARFv4/pre-standard + DWARFv5) content
On Mon, Mar 30, 2020, 5:37 PM David Blaikie wrote: > > > On Sun, Mar 29, 2020 at 3:44 PM Cary Coutant wrote: > >> >> > Yep - unless someone has significant objections my plan is currently: >> >> > >> >> > Emit a v5 index with extension/non-standard extra column indexes >> (specifically: DW_SECT_LOC and 9 and DW_SECT_MACINFO at 10). I hope those >> can at least be reserved (like DW_SECT value 2 (originally DW_SECT_TYPES) >> was in DWARFv5) in DWARFv6. & maybe open up an extension space in the >> future. >> >> >> >> That sounds good to me. When I saw that number 2 (debug_types in the >> >> fission extension) was reserved, I originally assumed this was what >> >> had already happened. >> >> The pre-v5 dwp format was just a prototype, accessed via >> --experimental GCC flags, and I don't think we ever intended to >> support mixing pre-v5 dwo files with standard v5 dwo files. I'd >> recommend your original option #1 (invalid/unsupported). Thus, you >> shouldn't need DW_SECT_LOC or DW_SECT_MACINFO. >> > > That'd be really difficult (I think I'd go so far as to say - it wouldn't > be done that way) for an environment like Google (or other large projects) > that want to change the default. It's important not to get into a situation > where the flag flip from v4 to v5 is overridable, so that we can readily > opt-out of v5 on a per translation unit basis if there happen to be a > handful of translation units that trip over uncommon bugs without having to > rollback the whole codebase each time we hit something like that. > > So I'd say at the very least, I think we'll implement a v4+v5 index in our > internal port of binutils/gold dwp and gdb - and I'd really hope to be able > to upstream those for anyone else who might be in a similar situation. > > I guess it's possible we could opt-out of split DWARF and opt out of v5 > for such translation units (though there's currently no flag to undo > -gsplit-dwarf on the command line -ah, there is in GCC (-gno-split-dwarf) > but not in Clang, so we could add that). Does make things a bit awkward, > but not impossible, and seems like in the future we're going to have to > keep backwards compatibility too, so wouldn't be so bad to keep it for v4 > too, would it? > Also anyone having to deal with precompiled objects... > >> >> The .debug_types sections were moved back into .debug_info sections at >> the very last minute, so we just removed DW_SECT_TYPES without >> renumbering the later values. As best I recall, that was just a nod >> towards some compatibility with the prototype format, but it wasn't >> intended to provide for complete compatibility. >> >> I don't believe we ever supported .debug_macinfo in the prototype, so >> I wasn't concerned with the renumbering around DW_SECT_MACRO and >> DW_SECT_MACINFO. >> >> I agree that we should have reserved an extension range for DW_SECT >> values. It's probably safe to pick some arbitrarily large values if >> you need to extend this. >> >> For DWARF-64 support, I truly hoped that we wouldn't ever need it, but >> if it was ever necessary, the mechanism I had in mind was to simply >> replace .debug_cu_index sections with .debug_cu_index_64 sections (and >> likewise for .debug_tu_index). Maybe DWARF v6 will address this. Keep >> in mind that the .dwp can be an ELFCLASS64 object file, and its total >> size can grow larger than 4GB, even if .debug_cu_index can't support >> any section offsets larger than 4GB. >> >> -cary >> > ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] DWARF5 line table file numbering inconsistent
"This margin is too narrow to contain..." ;) I'd like to see the doc - it's easy to believe we've gotten something wrong here.. Might be good to fix this as textual edits rather than waiting on a full dwarf standard release because we're going to run into this a lot if we can't get it sorted quickly as multiple producers all produce something slightly different and incompatible. Thoughts? -eric On Thu, Oct 15, 2020 at 11:38 AM David Anderson via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > I think the following (while not news) needs to be said > simply and directly. > > It is impossible to obey all the DWARF5 rules > on file numbering in the line table > at the same time. They contradict each other, > taking the standard as a whole. > [this consistency issue is solely DWARF5]. > > A simple solution is to say that > the file number value 0 meaning of 'no file' > is eliminated so that part > of Section 2.14 page 50 is invalidated. > So then we have a zero-based file array > along with all references to it. > And declare that the 'file' line table > register defaults to zero (DWARF5 Table 6.4 Page > 153). Then the standard is self-consistent. > (Clang has been using this approach for some time now). > > I created a document documenting all the places > in the standard involving line table file numbering > but this emaill is already long enough. > > David Anderson > > -- > Of course power tools and alcohol don't mix. > Everyone knows power tools aren't soluble in alcohol. > -- Crazy Nigel > > ___ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
