[fpc-pascal] ARM Linux crosscompiler: compiles but... executable gives segmentation fault

[Michael Ring]

I have boiled down my problem to this democode. The problem is in the 
begin line of set Direction. The sp gets moved to 0x0fff8f94 which is 
unititialized Space before RAM.

The Reason is that the offset for the local var .Lj9 (.long -32840) is 
plain wrong. It might be me doing something strange (Setting the record 
to absolute) but this works fine on armv7m.

Jeppe, could you perhaps have a look, I compared with armv7m code and 
there the whole handling of local vars seems to work totally different.

I am doing something unusual here, so another conclusion is that my 
problem is most likely not related to the segfault described, sorry for 
messing this thread up.

Michael

program hello;
{$mode objfpc}
{$modeswitch advancedrecords}

type
   TGPIO_Bit = 0..11;
   TGPIO_Direction = (GPIO_Input, GPIO_Output);
type
   TGPIO_Registers = record
     MASKED_ACCESS: array [0 .. 4095] of longword;
     RESERVED1    : array [0 .. 4095] of longword;
     DIR          : longword;
     &IS           : longword;
     IBE          : longword;
     IEV          : longword;
     IE           : longword;
     RIS          : longword;
     MIS          : longword;
     IC           : longword;
     procedure setDirection(bit : TGPIO_Bit; direction : TGPIO_Direction);
   end;

const
   LPC_AHB_BASE   = $50000000;
   LPC_GPIO0_BASE = (LPC_AHB_BASE + $00000);

var
   GPIO0 : TGPIO_Registers absolute(LPC_GPIO0_BASE);

procedure TGPIO_Registers.setDirection(bit : TGPIO_Bit; direction : 
TGPIO_Direction);
begin
   DIR := DIR and (not (1 shl bit)) or (longWord(direction) shl bit);
end;

var
   i : integer;
begin
   i := 0;
   GPIO0.setDirection(i,GPIO_Output);
end.


Am 13.01.14 15:39, schrieb Michael Ring:
> I guess not, when I remember correctly this has already been repaired 
> for armv6m. The problem for me is that .Lj9 is defined as a negative 
> number. As a consequence r13 points to nirvana and
>
> str     r0,[r13, #8] creates an Exception.
>
>
> # [87] begin
>         push    {r4,r14}
>         ldr     r4,.Lj9
>         add     r13,r13,r4
> # Var bit located at r13+0
> # Var direction located at r13+4
> # Var $self located at r13+8
>         str     r0,[r13, #8]
>         strb    r1,[r13]
>         str     r2,[r13, #4]
> .Ll2:
>
> .....
>
> .Lj9:
>         .long   -32840
> .Lj7:
>         .long   32768
> .Lj10:
>         .long   32840
> .Lt2:
>
> Am 13.01.14 15:15, schrieb Jeppe Græsdal Johansen:
>> Might be related to the mla/mls optimization which somehow has been 
>> enabled even though it's still broken
>>
>> ----- Reply message -----
>> Fra: "Reinier Olislagers" <reinierolislagers at gmail.com>
>> Dato: man., jan. 13, 2014 13:44
>> Emne: [fpc-pascal] ARM Linux crosscompiler: compiles but... 
>> executable gives segmentation fault
>> Til: <fpc-pascal at lists.freepascal.org>
>>
>> On 13/01/2014 12:34, Michael Ring wrote:
>> > I had a look at armv6m yesterday evening, parts of my code run fine in
>> > gdb, the code crashes in the init of a procedure when trying to prepare
>> > the access to contents of a set.
>> > The address of the set seems to get calculated totally wrong ending up
>> > in a memory access at the end of the chip's address range.
>> > Not sure if this is related to your problem, I will try to boil 
>> down the
>> > example to a bare minimum to see where the generated code differs
>> > between armv7m and armv6m.
>>
>> Thanks a lot, Michael!
>>
>> _______________________________________________
>> fpc-pascal maillist  - fpc-pascal at lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>>
>>
>>
>>
>> _______________________________________________
>> fpc-pascal maillist  -fpc-pascal at lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
>
>
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20140114/f5806d32/attachment.html>