[sdcc-devel] [ sdcc-Bugs-3539804 ] #pragma config and certain string constants

[SourceForge.net <no...@so...>]

Bugs item #3539804, was opened at 2012-07-03 10:03
Message generated for change (Comment added) made by diegoherranz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3539804&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pic16 target
Group: fixed
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Herbert Pötzl (hpoetzl)
Assigned to: Borut Ražem (borutr)
Summary: #pragma config and certain string constants

Initial Comment:
when combining (implicit?) string constants and #pragma config, the strings end up right after the CONFIG directives which leads to the following error and warning:

$ sdcc --use-non-free -mpic16 -p18f26j50 config_bug.c
config_bug.asm:485:Error[152]   Executable code and data must be defined in an appropriate section.
config_bug.asm:485:Warning[220] Address exceeds maximum range for this processor.
...

$ sdcc -v
SDCC : mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08 3.2.0 #7999 (Jul  3 2012) (Linux)

$ gpasm -v
gpasm-0.14.2 #711 (Jul  3 2012)


from config_bug.asm:
; ; Starting pCode block
        CONFIG  WDTEN=OFF
; ; Starting pCode block
__str_0:
        DB      0x73, 0x74, 0x72, 0x69, 0x6e, 0x67, 0x00


note: it might as well be a gputils issue but I presume that 'CONFIG' simply advances to the defined addresses and thus the following string ends up _after_ the config space which of course is bogus.


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

Comment By: Diego Herranz (diegoherranz)
Date: 2012-07-14 02:42

Message:
I've tested it and it seems to work like a charm.

Thanks again!

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

Comment By: Borut Ražem (borutr)
Date: 2012-07-12 08:33

Message:
> it supposed to work also with multi-line pragma CONFIG?

Yes.

Borut

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

Comment By: Diego Herranz (diegoherranz)
Date: 2012-07-12 07:51

Message:
Great!

I'll test it tomorrow when snapshot is built. Is it supposed to work also
with multi-line pragma CONFIG? 

Thank you very much

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

Comment By: Borut Ražem (borutr)
Date: 2012-07-12 06:05

Message:
Properly fixed (hopefully) in svn revision #8038.

Any report from users is welcome.

Borut

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

Comment By: Borut Ražem (borutr)
Date: 2012-07-11 23:36

Message:
Diego,

the source code snippet compiles OK wth revision #7999 since the code for
array fooarray[] is generated before the constant string "hello" and the
array genertes "code" directive by itself.

Unfortunately this example doesn't work with sdcc revision #8008 (SDCC
3.2.0), even if "all in one" #pragna directive is used, since there are two
"code" directives generated: one from #pragnma config and the second from
fooarray[]. Gpasm complains with: "main.asm:78:Error[154]   Each object
file section must be contiguous." :-(

Borut

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

Comment By: Diego Herranz (diegoherranz)
Date: 2012-07-11 13:30

Message:
Forgot to say,

Thanks a lot!

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

Comment By: Diego Herranz (diegoherranz)
Date: 2012-07-11 13:29

Message:
This is a small example where using #7999, code is generated correctly.
However, if fooarray line is commented, errors like these are found:

main.asm:348:Warning[220] Address exceeds maximum range for this processor.
main.asm:348:Error[152]   Executable code and data must be defined in an
appropr

