Re: [Dwarf-discuss] PROPOSAL DW_FORM_implicit_const

On 4/23/25 11:25, Cary Coutant wrote: David, As part of this, we rearrange the references from `DW_FORM_implicit_const`, `DW_FORM_addrx`, and `DW_FORM_indirect` to be listed in the order `DW_FORM_addrx`, `DW_FORM_implicit_const`, and `DW_FORM_indirect`. `DW_FORM_addrx`

[Dwarf-discuss] PROPOSAL DW_FORM_implicit_const

# FORMs Implicit Const and Indirect ## BACKGROUND In issue 221114.1 `DW_FORM_implicit_const` and `DW_FORM_indirect` we corrected a mistake in DWARF5 that, in very limited circumstances, forced compilers to emit an abbrev section that could not be scanned (to find abbrev codes) without chaos ens

Re: [Dwarf-discuss] The new Version Scheme for V6.

On 3/28/25 08:30, David Blaikie wrote: I believe the intent is that version numbers are able to be compared numerically. In any case, they are numbers per https://dwarfstd.org/ issues/210419.1.html - "A DW_AT_language_version attribute may be specif

[Dwarf-discuss] The new Version Scheme for V6.

VVMMPP Major version number (VV) × 10,000 + minor version number (MM) × 100 + patch number (PP) (e.g., 30607 for version 3.6.7) https://dwarfstd.org/languages.html So I'm puzzled. As normally represented 3.101.198 is easily understood, but as shown in the explanation line above ... what i

[Dwarf-discuss] Please WITHDRAW issue 240618.1

Please withdraw my open issue 240618.1 . In working on correcting the wording I've found things related to rnglists and loclists handling that are confusing (to me) inconsistencies. I will be asking a few basic questions on this (on dwarf-discuss) as the next step. I suspect there are issues i

Re: [Dwarf-discuss] [UPDATE] 240618.2 rnglists_base missing

On 1/13/25 11:31, David Blaikie wrote: I still think the commentary on the indexes isn't quite right. They're separate from this issue - you'd still need the rnglists base, or have to assume that it's sizeof(header), to go that far into the region described by the index. The index essentially ma

Re: [Dwarf-discuss] Does DWARF 5 specify which DW_LNCT content types are valid for directory entries?

On 1/13/25 11:35, David Blaikie via Dwarf-discuss wrote: I guess Jon is referring to the  16th field in the header, "directories (sequence of directory names)" which uses the same encoding system (but a separate format field, so the directories can have different active fields than the files) a

Re: [Dwarf-discuss] Does DWARF 5 specify which DW_LNCT content types are valid for directory entries?

On 1/13/25 07:17, John DelSignore via Dwarf-discuss wrote: Hi, Section 6.2 (Line Number Information) of the DWARF 5 spec does not seem to constrain which DW_LNCT content types are valid for directory entries, or at least I couldn't find where it does. Are DW_LNCT_directory_index, DW_LNCT_time

[Dwarf-discuss] [UPDATE] 240618.2 rnglists_base missing

# `DW_AT_rnglists_base` missing ## BACKGROUND If a split-full CU uses `DW_FORM_rnglistx`, is a `DW_AT_rnglists_base` required? Apparently not, since in cases I have seen in object files with a single rnglist in `.debug_rnglists.dwo` there is no `DW_AT_rnglists_base`. The operative assumption s

[Dwarf-discuss] Missing a useful reference Figure F.2.3 DWARF5 . [Revised.]

On 1/1/25 15:24, David Anderson wrote: # Loose Ends Table F.2.3 DWARF5 Page 405 "The .debug_loclists.dwo section contains the location lists referenced by DW_AT_location attributes in the .debug_info.dwo section. This section has a similar format to the .debug_loclists section in a non-split obj

[Dwarf-discuss] Missing a useful reference Figure F.2.3 DWARF5 . Reference incorrect.

# Loose Ends Table F.2.3 DWARF5 Page 405 "The .debug_loclists.dwo section contains the location lists referenced by DW_AT_location attributes in the .debug_info.dwo section. This section has a similar format to the .debug_loclists section in a non-split object, but it has some small differences a

Re: [Dwarf-discuss] .debug_cu_index question

