[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Heads up for CDT-1.2 branch
|
That is ... another grey area 8-(
Binary parsers are a major performance issue already, since we can not
rely on file extensions nor filenames, only reading the file for the
"!<arch>" the "ELF" etc .. can we be sure of the type.
Imagine with multiples binary parsers, the number of stat() and open(),
we still looking at this.
Seems like there are two ways to deal with this.
The first is for managed builds. (This is what we do, though not with the
current managed builder). If you are building the makefiles, then you know
the toolchain you used to build with. That's the same toolchain you objdump
with.
The second is for user written makefile execution. Here I'd think you read
in the first 1k buffer (or so) ahead of time and go to the different
extension points and let them say "yes" or "no". Give them the buffer and
the file. I'm betting that 9 of 10 can figure it out from the first buffer
which reduces the time from O(num_exes * num_types) to just O(num_exes).
Either way, there is clearly an executable/toolchain database that you are
maintaining that matches executable path with toolchain so that once you've
done it, it's done until you restart the workspace and go scan for binaries
again.
Thanks!
-Chris
