View previous topic :: View next topic |
Author |
Message |
loupan
Joined: 22 Oct 2007 Posts: 21
|
4.107 - compiler generating wrong addresses? |
Posted: Fri May 21, 2010 7:06 am |
|
|
In a previous post, I discussed a case where it appeared to me that the compiler was generating incorrect addresses for some of the function calls:
http://www.ccsinfo.com/forum/viewtopic.php?t=41396&highlight=
CCS tells me I am the only one reporting this problem, but another user appears to have a similar problem:
http://www.ccsinfo.com/forum/viewtopic.php?t=41702&highlight=
The processor is a PIC18F8722, 128K, about 95% ROM usage.
I am using 4.017 and still see the same problem. Below is my analysis.
If someone sees something wrong with the below analysis, please let me know.
Compiler Version 4.107 – Summary of 4 calls to function get_hi_vis_options()
Function Definition for get_hi_vis_options. Function is located at address 04722
Quote: |
int get_hi_vis_options() { // This is the fncn that gets called with wrong adrs
return read_ext_eeprom(EEPROM_HI_VIS_OPT);
04722: MOVLW 2A // 4722 is the correct adrs of function
04724: MOVLB B
04726: MOVWF xC4
04728: MOVLW F8
0472A: MOVWF xC3
0472C: MOVLB 0
0472E: RCALL 46D8
04730: MOVF 01,W
.................... }
04732: RETLW 00
....................
First call – uses correct adrs
if (get_hi_vis_options() == HI_VIS_2_7_SEG) // then both ext devices are 7 seg
04B3A: RCALL 4722 // correct
04B3C: MOVF 01,W
04B3E: SUBLW 02
04B40: BNZ 4B5A
Second call – uses correct adrs
vis_options = get_hi_vis_options();
08F26: CALL 4722 // correct
08F2A: MOVFF 01,7E9
Third call – uses correct adrs
if (get_hi_vis_options() == HI_VIS_1_7_SEG) // then ext BG is configured on
052A2: MOVLB 0
052A4: CALL 4722 // correct
052A8: DECFSZ 01,W
052AA: BRA 52B4
Fourth call – USES WRONG ADRS
if (get_hi_vis_options() == HI_VIS_1_7_SEG)
1CDBE: MOVLB 0
1CDC0: CALL 1BD48 // Wrong Address
1CDC4: DECFSZ 01,W
1CDC6: GOTO 1CDD0
The wrong adrs correspond to the MIDDLE of another function, the relevant part shown below (from LST file):
display_runtime_band_corr_fact();
1BD30: MOVLB 0
1BD32: CALL 136C0
1BD36: MOVLB 8
1BD38: MOVLB 6
1BD3A: MOVLB 5
....................
.................... }
....................
....................
....................
....................
.................... if (disp_bars && (G_BAR_GRAPH_DEVICES == BAR_GRAPH_DEV_EXTERN || BAR_GRAPH_DEV_BOTH ||
.................... (G_CONSOLE_ON && G_BAR_GRAPH_DEVICES != BAR_GRAPH_DEV_OFF))) {
1BD3C: MOVLB 8
1BD3E: BTFSC x22.2
1BD40: GOTO 1BD4E
1BD44: GOTO 1BF3E
1BD48: BTFSS x22.2 // This is the adrs 1BD48, which is the adrs generated for the last call of get_hi_vis_options()
1BD4A: GOTO 1BF3E
....................
....................
The following are excerpts from the Symbol table file:
The symbol table thinks the rogue adrs belongs to READ_PROGRAM_MEMORY
ROM Allocation:
01BD48 @READ_PROGRAM_MEMORY
003D36 @delay_ms1
01E848 @delay_us1
01DC82 @PUTCHARI_BIU_1
0071B6 @FLT
00791A @SFTOI
The symbol table also shows the correct adrs for the function in question: get_hi_vis_options()
015A4C service_user_push_but
00D504 calc_band_corr
004722 get_hi_vis_options
003DB6 init_critical_static
004866 init_static |
|
|
|
sjb
Joined: 13 Apr 2010 Posts: 34 Location: UK
|
|
Posted: Fri May 21, 2010 8:22 am |
|
|
I assume this is a large program. Have you tried cutting it down to a simple example?
If you can post a small, but complete example I'd be happy to see if it does the same for me , which I assume it will, but at least it will confirm there's nothing 'funny' about you setup.
I've just started to use CCS for a new project and have been finding a few bugs myself.
Steven |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Fri May 21, 2010 10:10 am |
|
|
It's obviously a compiler bug, assumíng the generated binary code is corresponding to the listing text. You may
want to find out, what are the exact conditions for generating (totally wrong) calls, just a distance above a certain
value, or arbitrarily, so the code may be correct if you move it by a small amount? In any case, it has to be fixed by CCS. |
|
|
loupan
Joined: 22 Oct 2007 Posts: 21
|
|
Posted: Fri May 21, 2010 2:40 pm |
|
|
Thanks for your responses. If I move the code around, or even change the order of the declartions, the problem will move to another function (or in a few cases, not occur).
CCS is not interested in pusuing this unless I send them the source code, which I am prohibited from doing. That's unfortunate.
Thanks again. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri May 21, 2010 2:53 pm |
|
|
Right, but you could fake up a program that uses generic names for
the functions, and maybe changes the internals of the functions to
be more generic code. You could probably duplicate the problem
and satisfy your non-disclosure agreement, and get CCS to work on
the problem, by doing it this way. |
|
|
Douglas Kennedy
Joined: 07 Sep 2003 Posts: 755 Location: Florida
|
|
Posted: Fri May 21, 2010 7:00 pm |
|
|
If you can't trust CCS with your code then you can't trust them for the compiler either. The best security is to write your own code and your own compiler and maybe even your own PC operating system. The point is you have to trust someone. If the source is the major concern then disguise it in someway as suggested. If 4.107 is the issue does an earlier version say 4.106 work? |
|
|
loupan
Joined: 22 Oct 2007 Posts: 21
|
|
Posted: Sun May 23, 2010 10:41 am |
|
|
Mr. Kennedy,
I don't know how you determine who you trust, but based on my life experience, trust has to be earned.
For those of you that offerered non-sarcastic responses, thanks again for your suggestions. |
|
|
|