Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #19211
| 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> |
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
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