[Ltrace-devel] Getting prototypes from debug information

Petr Machata pmachata at redhat.com
Sun May 11 21:12:21 UTC 2014


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

>> This doesn't seem right.  dwfl_nextcu should go through all CU's of the
>> whole Dwfl--i.e. if you add two Dwarf-based libraries to a process, it
>> would iterate the former one twice.  Or maybe I don't quite grasp how
>> your code works.
>
> I'm not trying to do anything noteworthy here; just iterating through
> all the compile units. You're saying that if a process that uses two
> libraries, this could would look through those libraries twice? I don't
> understand the issue you're describing.

My mistake, I thought we have a Dwfl per process, but we have one per
library.  Having it stored at process would perhaps fit better with the
overall design of Dwfl, but I guess there's no bug as things stand now.

>> Is there a reason not to just use uint64_t for encoding?
>
> Nope. Typo.

Then this doesn't need the cast ;)

@@ -200,7 +200,7 @@ static bool get_integer_base_type(enum arg_type *type, int byte_size,
 // support a particular type (or an error occurred), I regturn ARGTYPE_VOID
 static enum arg_type get_base_type(Dwarf_Die *die)
 {
-       int64_t encoding;
+       uint64_t encoding;
       	if (!get_die_numeric((uint64_t*)&encoding, die, DW_AT_encoding))
               	return ARGTYPE_VOID;

But that's a detail.

One last thing.  Can you please:

$ git remote add debian git://git.debian.org/git/collab-maint/ltrace.git
$ git fetch debian
$ git rebase debian/master
$ git push -f

... so that I can merge cleanly, without the merge commit?

Thanks,
PM



More information about the Ltrace-devel mailing list