This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: known-dwarf.h

Mark Wielaard <> 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.

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

>> 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) /* ... */

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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]