Hi,

I am using KEIL compiler for my SAM7SE512. We have quite a bit of code
developed for this project & now all of sudden when I implemented some
more functions, one of them is not returning proper value.

For Example, I am returning float from a function, when i debug into
that function i see the return value fine, but in the calling function
it shows up as a huge negative number (-9.4...e+022). I checked stack
pointer, it seems reasonable(within the stack area).
Once this happens (big number return), everything goes out of order,
my pointers addresses go to 0x00000000 & their values also show up as
-9.4...e+022.

Thanks for your help,

Gujarati
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Hello,

1) Is your KEIL compiler version is code limited?
2) Temporarily remove some other functions / code to make more space
then run the offending function and see it still gives same error!

Then problem can be narrowed down

Regards
Vinay
--- In A...@yahoogroups.com, "gujarati2000"
wrote:
>
> Hi,
>
> I am using KEIL compiler for my SAM7SE512. We have quite a bit of
code
> developed for this project & now all of sudden when I implemented
some
> more functions, one of them is not returning proper value.
>
> For Example, I am returning float from a function, when i debug
into
> that function i see the return value fine, but in the calling
function
> it shows up as a huge negative number (-9.4...e+022). I checked
stack
> pointer, it seems reasonable(within the stack area).
> Once this happens (big number return), everything goes out of
order,
> my pointers addresses go to 0x00000000 & their values also show up
as
> -9.4...e+022.
>
> Thanks for your help,
>
> Gujarati
>

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Hi,

check your stack size.

Foltos

gujarati2000 wrote:
>
> Hi,
>
> I am using KEIL compiler for my SAM7SE512. We have quite a bit of code
> developed for this project & now all of sudden when I implemented some
> more functions, one of them is not returning proper value.
>
> For Example, I am returning float from a function, when i debug into
> that function i see the return value fine, but in the calling function
> it shows up as a huge negative number (-9.4...e+022). I checked stack
> pointer, it seems reasonable(within the stack area).
> Once this happens (big number return), everything goes out of order,
> my pointers addresses go to 0x00000000 & their values also show up as
> -9.4...e+022.
>
> Thanks for your help,
>
> Gujarati
>
>



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Make sure the function is declared identically for both the caller and
the callee. Is the function declared as a cdecl? Are both the
function and the caller compiled in the same mode (i.e. thumb vs arm)?

A confusion about _cdecl could be the cause, for example, if the
caller expects the function to do the stack cleanup, but the function
expects the caller to do it - this would, I believe, cause exactly the
symptoms you describe.

Even with the incorrect result, does the program execution continue
OK, or does it crash? (i.e. if you return right after this function
call, are you still within your code, or are you out in la-la land?)

--- In A...@yahoogroups.com, Foltos wrote:
>
> Hi,
>
> check your stack size.
>
> Foltos
>
> gujarati2000 wrote:
> >
> > Hi,
> >
> > I am using KEIL compiler for my SAM7SE512. We have quite a bit of code
> > developed for this project & now all of sudden when I implemented some
> > more functions, one of them is not returning proper value.
> >
> > For Example, I am returning float from a function, when i debug into
> > that function i see the return value fine, but in the calling function
> > it shows up as a huge negative number (-9.4...e+022). I checked stack
> > pointer, it seems reasonable(within the stack area).
> > Once this happens (big number return), everything goes out of order,
> > my pointers addresses go to 0x00000000 & their values also show up as
> > -9.4...e+022.
> >
> > Thanks for your help,
> >
> > Gujarati
> >
>
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Vinay,

Thanks for your reply. I have full KEIL compiler, so there is no
limit on code size. We did remove some of the functions & it's
still behaving the same.

Regards,