Right. Thanks. I will update and repost the document to fix mistakes/lack-of-clarity. Possibly today. On 12/20/24 10:05, David Blaikie wrote: On Fri, Dec 20, 2024 at 9:36 AM David Anderson via Dwarf-discuss mailto:dwarf-discuss@lists.dwarfstd.org>> wrote: The examp

[Dwarf-discuss] .debug_cu_index. Found an answer.

Section 7.3.5 DWARF Package Files page 190 line 30: The DWARF package file also contains two index sections that provide a fast way to locate debug information by compilation unit ID for compilation units, or by type signature for type units: .debug_cu_index .debug_tu_index --- -- Dwarf-

[Dwarf-discuss] .debug_cu_index question

The examples of .debug_tu_index in DWARF5 Section F.2.3 show the hash as computed by Type Signature Computation Section 7.32 and referenced by DW_AT_LOCATION DW_FORM_ref_sig8. Ok. I was thinking of this incorrectly before. It's not visible as a whole-CU index. I think. See pages 412, 413. Th

[Dwarf-discuss] rnglists and loclists and their base addresses

# Overview `.debug_loclists[.dwo]` and `.debug_rnglists[.dwo]` A view from the consumer side. Uses of `DW_AT_rnglistx` and `DW_AT_loclistx` and of the other reated 'x' FORMS is a bit complicated. The issue is that one must find the correct part of the target loclists/rnglists section. We will

Re: [Dwarf-discuss] Proposal: Clarify DWARF Address Range Overlap Rules

On 12/11/24 16:59, Alex via Dwarf-discuss wrote: ## Proposed Changes In Section 2.17 (Location Descriptions), replace the text on p. 53, line 15: From: ``` Bounded range entries in a range list may not overlap. There is no requirement that the entries be ordered in any particular way. ``` N

Re: [Dwarf-discuss] Macros after "#include" does not show up DWARF

