Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #19211

Re: Tips to analyze a project with thousands of files

From Stuart <DerTopper@web.de>
Newsgroups comp.lang.c++
Subject Re: Tips to analyze a project with thousands of files
Date 2012-10-23 13:00 +0200
Organization A noiseless patient Spider
Message-ID <k65tc5$u48$1@dont-email.me> (permalink)
References <k5tbim$ua7$1@adenine.netfront.net>

Show all headers | View raw


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
> client.
>
> 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
> project?
>
> 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 shit-shovelling I would have to do. I 
think a programmer can only do so much shit-shovelling, and I had enough 
of it to last me three livetimes.

Regards,
Stuart

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Tips to analyze a project with thousands of files "Like Learn" <like2learn@live.ca> - 2012-10-19 23:07 -0600
  Re: Tips to analyze a project with thousands of files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-10-20 07:49 +0000
    Re: Tips to analyze a project with thousands of files "Like Learn" <like2learn@live.ca> - 2012-10-21 00:09 -0600
    Re: Tips to analyze a project with thousands of files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-10-21 11:42 +0000
  Re: Tips to analyze a project with thousands of files Öö Tiib <ootiib@hot.ee> - 2012-10-20 09:14 -0700
    Re: Tips to analyze a project with thousands of files "Like Learn" <like2learn@live.ca> - 2012-10-21 00:12 -0600
  Re: Tips to analyze a project with thousands of files ctgqumgf@sharklasers.com - 2012-10-21 01:34 -0700
    Re: Tips to analyze a project with thousands of files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-10-21 11:55 +0000
    Re: Tips to analyze a project with thousands of files "Like Learn" <like2learn@live.ca> - 2012-10-21 22:39 -0600
  Re: Tips to analyze a project with thousands of files Stuart <DerTopper@web.de> - 2012-10-23 13:00 +0200
  Re: Tips to analyze a project with thousands of files drew@furrfu.invalid (Drew Lawson) - 2012-10-24 15:33 +0000
  Re: Tips to analyze a project with thousands of files Werner <werasm@gmail.com> - 2012-10-24 09:29 -0700
    Re: Tips to analyze a project with thousands of files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-10-25 20:44 +0000
  Re: Tips to analyze a project with thousands of files Luca Risolia <luca.risolia@studio.unibo.it> - 2012-10-24 22:42 +0200

csiph-web