Hi Aaron,
On Thu, 2026-07-09 at 20:19 -0400, Aaron Merey wrote:
> On Wed, Jul 1, 2026 at 8:01 AM Mark Wielaard <[email protected]> wrote:
> >
> > This introduces three new libdw functions dwarf_begin_type,
> > dwarf_begin_elf_type and dwarf_type.
> >
> > When a file contained multiple types of DWARF, plain DWARF, DWO or
> > GNU_LTO, dwarf_begin and dwarf_begin_elf would use the plain DWARF
> > when available, otherwise use the DWO sections and finally the GNU_LTO
> > sections to construct a Dwarf handle. This meant that if a file
> > contained multiple types you would only be able to get one. And you
> > couldn't explicitly say you only wanted a Dwarf handle for a specific
> > type. Also you had no clear way of determining which type of Dwarf
> > handle you got.
> >
> > The new dwarf_begin_type and dwarf_begin_elf_type allow explicitly
> > specifying a specific type of DWARF you want. And the dwarf_type
> > function will return the actual type of DWARF you got.
> >
> > [...]
> >
> > Two remaining issues:
> >
> > - Maybe we want a dedicated DWP type? Currently DWARF_T_DWO covers
> > both single DWO and DWP/multi-DWO types. But this might not be a
> > detail "real" users care about (only possibly useful for eu-dwp).
>
> I'm leaning towards not adding a DWP type because libdw already
> transparently handles DWP. I can't think of anything that a typical
> (non-eu-dwp) user would need a DWO/DWP type distinction for. And even
> if this distinction ends up being important one can always check for
> .debug_{cu,tu}_index.
Yes, that was my conclusion too. Also I added an api (upcoming patch)
to read the .debug_dwp section (if available).
> > - Currently seeing a .debug_dwp section always assumes it is a dwo/dwp
> > file, but it could be a plain DWARF file with a DWP reference. Need
> > to actually inspect the .debug_dwp section to see which it is.
So even though I added an new api for reading .debug_dwp I then
realized the .debug_dwp (and .debug_sup) sections are just
administrativa, they don't really "count", you always need "real" debug
sections to determine which they you are looking at. So I'll just
recognize, but then mark those sections as "auto".
> > +/* DWARF type. Either plain DWARF, split DWARF DWOs or GNU LTO. When
> > + used with dwarf_begin_type or dwarf_begin_elf_type DWARF_T_AUTO
> > + tries to get PLAIN, DWO, GNU_LTO in that order. Enum values have a
> > + numeric value indicating their priority in auto mode. */
> > +typedef enum
> > + {
> > + DWARF_T_AUTO = 0, /* Automatic selection (PLAIN > DWO > GNU_LTO).
> > */
> > + DWARF_T_GNU_LTO = 16, /* GNU LTO (.gnu.debuglto_.debug_*). */
> > + DWARF_T_DWO = 32, /* Split DWARF (.debug_*.dwo). */
>
> If we don't plan on ever adding a DWP type, this comment could be
> expanded to mention that DWARF_T_DWO includes DWP.
Yes, added.
> > + DWARF_T_PLAIN = 64, /* Standard DWARF (.debug_*). */
> > + }
> > +Dwarf_Type;
> > +
> > [...]
> > diff --git a/libdw/libdw.map b/libdw/libdw.map
> > index b45647e6fa4c..404b4c1056a9 100644
> > --- a/libdw/libdw.map
> > +++ b/libdw/libdw.map
> > @@ -411,3 +411,10 @@ ELFUTILS_0.194_EXPERIMENTAL {
> > global:
> > dwflst_sample_getframes;
> > } ELFUTILS_0.193_EXPERIMENTAL;
> > +
> > +ELFUTILS_0.196 {
> > + global:
> > + dwarf_begin_elf_type;
> > + dwarf_begin_type;
> > + dwarf_get_type;
> > +} ELFUTILS_0.194_EXPERIMENTAL;
>
> Should ELFUTILS_0.196 chain on to ELFUTILS_0.193 instead? It's the
> last non-experimental node. The idea of the experimental nodes was to
> keep them separate from the official branch in case we want to remove
> them. Although due to RHEL's ABI guarantees full removal may not
> happen in any case.
O, that makes sense. non-experimental symbol versions should not depend
on experimental symbol versions. So the above is indeed wrong. To use
the new symbols you don't need the experimental ones, you only need the
older stable ones (ELFUTILS_0.193). Thanks. Will change.
> > +int
> > +main (int argc, char *argv[])
> > +{
> > + if (argc < 2)
>
> This should be `argc < 3`.
>
Of course.
Thanks, will make all those changes and post an updated "final"
version.
Cheers,
Mark
