Re: known-dwarf.h

[Mark Wielaard <mjw at redhat dot com>]

On Wed, 2015-03-11 at 14:41 +0100, Petr Machata wrote:
> Mark Wielaard <mjw@redhat.com> writes:
> 
> > On Tue, 2015-03-03 at 13:46 +0100, Petr Machata wrote:
> >> known-dwarf.h is an extremely handy header file.  I regularly find
> >> myself replicating it in my ELF/DWARF-related projects.  In dwgrep
> >> I simply copy over known-dwarf.awk as such and generate the header
> >> myself.
> >
> > And you have a known-elf.awk. elfutils really should steal that one.
> > (Or just completely adopt your dw-tools :)
> 
> Yes, I actually have that on my TODO before I disappear.

For others, so you aren't surprised by future proposals from Petr.
We discussed this a bit on irc. Petr has a couple of tools based on
elfutils written in C++:
https://github.com/pmachata/dwlocstat
https://github.com/pmachata/dwgrep
It might make sense to integrate (parts) of these into elfutils as new
tools. Especially since Petr will soon have less time to work on them,
so we can maintain them together. As a start Petr is looking at adding
the C++ libdw/libdwfl iterators he is using to elfutils. We could export
those as new public interface for any elfutils based C++ project use, or
first use them only internally for new elfutils tools written in C++.
If that works out then we can look at merging dwlocstat adding C++
detection to configure and build it as optional tool.

> >> Obviously that's not ideal.  Could known-dwarf.h be shipped?  In
> >> dwlocstat I really only use it to convert constants to strings
> >> representing their names
> >
> > We probably should just introduce real string functions. They are useful
> > on their own. I had a proposal for them some time ago. I'll find them
> > and post a proposal. And maybe we can add similar ones based on
> > known-elf.
> 
> Yes, that would go a long way I think.

OK. I'll work on that then.

> >> but in dwgrep I actually need known-dwarf.h,
> >> as I do some more intricate per-constant processing.
> >> 
> >> Opinions?
> >
> > I am not entirely against it. But I am somewhat hesitant because it is
> > hard to define what interface we really are exporting with them.
> > Currently they really are implementation details. And they are not
> > completely consistent. There are "bare" constant KNOWNs and others with
> > DESCriptions. Some even mix the two. So we should first decide which to
> > export and make them consistent (never or always include the description
> > string). And there is no documentation for them. There should at least
> > be a description of how to use them correctly.
> 
> So the status quo is as follows.
> 
> Elfutils takes up the following names:
> 
> - a bunch of X-macros of the form ALL_KNOWN_DW_<X> (Which we shoud
>   probably rename to DWARF_ALL_KNOWN_DW_<X>).  These are intended for
>   user consumption.
> 
> - implementation callbacks ONE_KNOWN_DW_<X> and ONE_KNOWN_DW_<X>_DESC
>   (Which we should rename to DWARF_*).  Those are implicitly taken,
>   reserved for use in calling convention, even though they are not
>   exported as such.
> 
> The calling convention of a DWARF_ALL_KNOWN_DW_<X> is then as follows:
> 
> #define DWARF_ONE_KNOWN_DW_<X>(SHORT, LONG) /* ... */
> #define DWARF_ONE_KNOWN_DW_<X>_DESC(SHORT, LONG, DESC) /* ... */
> DWARF_ALL_KNOWN_DW_<X>
> #undef DWARF_ALL_KNOWN_DW_<X>_DESC
> #undef DWARF_ALL_KNOWN_DW_<X>
> 
> Always.  Whether any given KNOWN set does or does not use _DESC
> callbacks is an implementation detail.  All callbacks could be to _DESC,
> or none of them could be.  Personally I don't see that as a problem, but
> I wouldn't be against making it simpler one way or another.

I would much prefer to make this consistent, so you only have to define
either DWARF_ONE_KNOWN_DW_<X> or DWARF_ONE_KNOWN_DW_<X>_DESC. And IMHO
the DESC variant only makes a little sense with DW_LANG. And even there
I think the description is slightly questionable.

> Another possibility would be to convert the X-macros to normal function
> entry points:
> 
> int dwarf_all_known_dw_<x>(int start,
>                            int (*cb) (char const *short, char const *long,
>                                       char const *desc, void *data),
>                            void *data);
> 
> SHORT, LONG and DESC would have guaranteed lifetime of activation of CB,
> DESC could be NULL, and dwarf_all_known_dw_<x> would return a restart
> token like we do elsewhere in elfutils.
> 
> That would disallow e.g. creating enums and switches programmatically.
> It would also not scale well to the ELF constants, where there are often
> per-PROC and per-OS constants, so the interface is more complex and
> relies on macros quite a bit more.  So I'm still in favor of Roland's
> original X-macro solution, plus perhaps a handful of tweaks.

Agreed.

Cheers,

Mark