[Ltrace-devel] [PATCH RESEND] Add POSIX Threads prototypes

Роман Донченко dpb at corrigendum.ru
Thu Mar 12 20:57:35 UTC 2015


Petr Machata <pmachata at redhat.com> писал в своём письме Thu, 12 Mar 2015  
00:25:36 +0300:

> Also, you don't want to simply call read_config_file recursively, as
> that would re-read the file every time it's included.  You also still
> want to allow the full suite of overrides that ltrace admits,
> i.e. looking through XDG_CONFIG_DIRS et.al.

I don't think I do, actually! If we do that, then the includer is never  
going to know what
it's including. I.e., if a.conf includes b.conf, and b.conf is overridden,  
then the override
might not contain the stuff that a.conf depends on, so it'll be broken. I  
think we should only
search in a.conf's directory in this case.

> The right way about it is to go through protolib cache, which handles
> all this stuff.  So read_config_file would need to get an argument of
> the type struct protolib_cache *.  An include line would trigger a call
> to protolib_cache_load.  The result would be added to the currently
> loaded protolib by protolib_add_import.

Hmm... I don't really want to include complete protolibs into other  
protolibs, though. Okay, for libc.so.conf and libpthread.so.conf I do, but  
that's an exception, not the rule. For the general case, I envision a  
C-like structure, where there are "header files" with common type  
definitions, but which aren't necessarily complete protolibs themselves.  
Like this:

types.inc:
typedef ldouble = double;

libc.so.conf:
include "types.inc";
ldouble strtold(string, +string*);

; some of libpthread's symbols are duplicated in libc
include "libpthread.so.conf"

lib.so.conf:
include "types.inc";
ldouble sinl(ldouble);

Now, I suppose, we could require the header files to be valid config files  
in themselves (types.inc is), and then we could store them as protolibs in  
the cache, but honestly, I don't see much point in that. They're going to  
be parsed at most once per library, which I don't think is a big deal, and  
if we do cache them, they'll just stay in the cache after all the library  
configs have been parsed, serving no purpose.

Thoughts?



More information about the Ltrace-devel mailing list