Page 1 of 1

New BUG with OS_Yield

PostPosted: Mon Jan 27, 2003 3:10 am
by luben
Hello,

I think that I got some new bug with OS_Yield()... oh, my!

This code works fine:

code:

if ((i & 0x07) == 0)
{
OS_Yield(_TASK_search3);
}

this code yields error message somehow:

code:

if (i & 0x07 == 0) //!!!!!!!!!! NOTE THAT THERE IS NO BRACES around i & 0x07
{
OS_Yield(_TASK_search3);
}


The error code pops up in the linker.....
Linking:
Command line: "C:HT-PICBINPICC.EXE -FAKELOCAL -G -MPLAB -ICD -16F876 -oGRAFA.HEX -L-Pgendi=E00h GRAFA.OBJ "
Error[000] : undefined symbol:
Error[000] : __TASK_search3 (GRAFA.OBJ)

I use aspic.exe with modified behaviour (to fix the BANK BUG) and salvo.h with do{ ..... } while(0) loops.

I have no explanation for this ..... looking from ANSI C spelling both records are correct, but in one of them somehow the LABEL disappeares or it's not accepted.

Regards
Luben

[This message has been edited by luben (edited January 27, 2003).]

[This message has been edited by luben (edited January 27, 2003).]

[This message has been edited by luben (edited January 27, 2003).]


Re: New BUG with OS_Yield

PostPosted: Mon Jan 27, 2003 8:19 am
by aek
Hi Luben.

The code segments appear to be identical ... perhaps your editor has injected some bad characters?

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


Re: New BUG with OS_Yield

PostPosted: Mon Jan 27, 2003 8:34 am
by luben
I'm sorry.... I just copied the same example twice
Now I edited the message!

The bug is really strange - the compiler interprets the braces in some strange manner - without braces the OS_Yield stops working! I lost almost 2 hours to get what's up and to highlight the bug.

Inserting bad characters is really dangerous when doing macros - one symbol after "" sign .. and you get strange errors.

regards
Luben

[This message has been edited by luben (edited January 27, 2003).]


Re: New BUG with OS_Yield

PostPosted: Tue Jan 28, 2003 8:44 am
by jtemples
quote:

if (i & 0x07 == 0)

That "if" statement is always false for any value of "i," so the optimizer is correctly not generating code for it and the OS_Yield. Thus the label TASK_search3 doesn't actually exist, just like the linker says.

The compiler does generate a warning about the above code, but unfortunately, it's only visible at level -3, which is pretty much unusable because it results in so many spurious warnings when used with a Salvo program.

The only thing that's strange is that the linker wants that label to exist, even though there are no references to it in the code. I've noticed that the linker "sees" labels even for code it doesn't generate, and puts them in the call tree. If it's a bug, it's a linker bug, not a Salvo bug.

[This message has been edited by jtemples (edited January 28, 2003).]


Re: New BUG with OS_Yield

PostPosted: Tue Jan 28, 2003 9:58 am
by aek
You may want to pass that one on to HI-TECH ... since the body inside the { ... } didn't change, that's odd that it affected the macro OS_Yield().

May have something to do with C precedence, etc.

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


Re: New BUG with OS_Yield

PostPosted: Wed Jan 29, 2003 6:49 am
by luben
Hello,

If I understood correct:

code:

if (i & 0x07 == 0)
{operator}

the == is applied to 0x07.... I mean it's executed like:

code:

if (i & (0x07 == 0))
{operator}


That explains many things.....

Regards
Luben


Re: New BUG with OS_Yield

PostPosted: Wed Jan 29, 2003 6:51 am
by jtemples
Right, your code is essentially "if (i & 0)" which can never be true.

Re: New BUG with OS_Yield

PostPosted: Wed Jan 29, 2003 9:32 am
by aek
quote:
The only thing that's strange is that the linker wants that label to exist, even though there are no references to it in the code.
Well, in PICC and PICC-18 ports, there is _OSLabel(labelname), which declares the label as a void fn (void). That may be why the linker is looking for it ...

Anyway, thanks for the heads-up. Maybe someday I should burn C's operator precedence rules into my head ... until then, I'll keep using ()'s ...

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


Re: New BUG with OS_Yield

PostPosted: Wed Jan 29, 2003 10:17 am
by jtemples
quote:

Well, in PICC and PICC-18 ports, there is _OSLabel(labelname), which declares the label as a void fn (void). That may be why the linker is looking for it ...

The linker doesn't seem to care about declarations of functions that don't exist; at worst, these only generate warnings from the compiler. But if you try something like this:

code:

if (0) {
void not_a_function(void);
not_a_function();
}

Then look at your .lst file, you will see that the compiler has generated no code for the expression, and does not call not_a_function(). However, you'll get a linker error about the function being missing.

I'm not going to complain about it being a bug, though, because I have code just like the above in my Salvo programs. It's useful to trick the linker into not generating an error when you have OSCALL_OSSIGNALEVENT = OSFROM_ANYWHERE, yet you don't need to call all of the enabled event signaling services from your ISR.


Re: New BUG with OS_Yield

PostPosted: Wed Jan 29, 2003 10:43 am
by aek
quote:
I'm not going to complain about it being a bug, though, because I have code just like the above in my Salvo programs. It's useful to trick the linker into not generating an error when you have OSCALL_OSSIGNALEVENT = OSFROM_ANYWHERE, yet you don't need to call all of the enabled event signaling services from your ISR.
Good point -- Without this little PICC/PICC-18 "trick", this workaround would cost ROM (and maybe even a little RAM, if one had to come up with a test that would never be true at runtime) in order to satisfy the multiple callgraph requirements ...

Thanks for laying it all out so clearly -- I had seen this behavior before, but forgot about it ...

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