[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