Gujarati
--- In A...@yahoogroups.com, "vinaydand"
wrote:
>
> Hello,
>
> 1) Is your KEIL compiler version is code limited?
> 2) Temporarily remove some other functions / code to make more
space
> then run the offending function and see it still gives same error!
>
> Then problem can be narrowed down
>
> Regards
> Vinay
> --- In A...@yahoogroups.com, "gujarati2000"
> wrote:
> >
> > Hi,
> >
> > I am using KEIL compiler for my SAM7SE512. We have quite a bit
of
> code
> > developed for this project & now all of sudden when I
implemented
> some
> > more functions, one of them is not returning proper value.
> >
> > For Example, I am returning float from a function, when i debug
> into
> > that function i see the return value fine, but in the calling
> function
> > it shows up as a huge negative number (-9.4...e+022). I checked
> stack
> > pointer, it seems reasonable(within the stack area).
> > Once this happens (big number return), everything goes out of
> order,
> > my pointers addresses go to 0x00000000 & their values also show
up
> as
> > -9.4...e+022.
> >
> > Thanks for your help,
> >
> > Gujarati
>
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Check to make sure that you're not overwriting the bounds of an array
somewhere. What you're seeing could be a secondary effect of an error
such as that, occurring elsewhere in your code. I always find that
the best way to track down a bug like this is to drop down into
assembly language and single step through the function. Monitor all
of your calculations one instruction at a time. Eventually, you
should see where a value or a pointer is getting corrupted. Then, you
can backtrack from there.

If a value is getting corrupted and you're certain that nothing should
be writing to it, set up a watchpoint to trigger on writes to that
address.

If the function works correctly when you single step through it, there
may be a real time interaction causing the problem. Check your
interrupt routines to be certain they're not causing you grief,
perhaps by not saving/restoring a register properly.

Good luck!
Mike

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Hello Gujarati,

Is it possible for you to post the code of errant function along
with some comments, so we can have a look at it. If possible please
give some sample values of inputs required by the function and
expected output.

Regards
Vinay

--- In A...@yahoogroups.com, "gujarati2000"
wrote:
>
> Vinay,
>
> Thanks for your reply. I have full KEIL compiler, so there is no
> limit on code size. We did remove some of the functions & it's
> still behaving the same.
>
> Regards,
>
> Gujarati
> --- In A...@yahoogroups.com, "vinaydand"
> wrote:
> >
> > Hello,
> >
> > 1) Is your KEIL compiler version is code limited?
> > 2) Temporarily remove some other functions / code to make more
> space
> > then run the offending function and see it still gives same
error!
> >
> > Then problem can be narrowed down
> >
> > Regards
> > Vinay
> >
> >
> > --- In A...@yahoogroups.com, "gujarati2000"
> > wrote:
> > >
> > > Hi,
> > >
> > > I am using KEIL compiler for my SAM7SE512. We have quite a bit
> of
> > code
> > > developed for this project & now all of sudden when I
> implemented
> > some
> > > more functions, one of them is not returning proper value.
> > >
> > > For Example, I am returning float from a function, when i
debug
> > into
> > > that function i see the return value fine, but in the calling
> > function
> > > it shows up as a huge negative number (-9.4...e+022). I
checked
> > stack
> > > pointer, it seems reasonable(within the stack area).
> > > Once this happens (big number return), everything goes out of
> > order,
> > > my pointers addresses go to 0x00000000 & their values also
show
> up
> > as
> > > -9.4...e+022.
> > >
> > > Thanks for your help,
> > >
> > > Gujarati
> > >
>
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Is your function, by any chance, ending with a big for(;;) loop ?
I recently had a similar problem (but I was returning a signed int).

I found that after iterating through the for() loop the function returns normally, but then the
stack got all screwed up. Once I added a single statement (return 0) after the for() loop, but
before exiting the function, all is OK. Keil also uses GCC so I'm wondering if you're observing
the same CG bug I came across.

Perhaps just try adding a return at end of function to make sure you're not seeing the same bug.
I don't recall another workaround, but if you have the same problem, perhaps an explicit return
might fix it ?

Example :

This was broken
===============
signed int foo (...)
{
some_code;
for(...;...;...)
{
// ..... bla bla
}
}

but this fixed it :
===================
signed int foo (...)
{
some_code;
for(...;...;...)
{
// ..... bla bla
}
return 0;
}
HTH
Kris

