On 07/21/10 09:26, Rod Evans wrote:
On 7/21/10 12:45 AM, Vladimir Kotal wrote:
Perhaps the wsdiff maintainers have an idea of what would make their
life
easier?
Dunno who is wsdiff maintainer but I think in terms of performance the
ultimate solution (although a bit of a overkill) would be to avoid the
fork()+exec(elfdump) completely. This would require python bindings for
libelf.so (libelfdump.so ?).
Well, it the many fork+exec's could be replaced with one you
might feel it.
elfdump() uses libelf to traverse a file, and liblddbg to
print tables like symbols and relocations (this maintains
consistency between elfdump and ld(1) and ld.so.1(1)
debugging diagnostics). But, elfdump glues together many
things within the file to provide these diagnostics (ie.
relocation records reference symbols, and symbols reference
string tables to get the symbol name). This gluing
together of different elements within the file to generate
one line of diagnostics isn't encapsulated in any library.
I had almost finished typing a reply very much like the above.
elfdump encapsulates a lot of ELF knowledge, and might be harder
to replace than it seems on the surface.
I'd like to know how long wsdiff takes to run, and how much of
that is attributable to elfdump overhead. Is the new parallelized
wsdiff still a big bottleneck in the build process?
- Ali
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
