Re: missing #include in libdw.h?
On Wed, 2017-10-04 at 19:07 +, Bill Williams wrote: > Works for me. This showed up on my desk from a broken configuration, > but I figured I’d best pass it upstream too. :) Thanks. I pushed this to master.
[Bug tools/22250] readelf should support --dwarf-start and --dwarf-depth
https://sourceware.org/bugzilla/show_bug.cgi?id=22250 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- For reference this is the binutils objectdump man page documentation for these two options: --dwarf-depth=n Limit the dump of the ".debug_info" section to n children. This is only useful with --dwarf=info. The default is to print all DIEs; the special value 0 for n will also have this effect. With a non-zero value for n, DIEs at or deeper than n levels will not be printed. The range for n is zero-based. --dwarf-start=n Print only DIEs beginning with the DIE numbered n. This is only useful with --dwarf=info. If specified, this option will suppress printing of any header information and all DIEs before the DIE numbered n. Only siblings and children of the specified DIE will be printed. This can be used in conjunction with --dwarf-depth. You can specify "the DIE numbered n" as decimal or 0x hexadecimal. It seems it isn't really the "number" but the first DIE starting after the given offset from the start of the section data. Also it suppresses printing of the actual CU headers (which would make it hard with the output format of eu-readelf to see where a CU starts/ends). It will just continue printing DIEs till the end of the section. Which properties of the above are important to you? Is the given selection mechanism of which DIEs to print the most convenient? Is it important to suppress header printing? Since this really is about printing something after an offset from the start of a section, should it be extended to other debug sections? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/22250] readelf should support --dwarf-start and --dwarf-depth
https://sourceware.org/bugzilla/show_bug.cgi?id=22250 --- Comment #2 from Mark Wielaard --- Addition. "the special value 0 for n" also restores printing the CU headers. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/22250] readelf should support --dwarf-start and --dwarf-depth
https://sourceware.org/bugzilla/show_bug.cgi?id=22250 --- Comment #3 from Mark Wielaard --- Another addition "depth" starts counting from zero. Zero usually is the first DIE (compilation_unit or partial_unit). Specifying --dwarf-depth=0 will only print the Compilation Unit headers, followed by a blank line and no ... markers. Unless --dwarf-depth is given with a non-zero argument, then only a blank line is printed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/22250] readelf should support --dwarf-start and --dwarf-depth
https://sourceware.org/bugzilla/show_bug.cgi?id=22250 --- Comment #4 from Tom Tromey --- (In reply to Mark Wielaard from comment #1) > Which properties of the above are important to you? > Is the given selection mechanism of which DIEs to print the most convenient? > Is it important to suppress header printing? > Since this really is about printing something after an offset from the start > of a section, should it be extended to other debug sections? I implemented this stuff in objdump to support browsing DWARF in Emacs. The Emacs mode dumps the "outline" of the DWARF into a buffer, then you can click on a '...' to get more data there. That explains why header suppression is done... However lately I wanted to use this with eu-readelf to track down that bad DWARF bug: https://github.com/rust-lang/rust/issues/44412 In that case I wouldn't care so much about the headers. But really it would be nice to have it all so that I could port the Emacs mode to use eu-readelf. -- You are receiving this mail because: You are on the CC list for the bug.
