How do I find my program's main(...) function?

Question

Hi,

I am currently porting a project with a few hundred code files and dependencies onto several third-party libraries to Mac Os. I've finally gotten to the point where the program compiles without warnings or errors, but it does not seem to execute my own main function.

Instead it seems to execute some other main function which seems to belong to a third party. This function writes some diagnostic-looking data to the console and exits afterwards:

(gdb) continue
Current language:  auto; currently c++
//
// This is an automatically generated file.
// Do not edit.
//

const unsigned short expTable[] =
{
    0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 
...
    0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 
};

Debugger stopped.
Program exited with status value:0.

I can't use the debugger to find out where this main function resides because, while the stack trace seems valid, gdb doesn't show me the correct line number and file name for each stack entry (See this unsolved question for details).

The search took several minutes to complete, but did not return any results.

My project is using SDL among other libraries, but I am award of SDL_Main() and the underlying problems and have built my project on top of a perfectly fine working SDL project template. So I am quite sure that my own main function is valid.

Do you have any idea what might be going wrong? I'm currently out of ideas on how to find and remove the rogue main function.

Thanks,

Adrian

EDIT: As I just found out, I made a mistake while searching file files with the string "This is an automatically generated". I just found several dozen files with the same string, all belonging to FreeImage, one of the third party libraries I am using. So, the problem seems to be related to FreeImage, but I am not still not sure how to proceed since I have compiled Freeimage as a library with the enclosed MacOs makefile and included only the library. I will try to rebuild a newer version of FreeImage and see it if that fixed my problem.

Answer 1

Did you try running your executable through nm? It might be able to give you some hints. I wouldn't think it'd be possible to link a program with more than one globally visible function named main(), not sure how that manages to happen.

Answer 2

Could it be an initializer for a static object that fails before your main() is called?

Answer 3

I'm not sure how to find the other one, but you can specify your own entry point explicitly and make the other one unused. You can use the GNU linker ld -e option to set your entry point.

-e entry

--entry=entry

Use entry as the explicit symbol for beginning execution of your program, rather than the default entry point. If there is no sym- bol named entry, the linker will try to parse entry as a number, and use that as the entry address (the number will be interpreted in base 10; you may use a leading 0x for base 16, or a leading 0 for base 8).

For future readers, if you have this problem in Windows. The equivalent linker option is /ENTRY.

Answer 4

Look through the header files that you include and see if there isn't a define that remaps main to something else. This is an old trick to ensure that a library's main function is called first to do some set up. Generally, it will eventually call your main function by referring to the redefined value.

Answer 5

A quick hack:

readelf -s -w my_bin_file > temp.txt

Open temp.txt, search for main (with FUNC in one column) Go up until you find the first FILE column - this is the file with the linked main.

edit: This only works on GNU Unix flavors and friends. OS X uses the Mach-O format, not ELF.

Answer 6

I know that in C, you can have a different entrypoint called before the main function, that could be an idea. The code usually looks like :

void __attribute__ ((constructor)) my_main(void);

Maybe you can search for something like that in your code.

In C, there is also different ways to catch the main function and call it after the "real" main. Some threads library have this kind of hacks in order to "prepare" the environnement, scheduler and stuff like that.

This is not really usefull but this may explain why your main isn't called at all.

Hope this helps!

Answer 7

Do you have several main in the binary? Try using nm on it. (it shouldn't be possible as ld won't link with duplicates, but go into the dynamical libs and look for _main there)

nm a.out | grep -5 _main

This should give 5 lines before and after any _main found in the binary a.out

If you have several, see the surrounding symbols for hints which parts they are in...

Next step can be to do the same on each dynamic lib that is used. To get a list of the used dynamic libraries use otool

otool -L a.out

Answer 8

Another note.

WxWidgets do also define their own main

From here

As in all programs there must be a "main" function. Under wxWidgets main is implemented using this macro, which creates an application instance and starts the program.

IMPLEMENT_APP(MyApp)

Answer 9

It looks like you can have a file called b44ExpLogTable.cpp compiled into your binary or some thirdpart library. It looks like that little program is to generate a exp() table but has somehow come to be imported into your project(s)

See this and this in FreeImage sources

Answer 10

Generate a map file. Most programs don't actually start at main. A mapfile from GCC should tell you the address of __start or __executable_start, which you should be able to break in and step through to see what's causing your program to exit.