[Lsb-infrastructure] some conflicts when running libtodb2

[Denis Silakov]

You've touched a real libtodb2 problem - readelf output parser looses 
information about 'type of type' and this leads to collision in cases 
when we have, for example, struct and typedef to this struct with the 
same name.

In such cases we actually need both typedef and struct; but at the 
current state of art libtodb2 can give us collisions like 'typedef to 
itself' or 'members of typedef'.

Surely, parser should be improved to handle this correctly. However, at 
the moment I'd suggest you to try an alternative way of obtaining data - 
using headers, not debug info.

I've pushed the alpha version of the new tool to bazaar (headertodb2 
subfolder of libtodb2), and some examples are now located on our wiki:

http://ispras.linuxfoundation.org/index.php/Headers_Analysis_Tool

In general, this new tool should be used in combination with other 
libtodb2 scripts; it just provides a new way of data collection. It also 
contains new 'prepare_sql.pl' script which can be used to create 
id-independent SQL (and it works both on files obtained by readelf 
output parser and on files obtained using the new headertodb2.pl 
script). The other advantage of prepare_sql script is that it allows to 
perform 'library updates' - i.e. it checks which elements are already 
present in the database, and creates SQL to add only the new ones.

We've actually used this new tool to upload cairo - see example on the 
wiki. At a first glance, it looks like libsane and libXext can also be 
processed by the tool (at least it succeeds with data collection/upload, 
we didn't try to generate headers or tests).

Sorry for the lack of documentation - the tool is still under deep 
development and we are experimenting with different libraries. But I 
hope three examples on wiki can be useful. You can also call 
'headertodb2.pl --help' to get the list of possible options with 
descriptions.

However, it should be mentioned that some libraries (NSS is the last 
example) have rather tricky headers (e.g. headers should be included in 
a specific order, combine stuff that belongs to different libraries, 
etc.). In this case it is actually more simple to use readelf than to 
spent hours on finding out correct options for headertodb2.pl.

Wichmann, Mats D wrote:
> When running the get_int_info.pl step of libtodb on libXext,
> I see this complaint:
>
> Type collision for name PS_FontInfoRec: Typedef vs Struct
> Type collision for name PS_FontInfoRec: Struct vs Typedef
> Type collision for name xMbufBufferInfo: Typedef vs Struct
> Type collision for name xMbufBufferInfo: Struct vs Typedef
> Type collision for name const char *[1]: Const vs Array
>
>
> The first of these is actually odd in the specdb now:
>
> $ grep PS_FontInfoRec *
> Type.init:INSERT INTO `Type` VALUES
> (16989,'PS_FontInfoRec','Struct',961,'',NULL,'Unknown','Unknown','Unknow
> n',NULL,0,0,'libfreetype',0);
> Type.init:INSERT INTO `Type` VALUES
> (16990,'PS_FontInfoRec','Typedef',961,'',NULL,'Unknown','Unknown','No',N
> ULL,0,0,'libfreetype',0);
>
> That is, there are already two entries for it.  This is
> presumably due to the odd definition:
>
> typedef struct  PS_FontInfoRec {
> <snip>
> } PS_FontInfoRec, *PS_FontInfo;
>
>
> xMbufBufferInfo is similar, even though it's not something
> subject to this import it's still in the library so it's
> seen, I guess (this one is not in the DB now):
>
> typedef struct xMbufBufferInfo {
> <snip>
> } xMbufBufferInfo;
>
>
> Not as sure about the final one.
>   


-- 
Regards,
Denis.