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

[Michael Ring]

One day (In a far far away future) I will understand how this whole 
compiler magic works ;-)

Thank you very much for your fix, the LED's on my Board are not (yet) 
blinking, but at least now the code seems to run fine in gdb.

Have a nice evening, will contact you when I have a little more code 
working for nxp and stm chips...


Michael

Am 14.01.14 20:29, schrieb Jeppe Græsdal Johansen:
> Should be fixed now. The cpupi code estimated that it needed a copy of 
> the TGPIO_Registers record on the stack even though it was passed by 
> reference :)
>
> Den 14-01-2014 09:47, Michael Ring skrev:
>> 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
>>
>>
>>
>> _______________________________________________
>> 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/dea61587/attachment.html>