Re: Tips to analyze a project with thousands of files
 

On Sat, 2012-10-20, 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. 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.

The task is almost never to "analyze" something. IME, it's only by
doing actual useful work (changing a feature, doing internal changes
or testing) that you can learn more about a large piece of code.

I have often been in that situation. It's frustrating. But you have
to accept it:

"I cannot understand all of this at once. There are big parts I will
probably never understand. Most of this code is fit for
thedailywtf.com. But I can fix this particular bug, and learn
something while doing it, and the code will be better afterwards."

> 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. Any tip to find out the starting line of an ARM
> project?

Build it and look at the symbol table of the final image. That is
often a good supplement to looking at the source code.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Re: Tips to analyze a project with thousands of files
 

On Sat, 2012-10-20, Jorgen Grahn wrote:
> On Sat, 2012-10-20, 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.
....
> The task is almost never to "analyze" something. IME, it's only by
> doing actual useful work (changing a feature, doing internal changes
> or testing) that you can learn more about a large piece of code.
....

Only now did I see that "Like Learn" didn't say the task was just "to
analyze", but "to analyze ... to fix a bug". So my advice must have
looked a bit strange. Sorry!

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .