Re: Tips to analyze a project with thousands of files
On 10/20/12 Like Learn wrote:
> My task is to analyze a legacy firmware project using Qualcomm MDM9X00
> baseband chip with thousands of files (literally) to fix a bug. There is no
> design documents about the project.
Documenting the "overall" design is -- though the most important
documentation artefact of a project -- almost always neglected because
at the time the project was being conceived everybody knew the design by
heart (lotsa meetings and presentations).
After only half a year most of the design decisions will have been
forgotten by the management. Five years later the last of the
programmers who took part in all those kick-off meeting will be
transferred to another project/leave the company.
Everything will run smoothly for another year or two.
Then something real serious bug will suddenly appear and some poor
bugger (e.g. you) will be hired to "simply" fix it in a day or two.
Turns out that even the original project leader is no longer working in
the company and the only ressource of information is the
soon-to-be-retired secretary who could tell you all the funny episodes
about the project but, of course, does not have any technical
understanding about it.
So basically you are faced a situation where your boss dropped his key
into the Hoover dam and hands you a snorkel and a diving mask. Story of
our lives, I guess.
> The project is qriting in C++, halve of
> them are commented in Doxygen format, while the other halve not. I don't
> have the hardware to run the firmware or debugging. The only thing I have is
> a list of debugging outputs of the printfs in firmware collected by the
> I spent one day today and even couldn't find out where the firmware starts.
> Obviously it was not the main function. The comments are not in pure
> English, frustrated.
Been there. I was able to convince my boss to re-write the whole damn
project, but it was only 100KLOC, so it took me only a year to get the
thing working again.
The original code actually used some of the code obfuscating technique
that I read in one of these funny "how to make yourself indispensable"
guidelines. The original author (who could of course not be ascertained
because there were no comments and no source control system) was
apparently worried about memory allocations, so he introduced at lot of
members i1, i2, ..., i15 in a class.
These member variables were then used as substitute for local variables
in the methods of the class (so that the compiler does not have to
allocate too much stack memory). Because each method used those
variables in a completely different way it was impossible to give them a
proper name, so they got the generic i1 name.
Had I known that such a page like dailywtf.com existed at that time ...
> Any tip to find out the starting line of an ARM
> BTW, any suggestion for debugging tools toward Qualcomm MDM9x00? I believe
> it belongs to ARM family and has multiple-processors.
Sorry, can't help you there.
All I can say is to be brave, always use a bit of spit to clean your
scuba mask (helps defogging), and keep an eye open for job
advertisements. I got a pretty good job-offering just recently, but I
turned it down because of all the ****-shovelling I would have to do. I
think a programmer can only do so much ****-shovelling, and I had enough
of it to last me three livetimes.
|All times are GMT. The time now is 10:58 PM.|
SEO by vBSEO ©2010, Crawlability, Inc.