BX LR generation

I think this is a tool chain but - if I place the function that is called from startup code in a separate C module - a "BX LR" is generated!

"...the compiler does not generate a "BX LR" instruction at its end."

The only instance I know of where the compiler does not generate a return from a function is when it is an __asm function, so you add it to the function yourself.

If you look at the assembler produced for the C module, you surely see the returns in other functions?

Are you saying that your one C function just falls through to the next?

Are you saying that your one C function just falls through to the next?

YES!

I will try to send this program to Keil so they can see it. This cause me SO MUCH heard ache today (when combined with other changes...).

"YES!"

OMG. Sounds nasty!

I reported a problem with compiler produced code a few weeks ago (-O3 was creating faulty inline code) and was told that there should be a compiler update around mid-October.

Mid-October? First it was mid-September, then beginning October, and now this...

if I place the function that is called from startup code in a separate C module - a "BX LR" is generated!

And you're sure that's not just because the compiler inlined that function, and thus there was no need to return from it?

A little actual source and actual assembler output of both that function and its caller would go a long way towards clarifying this puzzle...

The only instance I know of where the compiler does not generate a return from a function is when it is an __asm function, so you add it to the function yourself.

Well, another good reason for a compiler to omit a return from a function is the case when the function doesn't ever return, like a typical main().
So yes, some actual source code would be in order.

Mike,

I have an enormous amount of work now. I will try to post a code snippet in the very near future.

"Well, another good reason for a compiler to omit a return from a function is the case when the function doesn't ever return, like a typical main()."

A valid point, I'd forgotten that one.

> Well, another good reason for a compiler to omit a return from a function is the case when
> the function doesn't ever return, like a typical main().

Or in case the compiler applied tail-call optimization.

int var;

int bar()
{
   return var;
}

int foo()
{
   return bar();
}

(assuming the compiler doesn't inline this silly example)

--
Marcus
http://www.doulos.com/arm/