main.c file (can't attach a file):

#include <pic18fregs.h>

const int fooarray[5] ={0x00, 0x00, 0x00, 0x00, 0x00};

#pragma config CP0 = ON
#pragma config CP1 = ON
#pragma config CP2 = ON
#pragma config CP3 = ON

//Foo function
void foo(const char *str){
}

void main (void){

	foo("hello");

}

sdcc command:
$ sdcc --use-non-free -mpic16 -p18f4550 main.c

$ sdcc -v
SDCC :
mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08
3.2.0 #7999 (Jun 29 2012) (Linux)


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

Comment By: Borut Ražem (borutr)
Date: 2012-07-10 08:34

Message:
> I'll use the one line pragma as a temporary workaround. Thanks.

I'm glat that it works for you.

> Anyway, I still don't know why I had no errors with 3.2 RC3 (#7999).
Maybe
> it depends on the place where the pragmas are located or... don't know.

Build #7999 has a problem when a constant string is defined in a function.
See the config_bug.c attachment. That's why the patch was applied in build
#8008, which fixed the "constant string defined in a function" problem by
switching to "code" section after emitting the CONFIG directive. But
unfortunately it introduced the "multiple #pragma configs" one, since the
"code" directive is emitted after each CONFIG directive.

> In fact, using 3.2 RC3 (#7999) with 18f4550 and multiline pragmas I get
the
> following asm file which seems to be correct (doesn't it?):

Yes, it seems correct. Can you please attach the c source, so that I can
analyze it?

Borut




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

Comment By: Diego Herranz (diegoherranz)
Date: 2012-07-10 03:34

Message:
I'll use the one line pragma as a temporary workaround. Thanks.

Anyway, I still don't know why I had no errors with 3.2 RC3 (#7999). Maybe
it depends on the place where the pragmas are located or... don't know.

In fact, using 3.2 RC3 (#7999) with 18f4550 and multiline pragmas I get the
following asm file which seems to be correct (doesn't it?):

[...]
    CONFIG  PWRT=ON
; ; Starting pCode block
    CONFIG  IESO=OFF
; ; Starting pCode block
    CONFIG  FCMEN=OFF
; ; Starting pCode block
    CONFIG  FOSC=HSPLL_HS
; ; Starting pCode block
    CONFIG  USBDIV=2
; ; Starting pCode block
    CONFIG  CPUDIV=OSC1_PLL2
; ; Starting pCode block
    CONFIG  PLLDIV=1
; ; Starting pCode block for Ival
[...]    code

and some arrays and strings after that.

Thanks a lot.

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

Comment By: Borut Ražem (borutr)
Date: 2012-07-10 03:26

Message:
Sorry Diego, you are right, the bug "Status" was still "Open", but
"Resolution" was "Fixed". Now I changed the "Resolution" back to "None".

Borut

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

Comment By: Borut Ražem (borutr)
Date: 2012-07-10 03:14

Message:
> IMHO, I think this bug isn't fixed.

Unfortunately this is true. But it was never stated as fixed in an
appropriate way, only a temporary patch was applied to make pic18 usable
and the bug was not closed.

Workaround for the problem with several #pragma configs is to use a single
"all in one" #pragma config.

For example instead using: 

#pragma config EBTRB=OFF
#pragma config EBTR3=OFF
#pragma config EBTR2=OFF
#pragma config EBTR1=OFF

you can use:

#pragma config EBTRB=OFF, EBTR3=OFF, EBTR2=OFF, EBTR1=OFF

Borut

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

Comment By: Diego Herranz (diegoherranz)
Date: 2012-07-10 02:25

Message:
IMHO, I think this bug isn't fixed.

If you modify config_bug.c adding another pragma config like:

#pragma config WDTPS = 1

You see this error again:
$ sdcc --use-non-free -mpic16 -p18f26j50 config_bug.c
config_bug.asm:487:Error[152]   Executable code and data must be defined in
an appropriate section.
[...]

Useful data:

$ sdcc -v
SDCC :
mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08
3.2.0 #8008 (Jul  6 2012) (Linux)

$ gpasm -v
gpasm-0.14.2 #711 (Jul  9 2012)




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

Comment By: Borut Ražem (borutr)
Date: 2012-07-06 01:45

Message:
Patch sdcc-3.2.0-config_fix.diff applied in svn revision #8008, since it is
pic16 specific, it doesn't affect other targets and it is low risk.

The more appropriate 'config' Map approach can be implemented after the
SDCC 3.2.0 release, so I'm leaving this bug opened.

Borut

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

Comment By: Herbert Pötzl (hpoetzl)
Date: 2012-07-03 14:29

Message:
IMHO the best approach would be to move all the CONFIG directives to the
beginning before any actual code is generated (tried that with a new
'config' Map but that didn't work and I'm lost in the sdcc source code :)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3539804&group_id=599