On 07/20/10 08:28 AM, Ali Bahrami wrote:
We're also open to ideas for elfdump to make it more wsdiff-friendly.
I'm guessing that the cost of a single invocation of elfdump isn't
the bottleneck when compared to the cost of running it multiple times.
Do you have a sense of how bad elfdump's overhead is?
Looking at wsdiff, there's a lot of elfdump() activity, and some
intelligence of what sections to diff. Perhaps some of this could
be wrapped into a single elfdump() command.
We have a bunch of options that allow for the pretty printing of
various sections, ie. -d, -r, -y, .... Or, without any options,
elfdump() will pretty-print all the sections it knows of. Basically
these are all non-PROGBITS sections.
Then there was the desire to extract PROGBITS sections, like .text
or .data, so they could be diff'ed individually. Which is how the
-w/-N<file> syntax evolved.
What if we had something like:
-W -N<dir>
where elfdump produced files like <dir>/<filename>.text, etc. And
what if each file was pretty-printed if elfdump() knew how, and binary
dumped if it didn't. This way you'd get all your data in one shot.
But the next issue is which sections to ignore. wsdiff could continue
to decide this, but perhaps elfdump() could be told to ignore any
non-allocable sections (ie, no sh_flags with SHF_ALLOC). These non-
allocable sections are the ones that are most often manipulated with
post-processing (ie, cft, mcs, strip, signatures). These sections
don't contribute to the memory image, and thus don't affect the process.
Some of the stuff in wsdiff I've lost track of. For example, ignoring
the .plt, .rela.bss, .rela-plt ... perhaps there were compiler changes
that resulted in different code relocations that caused these to change,
but there really was no real change to the files "content". I don't
recall. I don't recall the sections_preferred stuff either.
Anyway, this is just me thinking out loud. A single elfdump() invocation
would certainly be faster, but whether a directory of section-files
would allow for more parallelization, or offer an easier more flexibly
environment in which to architect wsdiff I don't know.
Perhaps the wsdiff maintainers have an idea of what would make their life
easier?
Using the existing perl modules might provide you more assistance, but unless
you want to duplicate all the elfdump pretty-printing, you're still left with
calling elfdump.
If this is a complete distraction from the parallelization you are after,
then sorry for the distraction. But as Ali stated, we could probably extend
elfdump() quite easily if we knew what output could make your life easier.
--
Rod.
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