-----Original Message-----
From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of gujarati2000
Sent: Friday, 6 June 2008 6:49 AM
To: A...@yahoogroups.com
Subject: [AT91SAM] Re: function not returning number(instead returns -9.4...e+022)

Vinay,

Thanks for your reply. I have full KEIL compiler, so there is no
limit on code size. We did remove some of the functions & it's
still behaving the same.

Regards,

Gujarati

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

On Thu, Jun 12, 2008 at 09:43:42PM +1000, microbit wrote:
> Is your function, by any chance, ending with a big for(;;) loop ?
> I recently had a similar problem (but I was returning a signed int).
>
> I found that after iterating through the for() loop the function returns normally, but then the
> stack got all screwed up. Once I added a single statement (return 0) after the for() loop, but
> before exiting the function, all is OK. Keil also uses GCC so I'm wondering if you're observing
> the same CG bug I came across.
>
> Perhaps just try adding a return at end of function to make sure you're not seeing the same bug.
> I don't recall another workaround, but if you have the same problem, perhaps an explicit return
> might fix it ?
>
> Example :
>
> This was broken
> ===============
> signed int foo (...)
> {
> some_code;
> for(...;...;...)
> {
> // ..... bla bla
> }
> }
>
> but this fixed it :
> ===================
> signed int foo (...)
> {
> some_code;
> for(...;...;...)
> {
> // ..... bla bla
> }
> return 0;
> }

This has nothing to do with "for" at all.
You claimed to return an "signed int" but returned nothing.
If the value was to be returned on the stack then your stackpointer
can be wrong as well.
Compilers are intelligent enough to warn you about those things if
you enable those checkings.

If you don't want to return anything then you have to do:
void foo (...)
{
some_code;
for(...;...;...)
{
// ..... bla bla
}
}

--
B.Walter http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Hi,

Perhaps I should have gone into more detail.

> You claimed to return an "signed int" but returned nothing.

I did return a signed int in the for() loop (It was a formatting routine that breaks out early
depending on the number of partitions created, 0 or 1-4)
I can't exactly recall all the details of it, and while I'm by no means a seasoned pro on C, I'm
not particularly a 'newbie' either.
This is one of more bugs I've come across in the CG of GCC and I just wondered whether the OP was
seeing a similar problem.

Actually - furthermore, IMO even when I complete the iteration in for() but don't specify a return
value, worst case my return value should be trashed but the stack frame shouldn't such that the
wrong return addresses are used. After all, that return address was on the stack *before* the
function was called...

> If you don't want to return anything then you have to do:
> void foo (...)

Thanks, but I'm not that dumb :-)

Best regards,
Kris

-----Original Message-----
From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of Bernd Walter
Sent: Thursday, 12 June 2008 9:56 PM
To: A...@yahoogroups.com
Subject: Re: [AT91SAM] Re: function not returning number(instead returns -9.4...e+022)
This has nothing to do with "for" at all.
You claimed to return an "signed int" but returned nothing.
If the value was to be returned on the stack then your stackpointer
can be wrong as well.
Compilers are intelligent enough to warn you about those things if
you enable those checkings.

If you don't want to return anything then you have to do:
void foo (...)
{
some_code;
for(...;...;...)
{
// ..... bla bla
}
}

--
B.Walter http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

On Fri, Jun 13, 2008 at 01:02:08AM +1000, microbit wrote:
> Hi,
>
> Perhaps I should have gone into more detail.
>
> > You claimed to return an "signed int" but returned nothing.
>
> I did return a signed int in the for() loop (It was a formatting routine that breaks out early
> depending on the number of partitions created, 0 or 1-4)

The end of the function is the place where you have to return what
you've promissed.
Even if you don't reach that location ever.

> I can't exactly recall all the details of it, and while I'm by no means a seasoned pro on C, I'm
> not particularly a 'newbie' either.
> This is one of more bugs I've come across in the CG of GCC and I just wondered whether the OP was
> seeing a similar problem.