On 9/13/24 15:50, Lorenzo Gomez via Dwarf-discuss wrote: int dwarf_init_b(int    /*fd*/,     Dwarf_Unsigned    /*access*/,     unsigned          /*groupnumber*/,     Dwarf_Handler     /*errhand*/,     Dwarf_Ptr         /*errarg*/,     Dwarf_Debug*      /*dbg*/,     Dwarf_Error*      /*error

Re: [Dwarf-discuss] Macros after "#include" does not show up DWARF

On 9/13/24 09:37, Jakub Jelinek via Dwarf-discuss wrote: DW_MACRO_import 0 means include the .debug_macro chunk from offset 0 in the section, which with applied relocations would be endless recursion there. Most likely just dwarfdump doesn't distinguish in that 0x what it really is, it is

Re: [Dwarf-discuss] Macros after "#include" does not show up DWARF

On 9/12/24 11:39, David Blaikie via Dwarf-discuss wrote: Oooh, fascinating. Certainly llvm-dwarfdump has explicit support for sections it expects to be fragmented (multiple sections with the same name, for comdat purposes, etc) - and so llvm-dwarfdump certainly wouldn't dump this correctly (prob

Re: [Dwarf-discuss] Question on Clang 18.1.8 and DW_IDX_parent

On 9/3/24 10:06, David Blaikie via Dwarf-discuss wrote: Some context: https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151/44 https://github.com/llvm/llvm-pr

[Dwarf-discuss] Question on Clang 18.1.8 and DW_IDX_parent

Dwarf5. The Name Table .debug_names Background: 6.1.1.2, page 141 Parent debugging information entry, a reference to the index entry for the parent. This is represented as the offset of the entry relative to the start of the entry pool. Table 7.232 Name index attribute encodings DW_IDX_par

Re: [Dwarf-discuss] Aranges address entry alignment?

On 7/13/24 11:33, Vsevolod Alekseyev via Dwarf-discuss wrote: “This header is followed by a series of tuples. Each tuple consists of an address and a length, each in the size appropriate for an address on the target architecture. The first tuple following the header in each set begins at an offse

[Dwarf-discuss] Proposal: rnglists_base missing

BACKGROUND: References are to DWARF5 unless otherwise indicated. If a split-full CU uses DW_FORM_rnglistx is a DW_AT_rnglists_base required? Apparently not, though in cases I have seen in object files are instances of a single rnglist in .debug_rnglists.dwo . The operative assumption is consumer

[Dwarf-discuss] Proposal for DW_AT_rnglists_base table F.1

BACKGROUND: References are to DWARF5 unless otherwise indicated. The basic issue is that .debug_rnglists is sometimes mentioned as being part of a split-full compilation unit and yet other places say that is incorrect. In other words the standard conflicts with itself. There is clarity in Sec 3.

[Dwarf-discuss] DW_AT_base_types, loclists_base table F.1 incomplete

Issue: Clarification I cannot find any mention of these issues as open in the DWARF6 issues list. Dwarf5, Appendix F, table F.1: DW_AT_loclists_base has a checkmark for conventional but no checkmark for Skeleton and Split. It should have a checkmark for Skeleton. DW_AT_base_types has a che

Re: [Dwarf-discuss] Expression opcode 0xD0

On 4/7/24 10:20, Vsevolod Alekseyev via Dwarf-discuss wrote: I’ve got a crash report that my DWARF expression parser crashed on the following expression blob: 09 03 D0 39 8C That looks like DW_OP_const1s with 3 as the argument, followed by a bogus opcode D0. It’s not a valid opcode and not in

[Dwarf-discuss] TI DWARF extensions

Those interested in DWARF extensions compilers have used will find the public document by Texas Instruments https://www.ti.com/lit/an/spraab5/spraab5.pdf?ts=1705994928599 to be of interest. The folks at the github pyelftools project found this link. David Anderson -- It's not an optical illus

Re: [Dwarf-discuss] Proposal: Allow padding in all tables

On 1/19/24 06:51, Robinson, Paul via Dwarf-discuss wrote: Couldn't the abbrev table simply be padded with 0 bytes? Hmmm... that would appear to a dumper as a series of zero-length tables, I suppose? Would look funny in a dump but it could work. And would be a lot simpler for the producer of cour

Re: [Dwarf-discuss] Enhancement: DWARF Extension Registry

On 12/1/23 16:17, David Blaikie wrote: On Fri, Dec 1, 2023 at 1:43 PM David Anderson via Dwarf-discuss <mailto:dwarf-discuss@lists.dwarfstd.org>> wrote: On 12/1/23 05:24, Ben Woodard via Dwarf-discuss wrote: > My reasoning is that the reason why we are running o

Re: [Dwarf-discuss] Enhancement: DWARF Extension Registry

On 12/1/23 05:24, Ben Woodard via Dwarf-discuss wrote: My reasoning is that the reason why we are running out of vendor defined space is that within in the various vendor spaces the encoding space is consumed by legacy extensions that: 1) were never implemented publicly 2) were implemented but

Re: [Dwarf-discuss] Do Dwarf symbols only use ascii?

On 11/2/23 03:29, Roger Phillips via Dwarf-discuss wrote: I'm currently trying to debug a problem in the dynamorio system where the isdigit function crashes in elftoolchain while trying to parse symbols from dwarf info: https://github.com/DynamoRIO/dynamorio/issues/6161

Re: [Dwarf-discuss] Question about section .debug_aranges

On 10/24/23 06:08, Claudio Eterno via Dwarf-discuss wrote: Hi, I'm taking a look at docs. On dwarf-2.0.0.pdf I see at "7.20 Address Range Table" /This header is followed by a series of tuples. Each tuple consists of an address and a length, each in the size on Dwarf3.pdf is identical.

Re: [Dwarf-discuss] Facing a issue in contents of dwarf debug info section in an ELF file

On 9/25/23 00:11, Kyle Huey via Dwarf-discuss wrote: Most likely the .debug_info section is SHF_COMPRESSED. Try compiling with -gz=none. Also note that there are different approaches that have been used. If the section content starts with "ZLIB" a struct is present and the content is zlib/l

Re: [Dwarf-discuss] Regarding form x not understand by DWARF 2 code[details]

I forgot to mention that https://www.prevanders.net/dwarf.h contains #defines for all the DW_FORM codes known to libdwarf. David Anderson -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Regarding form x not understand by DWARF 2 code

On 4/23/23 07:22, Jnanendra Dewan (C) via Dwarf-discuss wrote: Hi Team, While running Dwarf 2 code we are getting error “This form X not understoodfurther procesing not possible.” So we have seen that here form is unknown. We have handled it inside the code. But we are getting multiple form

Re: [Dwarf-discuss] Wiki list of vendor extensions.

On 3/24/23 13:56, Ben Woodard via Dwarf-discuss wrote: Tangential to Scott's request, one of the requests from the tool developer community that I work with is to add a new wiki article which lists all the vendor extensions for the various compilers. Obviously this would include but not be limi

Re: [Dwarf-discuss] Wiki list of vendor extensions.

On 3/24/23 13:56, Ben Woodard via Dwarf-discuss wrote: Tangential to Scott's request, one of the requests from the tool developer community that I work with is to add a new wiki article which lists all the vendor extensions for the various compilers. Obviously this would include but not be limi

Re: [Dwarf-Discuss] DWARF bitness in loclists, etc

On 6/26/22 05:52, Vsevolod Alekseyev via Dwarf-Discuss wrote: Greetings, I’m involved with a Python DWARF parser, Pyelftools ( https://github.com/eliben/pyelftools/ ). I have a question about DWARF5 and the newly indexed loclists/rnglists sections, please.

Re: [Dwarf-Discuss] Older version of libdwarf on new Linux error 48 (stamp version error)

On 6/2/22 20:32, Paul Redkoles via Dwarf-Discuss wrote: I have an older version of libdwarf (over 10 years). And I'm building it on Oracle 79 with the Intel 2020 compilers. Everything compiles clean (libdwarf and exe that uses the lib), but I'm getting error #48 when calling dwarf_next_cu_header(

[Dwarf-Discuss] clang -flto and LLVMgold.so

A followon To Jan K and David B Feb 1 2022: Binary release on github clang+llvm-13.0.0-x86_64-linux-gnu-ubuntu-20.04.tar.xz does not contain LLVMgold.so So adding -flto just results in the inability compile anything. Suggestions? Thanks. David Anderson -- Overflow on /dev/null, please empty th

[Dwarf-Discuss] Libdwarf release 0.2.0 today

libdwarf-0.2.0 has been released today. See www.prevanders.net/dwarf.html This release was checked by Coverity Scan and found free of defects. API's have changed somewhat. See the end of www.prevanders.net/libdwarfreadme.html for some specifics on the differences from the last version (it was  d

Re: [Dwarf-Discuss] DWARF v5 and "file 0"

On 7/8/21 12:23 PM, Paul Robinson via Dwarf-Discuss wrote: The file table also added an entry for file 0, claiming that it similarly used to mean the primary compilation file. I can't find any evidence that was actually true, though; the default value for the line-number program's "file" registe

[Dwarf-Discuss] DW_AT values unknown to me.

I try to make the dwarf.h  file complete in its set of DW_AT values, including non-standard entries I know nothing about. I recently came across a few whose proper spelling is completely unknown to me. So I made up names. Browser searches revealed nothing so far. /*  From DWARF2 DW_AT_producer G

Re: [Dwarf-Discuss] Callable interface for Fortran "coarray" features

On 12/29/20 2:14 PM, Bishop, John E via Dwarf-Discuss wrote: Fortran defines the TEAM_TYPE as "processor dependent", which means implementation is up to the compiler/run-time implementation. It could be a pointer to a structure; it could be a key to a database, it could be a small integer whic

Re: [Dwarf-Discuss] Callable interface for Fortran "coarray" features

On 12/28/20 11:52 AM, Bishop, John E via Dwarf-Discuss wrote: Different implementations of these features may use very different methods (e.g. MPI, shmem, real shared memory, home-brew message passing, RPC,..).  This means that the structures representing coarray concepts like coarrays, teams, ev

[Dwarf-Discuss] line table file header paper headed to dwarfstd wiki

Mike Eager suggested adding the link right after the libdwarf link on the main page. Should happen shortly. DavidA ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

[Dwarf-Discuss] DWARF5 line table file numbering inconsistent

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 solutio

Re: [Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion

On 9/1/20 10:05 AM, David Blaikie wrote: So the base addresses are in the skeleton and the actual section (rnglists/loclists/str_offsets/str) can go with Split Full (i.e, in a .dwo) if it has no addresses but must go with the skeleton if has addresses. Sorry, I missed a ste

Re: [Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion

On 8/31/20 8:39 PM, David Blaikie wrote: On Mon, Aug 31, 2020 at 8:22 PM David Anderson mailto:dave...@linuxmail.org>> wrote: On 8/31/20 1:03 PM, David Blaikie wrote: > I'd rather go with LLVM's existing interpretation - that strx > encodings used in .dwo do not attempt to use str_of

Re: [Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion

On 8/31/20 8:39 PM, David Blaikie wrote: Hmm... yeah. I guess LLVM implements rnglistx /rnglist_base the same as strx/str_offsets_base. Where it assumes that any *x encoding refers to entities in the .dwo, even in the absence of a rnglists_base/str_offsets_base in the split full unit. I had thoug

Re: [Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion

On 8/31/20 1:03 PM, David Blaikie wrote: I'd rather go with LLVM's existing interpretation - that strx encodings used in .dwo do not attempt to use str_offsets in the skeleton. But I wouldn't mind adding a str_offsets_base to the split full unit to make it clear - this would be consistent with rn

[Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion

I has occurred to me that simply restricting skeleton CUs to use DW_FORM_string or DW_FORM_strp would restore the unique meaning of DW_AT_str_offsets_base to apply to the dwp  (letting non-skeleton CUs use DW_FORM_strx1 etc ).  With seemingly little impact on overall size. DavidA. ___

[Dwarf-Discuss] Confusion about .debug_str_offsets[.dwo]

If a DW_UT_split_compile in 'test.dwp'   has a compilation unit  DW_TAG_compile unit   with strings and referencing via DW_FORM_strx1   And there is a test.dwp with a .debug_str_offsets.dwo   the compile unit will not have a   DW_AT_str_offsets_base (by sec 3.1.3)   but the DW_AT_str_offsets_base

[Dwarf-Discuss] How many sections? 36

To productively read DWARF comprehensively (DWARF2  and later) it is useful to access the following  36 sections. Some of them non-standard. ".debug_abbrev", ".debug_addr", ".debug_aranges", ".debug_cu_index", ".debug_frame", ".debug_funcnames", ".debug_gnu_pubnames", ".debug_gnu_pubtypes", ".d

[Dwarf-Discuss] A question about .debug_rnglists

I am puzzled. DWARF5,  Sec 3.9, Declarations with Reduced Scope. Page 94. = quote from the document: b) If the address range of the containing scope is non-contiguous (see 2.17.3 on page 52) the value of this attribute is the offset in bytes of the beginning of the address range for the s

[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.

[Dwarf-Discuss] line/dir tables and indexes from a few compilers

I  inspected the details of the line table and indexes for a few examples. I don't know if anyone will be able to read this sensibly. The IRIX cases are, of course very old. even the oldest compilers shown here decided to put the source-file-name into file[0], probably because the V2 standard

Re: [Dwarf-Discuss] DW_AT_decl_file etc understood now. Question answered.

February 18, 2020. Lets see if we can get a complete picture of the indexing into the line table header directory/file names tables. The conjecture at the end of this suggests that all places with an actual file/directory number or index should be 1-origin, reserving 0 to mean no file named. Th

[Dwarf-Discuss] DW_AT_decl_file etc understood now. Question answered.

A bit of thought, and it becomes clear. Since 0 is a reserved (and always has been) value for DW_AT_decl_file the numbers used by the compiler must start at 1. So to index into the array of names from the line table header make sure your value is greater than zero and subtract 1 from the DW_AT_de

[Dwarf-Discuss] The DWARF5 line table header

The question that seems to arise, in the DWARF5 standard, is "How does DW_AT_decl_file entry refer to primary source file?" The primary source file is index 0 in the file header table array of strings. But by 2.14 no DW_AT_decl_file index can refer to that name.  Unless saying 'no source line has

Re: [Dwarf-Discuss] variable locations - safe use as lvalues

On 1/21/20 11:18 AM, Greg Clayton via Dwarf-Discuss wrote: [...] Presumably, a debugger could check that location lists do not overlap. This could nevertheless be a valid heuristic to detect the case. the "llvm-dwarfdump" binary in llvm.org  has a "--verify" option that lo

Re: [Dwarf-Discuss] split dwarf, dwo, package files

On 7/25/19 8:12 AM, David Blaikie wrote: > > No  examples in F.2 F.3  show the corresponding compllation-unit > header > unit_type.   Which leaves open the question of what the > compilation-unit > header unit_type is in the examples. > > > Are you uncertain as to which unit_typ

[Dwarf-Discuss] split dwarf, dwo, package files

I've noticed that the documentation of split dwarf and the various CU header unit codes has a possible deficiency. For example, in sections F.2 and F.3 (examples, not the standard, but easier to understand my remark in this context),  It has various mentions of signatures and has short compilation

[Dwarf-Discuss] dwarfdump libdwarf on mach-o and PE object file DWARF.

dwarfdump/libdwarf can work on mach-o dsym objects and on gcc-generated DWARF in PE objects (as well as Elf objects), but one has to get the latest from sourceforge. See https://www.prevanders.net/dwarf.html None of the released libdwarf '*.tar.gz' versions have such support at this time. Buildi

[Dwarf-Discuss] dwarfdump and compression. On sourceforge.

A new dwarfdump/libdwarf version on sourceforge is available for anonymous git clone. It prints the type of compression and the compression factor for each compressed section that's being reported. The compression factors of the test cases I happen to have range from 0.8 (inflation) to nearly 10.

[Dwarf-Discuss] dwarfdump: compressed sections: wait a bit

Oops. The sourceforge version is...an improvement, but not entirely correct in showing section/compression information with the section name. Another version should arrive tomorrow, Monday, Aug 6 2018, on sourceforge. Sorry about the premature announcement. DavidA. __

[Dwarf-Discuss] dwarfdump and compressed sections

Since recognizing compressed sections and reporting proper section names came up recently here I thought it appropriate to mention the following: The new as of a few minutes ago libdwarf (dwarfdump) on sourceforge  reports the actual section name from the object file (in all cases unless I misse

Re: [Dwarf-Discuss] armcc DWARF

On 05/23/2018 10:54 AM, Richard Earnshaw wrote: >> So, given two .debug_info and two .debug_line,  the only place I can >> think of that links >> the pieces together (ie right .debug_line from a .debug_info) as >> intended would be  relocation information. >> Similar for .debug_abbrev. >> Is that t

Re: [Dwarf-Discuss] armcc DWARF

On 05/23/2018 01:56 AM, Richard Earnshaw wrote: > It's perfectly legal to have multiple sections with the same name in an > ELF file. All relevant inter section data is conveyed by the section's > unique index. Having identical names for sections is important for > getting link ordering correct.

Re: [Dwarf-Discuss] armcc DWARF

On 05/22/2018 05:07 PM, Michael Eager wrote: > The thinking may be that if the linker is going to coalesce like- > named sections from multiple object files, it might as well do > the same for like-named sections in the same object file. Yes, that is what the armcc linker does, the final executabl

Re: [Dwarf-Discuss] armcc DWARF

On 05/22/2018 04:18 PM, Michael Eager wrote: > On 05/22/2018 02:33 PM, David Anderson via Dwarf-Discuss wrote: >> >> I have been given a tiny object file  created by armcc >> using DWARF and things make no sense to me so far. >> >> dwarfdump (and libdwarf)

[Dwarf-Discuss] armcc DWARF

I have been given a tiny object file  created by armcc using DWARF and things make no sense to me so far. dwarfdump (and libdwarf) use the SHT_GROUP section data to associate sections to their group.  This is a .o, not a fully linked executable or shared-library. (libdwarf assigns group numbers

Re: [Dwarf-Discuss] The .debug_str_offsets section and libdwarf/dwarfdump

On 04/16/2018 09:01 AM, David Blaikie wrote: > Adding a few folks working on Clang's DWARF5 functionality to see if > this is a known bug (David Anderson mentioned it may've come from > Clang r327823) and/or has been fixed. > > Perhaps a minimal example that produces this behavior/bug would be > us

[Dwarf-Discuss] The .debug_str_offsets section and libdwarf/dwarfdump

I've just pushed a new version of libdwarf/dwarfdump to sourceforge. I mention this here  because at least one compiler version is emitting an incorrect .debug_str_offsets section (I believe). You can get the source with    git clone git://git.code.sf.net/p/libdwarf/code The new  dwarfdump option