Re: [Sdcc-user] PIC port, __naked not working, Bus error, signal 11: SIGSEGV

[Raphael N. <rn...@we...>]

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