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 .
|
Similar Threads
