Thanks for working on this. I haven't reviewed your changes, but I wanted to do a quick comparision with the llvm output so I tried running dwarfdump on a file here and I get output like:

...
                    DW_AT_high_pc               <offset-from-lowpc>348
                    DW_AT_macro_info            Macro info: Start include file on line 0:  /object/testfiles/dwarf/base.cpp< 1><0x0000002e>    DW_TAG_variable
                      DW_AT_name                  sarr
...

For reference, llvm-dwarfdump simply gives the offset and lists the macinfo contents elsewhere:

...
              DW_AT_high_pc     (0x000000000000128c)
              DW_AT_macro_info  (0x00000000)

0x0000002e:   DW_TAG_variable
                DW_AT_name      ("sarr")
...

.debug_macinfo contents:
0x00000000:
DW_MACINFO_start_file - lineno: 0 filenum: 1
  DW_MACINFO_define - lineno: 1 macro: SIZE 10000
DW_MACINFO_end_file
DW_MACINFO_define - lineno: 0 macro: __llvm__ 1
DW_MACINFO_define - lineno: 0 macro: __clang__ 1
...

Note that in addition to missing a line break, the gimli output only gives one line of the macinfo data, whereas there are many more lines that would be useful to see. So I think the way llvm-dwarfdump does it is better. It's also better to simply list the constants and arguments (such as DW_MACINFO_start_file) instead of converting it to a description (such as "Start include file").

I just updated my branch:
Your comment made me realize that I had misunderstood the spec, and was missing most of the macinfo entries.
The DW_AT_macro_info attribute actually points to a list of items which is terminated with an end of unit item.

As a result, i changed get_macinfo(offset) to return an iterator over the items found starting at the offset.
I also modified dwarfdump to use this iterator to print all of the items. Unlike llvm-dwarfdump, they are printed inline with the DIEs, but the formatting should be generally improved compared to my first version..

New update - as far as I can tell I've addressed all of your comments.

The module is renamed to macros since macro is reserved.
I also switched to a FallibleIterator as you requested. This resulted in the addition of several #[cfg(feature = "fallible-iterator")] guards, so .debug_macinfo is not usable without this feature. That doesn't bother me much though, since I've never disabled this anyway.

The style used in this crate is to always expose a next method on the struct that isn't part of any trait implementation, and then use the fallible-iterator feature to control the existence of only the FallibleIterator implementation. The next method in that trait implementation is simply a one liner to call the other next method (they both have the same signature).

Oh, I see. In that case, what is the benefit of the fallible-iterator crate?

The FallibleIterator trait provides many more methods that may be useful for working with the iterator, such as for chaining adaptors. I personally rarely use them, but occasionally they can make code simpler.

In case you missed it - my last push yesterday changed the iterator implementation, so fallible-iterator is no longer required.

Done!

       text: macro_text,

Oof. That's the result of trying to automatically rename through rust-language-server, and I didn't check the diff afterwards.
Sorry for that!

It's fixed now.