Raphael,
if it is a lo risk, go ahead and commit the patch ASAP.
Borut
Raphael Neider wrote:
> Hi Kusti,
>
>> After a lot of pruning I got the code down to:
>>
>> unsigned char x;
>>
>> void test() __naked {
>> if (x) {
>> x = 1;
>> }
>> }
>
> Very good work; this helped a lot!
>
>> which when compiled with parameters:
>>
>> SDCCFLAGS = "-Wl,-m,-s 18f4550.lkr" -mpic16 -p18f4550 \
>> --disable-warning 85 --std-sdcc99 --obanksel=3 --pno-banksel
>>
>> produces SIGSEGV .
>>
>> If I remove the __naked the problem disappears, but I'm back in
>> square one.
>>
>> So this appears to be compiler bug. I tried to look for this in the list
>> archives but I could not find anything related to that.
>>
>> Now I have specific questions:
>>
>> 1) Should I file a bug?
>
> No need: please find a patch attached.
>
> The bug removes an invalid cast of a pCodeLabel into a
> pCodeInstruction and stays safe in that no (new) NULL pointer
> dereferences can occur. Code triggering this bug is likely to be buggy
> (a label with no instruction following is probably not a good thing to
> have; and I think this is the only circumstance at which this
> particular bug is triggered), so the risk of fixing this is low. The
> benefit would be one less obstacle for those experimenting with the
> __naked keyword using the pic16 target.
>
> @Borut: Shall I include this into 2.9.0 (would be my vote) or wait
> till after its release?
>
> Kusti, can you apply the attached patch locally and check if your
> originally failing code compiles with the patch?
>
>> 2) How can I circumvent this?
>
> Adding the (mandatory!) __asm return __endasm; to return to the
> calling function worked around the issue for me.
>
>> My actual problem is that the compilers emits a lot of code like:
>>
>> 002C C000 FFE5 01503 MOVFF r0x00, POSTDEC1
>> 0030 C000 FFE5 01504 MOVFF r0x01, POSTDEC1
>> 0034 C000 FFE5 01505 MOVFF r0x02, POSTDEC1
>> 0038 C000 FFE5 01506 MOVFF r0x03, POSTDEC1
>> 003C C000 FFE5 01507 MOVFF r0x04, POSTDEC1
>> 0040 C000 FFE5 01508 MOVFF r0x05, POSTDEC1
>>
>> that I would like to avoid, all I want is for the compiler to allocate
>> these are global variables used solely by the interrupt so that there
>> is no need to save/restore them...I know 'naked' alone would not do this
>> but it seems like a necessary step in getting there...?
>
> Currently, the compiler assumes all local/temporary variables to
> reside in the access bank; moving them to arbitrary memory locations
> is not that easy (on first sight), as this assumption also holds
> during register allocation and I do not readily know how to change
> that (nor if there is a single place to do so...). You might file a
> feature request for this so that it is not lost.
>
>> 3) I seem to recall some list discussion relating to PIC / inline
>> assembly and that it does not work or something but I cannot
>> find that discussion. Is there a problem there?
>
> Ummm, well, I am not aware of problems in conjunction with inline
> assembly, except that accessing local variables/parameters passed into
> a function is not easily possible (inspection of the .asm to map
> locals to r0xYYs and hoping the assignment survives the next
> compilation is not really suitable, but the best I have to offer right
> now).
>
> Best regards,
> Raphael
------------------------------------------------------------------------------
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