This is not a bug in the compiler - it is in your code.

> Actually - furthermore, IMO even when I complete the iteration in for() but don't specify a return
> value, worst case my return value should be trashed but the stack frame shouldn't such that the
> wrong return addresses are used. After all, that return address was on the stack *before* the
> function was called...

It is free to the compiler how too handle broken code.
Often those kind of source code bugs are without consequences, because
on many architectures the return argument is transfered using
registers, but that doesn't mean it is correct to do so.

> > If you don't want to return anything then you have to do:
> > void foo (...)
>
> Thanks, but I'm not that dumb :-)

Well - you did a coding mistake.
Slightly different than I thought, but your original code is still
wrong and you did fix it correctly.

--
B.Walter http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Hi,

> The end of the function is the place where you have to return what
> you've promissed.

Yes, and that's what I did - return a signed int when I return from *within* the for() loop.

> This is not a bug in the compiler - it is in your code.

Don't presume to know what code I wrote. The bug was NOT in my code.
Furthermore, there was another CG bug in GCC. When you have a fair bit of local variables
and they're longs combined with floats, GCC starts buggering up, some floats start to have long
operations (integer) and longs start to have float operations on 'em.

Again, I don't recall the specifics, I would have to dig it out and try to reconstruct the CG bug
I found. But again, I assure you it was NOT in my code.

-- Kris

-----Original Message-----
From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of Bernd Walter
Sent: Friday, 13 June 2008 2:35 AM
To: A...@yahoogroups.com
Subject: Re: [AT91SAM] Re: function not returning number(instead returns -9.4...e+022)

On Fri, Jun 13, 2008 at 01:02:08AM +1000, microbit wrote:
> Hi,
>
> Perhaps I should have gone into more detail.
>
> > You claimed to return an "signed int" but returned nothing.
>
> I did return a signed int in the for() loop (It was a formatting routine that breaks out early
> depending on the number of partitions created, 0 or 1-4)

The end of the function is the place where you have to return what
you've promissed.
Even if you don't reach that location ever.

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

There may very well be bugs in Kris' code, but in this specific case
as described, it certainly sounds like a compiler bug. Kris could
have omitted all return statement, but unless his code somehow trash
the stack or stack pointer (e.g. a random memory write), a "return
0;" is not necessary. The function may be returning garbage, but the
stack balancing is the job of the compiler (barring random memory
write, blah blah blah).

At 10:24 AM 6/12/2008, microbit wrote:
>Hi,
>
> > The end of the function is the place where you have to return what
> > you've promissed.
>
>Yes, and that's what I did - return a signed int when I return from
>*within* the for() loop.
>
> > This is not a bug in the compiler - it is in your code.
>
>Don't presume to know what code I wrote. The bug was NOT in my code.
>Furthermore, there was another CG bug in GCC. When you have a fair
>bit of local variables
>and they're longs combined with floats, GCC starts buggering up,
>some floats start to have long
>operations (integer) and longs start to have float operations on 'em.
>
>Again, I don't recall the specifics, I would have to dig it out and
>try to reconstruct the CG bug
>I found. But again, I assure you it was NOT in my code.

// richard (This email is for mailing lists. To reach me directly,
please use richard at imagecraft.com)
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Bernd,

I am astonished at what you've written. Do you mean that the
following code is illegal?

float fabs(float val)
{
for(;;)
{
if(val >= 0) return(val);
else return(-val);
}
}

AFAIK, this is perfectly legal 'C' syntax, even though there isn't a
return at the end of the function. I know the for(;;) part doesn't
really make sense, but it's just an example to show the principle of
the thing. In fact, with many compilers, adding a return at the end
of the function would produce an "unreachable code" warning.

A perhaps more typical example would be a switch statement that
returns a value for each case (including the default case).

But your claim says that this isn't the case, and I sincerely hope
you're wrong ;-)

