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

[伏虎]

hi,everyone. can anybody tell me where the C++ program start? I am
writing a loader, I want know the entry point of C++ program.

thank you.

[DJ Delorie]

It starts in main, just like C programs.

[伏虎]

On Apr 20, 6:52 pm, DJ Delorie <d...@delorie.com> wrote:
> It starts in main, just like C programs.

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

[伏虎]

On Apr 20, 6:52 pm, DJ Delorie <d...@delorie.com> wrote:

> It starts in main, just like C programs.

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

[R.Wieser]

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

[DJ Delorie]

"R.Wieser" <add...@not.available> writes:
> 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++ ?

[DJ Delorie]

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".

[伏虎]

On Apr 20, 9:51 pm, DJ Delorie <d...@delorie.com> wrote:

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.

[伏虎]

On Apr 20, 9:51 pm, DJ Delorie <d...@delorie.com> wrote:

[upsid...@downunder.com]

On Fri, 20 Apr 2012 23:28:49 -0700 (PDT), ?? <fuh...@hotmail.com>
wrote:

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

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.

[R.Wieser]

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

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

[Stefan Reuther]

伏虎 wrote:
> On Apr 20, 9:51 pm, DJ Delorie <d...@delorie.com> wrote:
>>伏虎 <fuhu...@hotmail.com> writes:
>>>On Apr 20, 6:52 pm, DJ Delorie <d...@delorie.com> wrote:
>>>>It starts in main, just like C programs.
>>
>>>no. befor main, some constructors need to be run.
>>
>>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.

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

[mwi...@the-wire.com]

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

Mel.

[Bill Leary]

"R.Wieser" wrote in message
news:4f9291ba$0$6967$e4fe...@news2.news.xs4all.nl...

>
> Any reason for asking language-related questions in a firmware-related
> newgroup ?
>
> There *is* a C related newsgroup available you know.

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

[Tim Wescott]

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.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

[Tim Wescott]

On Sat, 21 Apr 2012 05:28:48 +0200, R.Wieser wrote:

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

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

[Tim Wescott]

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.

[Bill Leary]

"Tim Wescott" wrote in message
news:9didnYjvUf58_A7S...@web-ster.com...

On Sat, 21 Apr 2012 11:23:03 -0400, Bill Leary wrote:

>> ((..omitted..))

>> 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?
>
> 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.

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

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

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

[Tim Wescott]

On Sun, 22 Apr 2012 08:29:29 -0400, Bill Leary wrote:

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

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.