0

Say I want to (try to) read through and understand a fairly complex piece of code (for example the free software Coreboot firmware code, which can be found here). How can I figure out where the code starts? As in, what is the first line of code that will be executed when the program runs?

I have some basic familiarity with C and I know that C programs usually start with an int main (void) function. So, should I just search through the source code files to find that declaration? Or, is there an easier way to figure this out? Perhaps some software development convention that I'm not aware of?

I'm a Mechanical Engineer by background. I have some familiarity with coding, but not how complex projects like this are structured.

Edit:

This question has been flagged as a duplicate of this question:

How do you dive into large code bases?

I don't agree that it is a duplicate. That question is much more general, about general techniques one can use to familiarize oneself with a large, unknown codebase. My question is much more focused on simply 'How can I find the starting point for the code.' It doesn't look like any of the existing answers to that question directly address that.

Besides, that question was flagged for its poor quality, as being not good or on-topic for the site.

Time4Tea
  • 163
  • 6
  • @gnat to me, that question looks more general. I think my question is more specific and focused: 'Where does the code start?' – Time4Tea Jan 23 '19 at 17:02
  • 1
    To be clear, you're specifically trying to find the first executed line of code in a project, correct? Irregardless of makefile/compiler/system settings/configuration? – Andrew Fan Jan 23 '19 at 18:02
  • 3
    *"So, should I just search through the source code files to find that [main] declaration? Or, is there an easier way to figure this out?"* - How much easier than that do you want it? Note this pretty much depends on the environment where the code will be executed, for some environments, the entry point is not "main", but something else defined by that specific environment. You have to RTFM. – Doc Brown Jan 23 '19 at 18:07
  • @AndrewFan yes, that's correct. As you suggest, it might depend on specific configuration settings. So then, let's say I assume a certain build configuration - how would I go about finding the starting point? – Time4Tea Jan 23 '19 at 18:07
  • @DocBrown ideally, I'd like a nice big billboard with neon lights, saying "Start Here". Thanks for your helpful suggestion, btw. – Time4Tea Jan 23 '19 at 18:13
  • 1
    [Start Here](https://www.coreboot.org/Developer_Manual#coreboot_Overview) – Dan Wilson Jan 24 '19 at 03:02
  • I don't think this is a good question because the codebase which apparently triggered it (coreboot BIOS) is not your typical OS-hosted application, and it only took me two minutes to find the execution flow in the documentation. I don't get the impression that people generally struggle with finding the entry point of an application. – Dan Wilson Jan 24 '19 at 13:36
  • @DanWilson thanks for your comment - it's a fair point. Perhaps I chose a bad example there (I could change it for one that is less well-documented?). I more-or-less just pulled that one out of the air. Is it generally true to say that finding the starting point is harder for a non-OS-hosted program? – Time4Tea Jan 24 '19 at 14:07

2 Answers2

3

The main function on many platforms is defined as int main (int argc, char **argv) or equivalently as int main (int argc, char *argv[]).

But beware of odd conventions on specific platforms. How about int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow).

Also be aware that it is possible to call functions before main, such as static int foo = FooFunc();. In such cases it may be indeterminate which function is actually called first. A sufficiently malicious programmer could do all the work in a static initializer, and make main just a stub.

Simon B
  • 9,167
  • 4
  • 26
  • 33
3

Two other strategies:

  • See the build system: this may define an entry point, or at least make clear which source file is most likely to contain it. It may be specified in linker options or linker scripts (.ld files).

  • See the debugger: often there is a "break after program start" option, which will drop you at the entry point. However that requires you to have setup the project, got it building in debug, and are able to run the debugger.

Coreboot however is unusual, because it's a boot firmware - this won't have a main() and can't easily be run under a debugger!

I guessed that in this case the entry point would be architecture-specific, so I looked in arch/x86 and found bootblock_normal.c which has a main() and bootblock_crt0.S which seems to be the "real" entry point. "crt0" is also a giveaway - that is the conventional name for C pre-main code.

It's worth noting again that because this code is architecture-specific there are several entry points, at least one for each architecture.

pjc50
  • 10,595
  • 1
  • 26
  • 29