By the way, I did try to answer the original question earlier, and
didn't really get any feedback. It seems that a) the variables all
look correct while in the called function, b) the function returns to
the proper place in the code, and c) after the return, the variables
(and other local variables) are all garbage. This REALLY smells like
a declaration mismatch (like cdecl attributes) or possibly an
ARM/THUMB declaration mismatch? (not sure about the latter, not so
familiar with the raw guts of the ARM cross-mode handling). It
screams out "Stack cleanup problem!" which is usually due to
declaration mis-matches of some sort!

In any case, at the very least the original poster should try moving
the function into the same file as the function that calls it, and see
if the error goes away (or if the compiler complains about
"declaration mismatch").
--- In A...@yahoogroups.com, Bernd Walter wrote:
snip
>
> The end of the function is the place where you have to return what
> you've promissed.
> Even if you don't reach that location ever.
>
snip...
> --
> B.Walter http://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
>

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

My stack size is about 1K & at the time of this issue, stack pointer
is no where close the end of stack.

Function protoype is matching the function implementation.

Both calling and called functions are in the same file.

For now i have set up a work around, by using global variables
to store these values instead of returns! This is working out
fine for now.

Thank you all for your inputs. At some point i will take out the
work around solution & dig in little more to fix this issue.

Regards,

Gujarati

Thank you all for

--- In A...@yahoogroups.com, "twgbonehead"
wrote:
>
> Bernd,
>
> I am astonished at what you've written. Do you mean that the
> following code is illegal?
>
> float fabs(float val)
> {
> for(;;)
> {
> if(val >= 0) return(val);
> else return(-val);
> }
> }
>
> AFAIK, this is perfectly legal 'C' syntax, even though there isn't
a
> return at the end of the function. I know the for(;;) part doesn't
> really make sense, but it's just an example to show the principle
of
> the thing. In fact, with many compilers, adding a return at the
end
> of the function would produce an "unreachable code" warning.
>
> A perhaps more typical example would be a switch statement that
> returns a value for each case (including the default case).
>
> But your claim says that this isn't the case, and I sincerely hope
> you're wrong ;-)
>
> By the way, I did try to answer the original question earlier, and
> didn't really get any feedback. It seems that a) the variables all
> look correct while in the called function, b) the function returns
to
> the proper place in the code, and c) after the return, the
variables
> (and other local variables) are all garbage. This REALLY smells
like
> a declaration mismatch (like cdecl attributes) or possibly an
> ARM/THUMB declaration mismatch? (not sure about the latter, not so
> familiar with the raw guts of the ARM cross-mode handling). It
> screams out "Stack cleanup problem!" which is usually due to
> declaration mis-matches of some sort!
>
> In any case, at the very least the original poster should try
moving
> the function into the same file as the function that calls it, and
see
> if the error goes away (or if the compiler complains about
> "declaration mismatch").
> --- In A...@yahoogroups.com, Bernd Walter wrote:
> snip
> >
> > The end of the function is the place where you have to return
what
> > you've promissed.
> > Even if you don't reach that location ever.
> >
> snip...
> > --
> > B.Walter http://www.bwct.de
> > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner
uvm.
>
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

My stack size is about 1K & at the time of this issue, stack pointer
is no where close the end of stack.

Function protoype is matching the function implementation.

Both calling and called functions are in the same file.

For now i have set up a work around, by using global variables
to store these values instead of returns! This is working out
fine for now.

Thank you all for your inputs. At some point i will take out the
work around solution & dig in little more to fix this issue.

Regards,

Gujarati

Thank you all for

