[Ltrace-devel] Getting prototypes from debug information

[Petr Machata]

Dima Kogan <lists at dima.secretsauce.net> writes:

> Petr Machata <pmachata at redhat.com> writes:
>
>> Dima Kogan <lists at dima.secretsauce.net> writes:
>>
>>> ltrace already uses libdw, so I'm assuming either this is not possible,
>>> or it's on somebody's short-term todo list. Any thoughts about it?
>>
>> It uses it optionally for unwinding, yes.  It could use it optionally
>> for prototype retrieval as well.  This idea has crossed my mind in the
>> past, and I wouldn't oppose patches that extend ltrace into accepting
>> debuginfo if available.
>
> OK. I have a version that works for some value of "works". The tree is
> here:
>
>  https://github.com/dkogan/ltrace

843db224 looks reasonable.

Regarding 403a1092:

- getType, getBaseType, etc. are not properly capitalized for ltrace
  functions.  Please make them get_type etc.

  Also we don't put spaces inside parentheses.  A function definition
  should look like this:

        +static enum arg_type getBaseType(Dwarf_Die* die)

  if, while and switch should look like this:

        +	if (encoding == DW_ATE_signed_char || encoding == DW_ATE_unsigned_char)

  What we are using is very close to what Linux kernel coding style
  looks like.

  Also keep your lines at 80 characters at most.

- in getBaseType, you use case sizeof(int) and case sizeof(long).  That
  will fail to compile on machines with four-byte int and long.

  I think it would be reasonable to support DW_ATE_complex_float and
  DW_ATE_boolean (which will be just an int with a boolean lens) and
  DW_ATE_address (an int with a hex lens) as well.

- attr_numeric needs to be able to signal error somehow else than by
  returning 0, which is a valid value for many of the attribute
  domains.  Possibly make it

        int attr_numeric (Dwarf_Die *, unsigned name, uint64_t *valp);

  and return 0 for success and a negative value for failure, which is
  how functions in ltrace commonly behave.

- in getEnum, you assume that the underlying type is INT.  That may not
  be the case.  In C++11, you can actually choose the underlying enum
  type.  DW_TAG_enumeration_type's DW_AT_type (if present) will point to
  that underlying type.

I didn't get further, and need to leave now, so will get back to you
later in the week (hopefully tomorrow).  The overall work is fine, it
just needs some expansion and a bit of coding style grooming.  (And the
leaks, obviously, I'll write about that more later.)

Thank you,
PM