hi,everyone. can anybody tell me where the C++ program start?

It starts in main, just like C programs.

no. Before main, some constructors need to be run.

no. befor main, some constructors need to be run.

Any reason you are posting in the EMBEDDED newsgroup ? Or just because you don't care/are dumb ?

Any reason you've never written embedded software in C++ ?

That's up to the startup code for your system. In ELF, for example, crt0.s or the equivalent is responsible for running all the .init/.fini code, which then calls the constructors and destructors. Where that code is, and how it gets called, depends on your tools, it's not a generic question we can answer here. The GNU tools, for example, typically look for a symbol called "_start" or "start".

my question is I have a piece of asm code, and I want to start the C++ main(), which function shall I call?

I am using gnu tool. I compile the C++ code into .o files and use ld to link them together. if i want to write a ld script to tell the ld to output a.out file or elf file, how to do that? i checked the asm code output by the gcc -S, and I cannot find the start or _start symbol.

my question is I have a piece of asm code, and I want to start the C++ main(), which function shall I call?

I am using gnu tool. I compile the C++ code into .o files and use ld to link them together. if i want to write a ld script to tell the ld to output a.out file or elf file, how to do that? i checked the asm code output by the gcc -S, and I cannot find the start or _start symbol.

Usually when you mix a high level language and some assembly code, the simplest way is to have a trivial high level main program and then call the assembly function (which again can call some high level language routines).

Something like:

extern void AsmRoutine(void) ;

int main (void) { AsmRoutine() ; }

From AsmRoutine() you can call C-functions as well as run time routines.

Calling ordinary C++ functions are problematic due to the name mangling.

Any reason for asking language-related questions in a firmware-related newgroup ?

There *is* a C related newsgroup available you know.

This is very specific to the library you are using. If you are using GNU tools, chances are there is library source code you can look at.

Execution starts at whatever symbol you tell the linker to use as entry point ("-e start"). At that symbol, you'll usually find code to set up stack, initialize malloc, clear bss, initialize stdio, and call constructors. In an embedded context, it might also set up hardware, interrupts, etc. You'll have to figure out yourself (with your library's source code and documentation) for your specific environment what you have to do to fulfill the requirements for calling 'main', there is no general answer.

If you know what your compiler does, you could even get away with start: ldr sp, =initial_stack bx main I've been doing that in several low-level projects like boot loaders, that do not need constructors, malloc, stdio, bss, etc.

Stefan

That is ultimately a deal between the C++ runtime functions and the linker. "_start" is a popular choice.

Mel.

And if you mention Embedded over there, they'll send you over here. And asking a C++ question there would get you sent away too.

And the specific question, how to start a program, would be off-topic over there. Their only concern with what happens before or after main() is that it complies with the standards. How it's accomplished, when I've seen it asked, is considered machine or OS dependent and thus off-topic.

The only time I've encountered this issue has been when working with embedded systems.

To address the question, before a C (and probably a C++) program executes the program is somehow moved into memory (might be in ROM on an embedded machine) a routine often, but not always, called CRT (C Run Time) gets control from the OS, does some initialization (perhaps obtaining and clearing global memory, making the connections for stdin, stdout, stderr) and, finally, passing control to main(). This is all machine and (if you used it) C library dependent.

I've written or modified a number of these for embedded systems. I did some bug fixing on an MS-DOS crt0.s once. I've never messed with a C++ one, but I wonder if there would be global constructor and destructor issues to be addressed as well?

- Bill

You need to decide what question you're asking, first.

To call main, branch to main. To run the constructors, then you need to either call the gnu library code that does that, or you need to go delving into the World of Gnu to find out how the initialization segment is organized, and run the constructors by hand -- and hope that it doesn't change with the next iteration of the tool set. Then when you're done, branch to main.

Perhaps because it's a perfectly reasonable question for someone trying to use the Gnu tool set for an embedded target?

There are indeed. The way I've seen this done (in both Borland and Gnu) is that each global constructor is compiled into a little function that gets called. Then each of these function start addresses, along with some Mystery Variables (obviously I haven't delved deep, here) get put into at least one specially-named segment.

At startup, there's code that goes through that segment, calling each function in turn. Those functions invoke the appropriate constructors, as well as any functions you've defined in #pragma startup statements.

Ditto for destructors, but for all the embedded systems that I've done, object destruction is accomplished by removing power from the system, or at least resetting the processor.

Thank you for the insight. I thought it might be something like that.

Right. One system I worked on I found that I could simplify alloc() eliminate free(). All the memory was allocated at the start and none of it was ever given back. With no free(), alloc() didn't have to do any book keeping.

- Bill

Yup. Most of the C++ systems that I've worked with wouldn't let me remove free; if I can't remove it, I just slap an assert(0) into the middle of it as a subtle hint to future generations that I didn't mean for it to be used.

Although I do bend my own rules a bit in the case of code that'll only be used by manufacturing personnel or engineering -- in that case, I'll use dynamic allocation, but I make sure that there's someone in the code reviews who makes sure that it's only getting used for the afore- mentioned debug code.