--- In A...@yahoogroups.com, "twgbonehead"
wrote:
>
> Bernd,
>
> I am astonished at what you've written. Do you mean that the
> following code is illegal?
>
> float fabs(float val)
> {
> for(;;)
> {
> if(val >= 0) return(val);
> else return(-val);
> }
> }
>
> AFAIK, this is perfectly legal 'C' syntax, even though there isn't
a
> return at the end of the function. I know the for(;;) part doesn't
> really make sense, but it's just an example to show the principle
of
> the thing. In fact, with many compilers, adding a return at the
end
> of the function would produce an "unreachable code" warning.
>
> A perhaps more typical example would be a switch statement that
> returns a value for each case (including the default case).
>
> But your claim says that this isn't the case, and I sincerely hope
> you're wrong ;-)
>
> By the way, I did try to answer the original question earlier, and
> didn't really get any feedback. It seems that a) the variables all
> look correct while in the called function, b) the function returns
to
> the proper place in the code, and c) after the return, the
variables
> (and other local variables) are all garbage. This REALLY smells
like
> a declaration mismatch (like cdecl attributes) or possibly an
> ARM/THUMB declaration mismatch? (not sure about the latter, not so
> familiar with the raw guts of the ARM cross-mode handling). It
> screams out "Stack cleanup problem!" which is usually due to
> declaration mis-matches of some sort!
>
> In any case, at the very least the original poster should try
moving
> the function into the same file as the function that calls it, and
see
> if the error goes away (or if the compiler complains about
> "declaration mismatch").
> --- In A...@yahoogroups.com, Bernd Walter wrote:
> snip
> >
> > The end of the function is the place where you have to return
what
> > you've promissed.
> > Even if you don't reach that location ever.
> >
> snip...
> > --
> > B.Walter http://www.bwct.de
> > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner
uvm.
>
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

The last time I had problems with local variables it was very similar in nature to your problem,
but the CG was mixing up float and long operations, it wasn't corrupting the stack frame.
Again, check if you might have a big for(;;) loop in the end part of the function.
If not that, my other workaround was also to use globals for some of the vars. GCC needs fixing...

B rgds
Kris

-----Original Message-----
From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of gujarati2000
Sent: Tuesday, 1 July 2008 6:56 AM
To: A...@yahoogroups.com
Subject: [AT91SAM] Re: function not returning number(instead returns -9.4...e+022)

My stack size is about 1K & at the time of this issue, stack pointer
is no where close the end of stack.

Function protoype is matching the function implementation.

Both calling and called functions are in the same file.

For now i have set up a work around, by using global variables
to store these values instead of returns! This is working out
fine for now.

Thank you all for your inputs. At some point i will take out the
work around solution & dig in little more to fix this issue.

Regards,

Gujarati

Thank you all for

--- In A...@yahoogroups.com, "twgbonehead"
wrote:
>
> Bernd,
>
> I am astonished at what you've written. Do you mean that the
> following code is illegal?
>
> float fabs(float val)
> {
> for(;;)
> {
> if(val >= 0) return(val);
> else return(-val);
> }
> }
>
> AFAIK, this is perfectly legal 'C' syntax, even though there isn't
a
> return at the end of the function. I know the for(;;) part doesn't
> really make sense, but it's just an example to show the principle
of
> the thing. In fact, with many compilers, adding a return at the
end
> of the function would produce an "unreachable code" warning.
>
> A perhaps more typical example would be a switch statement that
> returns a value for each case (including the default case).
>
> But your claim says that this isn't the case, and I sincerely hope
> you're wrong ;-)
>
> By the way, I did try to answer the original question earlier, and
> didn't really get any feedback. It seems that a) the variables all
> look correct while in the called function, b) the function returns
to
> the proper place in the code, and c) after the return, the
variables
> (and other local variables) are all garbage. This REALLY smells
like
> a declaration mismatch (like cdecl attributes) or possibly an
> ARM/THUMB declaration mismatch? (not sure about the latter, not so
> familiar with the raw guts of the ARM cross-mode handling). It
> screams out "Stack cleanup problem!" which is usually due to
> declaration mis-matches of some sort!
>
> In any case, at the very least the original poster should try
moving
> the function into the same file as the function that calls it, and
see
> if the error goes away (or if the compiler complains about
> "declaration mismatch").
> --- In A...@yahoogroups.com, Bernd Walter wrote:
> snip
> >
> > The end of the function is the place where you have to return
what
> > you've promissed.
> > Even if you don't reach that location ever.
> >
> snip...
> > --
> > B.Walter http://www.bwct.de
> > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner
uvm.
>
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )