Pumpkin, Inc.

Pumpkin User Forums

New BUG with OS_Yield

If you think you've found a bug or other mistake in your Salvo distribution, post it here.

New BUG with OS_Yield

Postby luben » Mon Jan 27, 2003 3:10 am

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

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: New BUG with OS_Yield

Postby aek » Mon Jan 27, 2003 8:19 am

Hi Luben.

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

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

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: New BUG with OS_Yield

Postby luben » Mon Jan 27, 2003 8:34 am

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

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: New BUG with OS_Yield

Postby jtemples » Tue Jan 28, 2003 8:44 am

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

jtemples
 
Posts: 45
Joined: Tue Jul 16, 2002 11:00 pm

Re: New BUG with OS_Yield

Postby aek » Tue Jan 28, 2003 9:58 am

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.

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

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: New BUG with OS_Yield

Postby luben » Wed Jan 29, 2003 6:49 am

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

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: New BUG with OS_Yield

Postby jtemples » Wed Jan 29, 2003 6:51 am

Right, your code is essentially "if (i & 0)" which can never be true.
jtemples
 
Posts: 45
Joined: Tue Jul 16, 2002 11:00 pm

Re: New BUG with OS_Yield

Postby aek » Wed Jan 29, 2003 9:32 am

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

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

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: New BUG with OS_Yield

Postby jtemples » Wed Jan 29, 2003 10:17 am

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.

jtemples
 
Posts: 45
Joined: Tue Jul 16, 2002 11:00 pm

Re: New BUG with OS_Yield

Postby aek » Wed Jan 29, 2003 10:43 am

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

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

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm


Return to Bug Reports

Who is online

Users browsing this forum: No registered users and 1 guest

cron