[Ltrace-devel] Getting prototypes from debug information

[Petr Machata]

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

> Petr Machata <pmachata at redhat.com> writes:
>>
>> So this is the result of my advice to only look to immediate protolib
>> when looking up prototypes.  It seems you need to look recursively after
>> all.  (Which should just mean passing true to
>> protolib_lookup_prototypes.)
>
> Passing true to protolib_lookup_type() makes it work the way one would
> expect. Passing true to protolib_lookup_prototypes() doesn't make it
> work. This isn't surprising, I think. Should I commit this change

No it isn't, I mixed them up.

> (passing true to both), or was this just a suggestion for testing? I'm

The change involving protolib_lookup_type(plib, name, true) looks right
to me, and if it fixes the problem, so much the better.  This would be
nice to have as a separate patch, as it's an isolated fix independent of
your larger work.

> a bit concerned about this treating the type namespace as global, even
> though it isn't. What would happen if two different DSOs define an
> identically-named type that isn't actually the same? Can looking for
> exports get confused by this?

Passing true to protolib_lookup_{proto,}type just means to look through
imports in addition to the immediate prototype library, not to other
prototype libraries sa well.  So they are not global per se.

But whatever is in .ltrace.conf is global, so that a user can put in
whatever they want and just have it appear in appropriate places.

About the clashes in general... note that when looking for a prototype
of a PLT call, we do look through all the prototype libraries in the
process, so in a sense, the namespace _is_ global.  Then again, any
exported symbol better be defined in one place only.

>  void FILEtest( FILE* a, const FILE* b );
>
> A lens that does what I want is
>
>  void FILEtest( void*, void* );

(BTW, this is a prototype, not a lens.  A lens is a way to look at a
piece of data.  So hex or enum are lenses, because they take the raw
underlying integer, and format it in interesting ways.  Similarly a
string is a lens, because it formats pointers or arrays in interesting
ways.)

> But I'd like to achieve this with some sort of lens typedef on FILE. Is
> this possible? Or more to the point, what would be the most useful

"typedef void FILE;" should work.

> ltrace output for a FILEtest() call, and how should it be implemented?

The most useful way would be to show a file name, I guess.  ltrace.conf
is not expressive enough to code this logic, but it can't always be done
anyway, for streams opened by fdopen.

So the next best thing is the file descriptor.  But that can't always be
done either, I suspect, for streams returned by fmemopen and the like.

That's the reason I just keep it as a void*, the pointer ends up being
the most meaningful identifier of each stream, even though the directory
counterpart DIR actually shows the file descriptor.

> I think this all works sufficiently now for me to get the details ironed
> out (memory, error handling), so I'm going to be looking at that next.

Cool.

Thanks,
PM