access violations on new ARM hardware

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

access violations on new ARM hardware

Björn Schreiber
Hi *.*,

   we use an ARM based SOM for a device developed by us, the software is
developed using Lazarus. Now we are testing a new version of the SOM and
can't get our software to work.

Old SOM:
Samsung S5PV210
one Cortex-A8 (?) core
Windows CE 6.0 R3 kernel

New SOM:
Freescale Vybrid dual core CPU
one Cortex-A5 core
one Cortex-M4 core
Windows CE 6.0 R3 / Windows Compact 7

   In order to gather some more information (even wince-stub isn't
running on the device so we can't use GDB) we used a fresh install of
FPC 2.6.4.

   A empty FPC program worked without any problems, even using the
Windows function MessageBox() worked flawless. But if we included the
unit SysUtils we got access violations right after the start - the same
behaviour as our Lazarus application.

   By modifying the original source of SysUtils by some MessageBox()
calls we tracked the first access violation down to the procedure
GetFormatSettings, to be more precise to the first call of GetLocaleStr.
If we removed the call to GetFormatSettings, the empty FPC program
worked flawless.

FPC was used with the following command line:
fpc -Twince -Parm -FiC:\FPC\2.6.4\units\arm-wince\rtl\inc -O- test.pas

   Any ideas what goes wrong? Did we miss a compiler switch, perhaps?


Greetings

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: access violations on new ARM hardware

Mark Morgan Lloyd-5
Björn Schreiber wrote:

> Hi *.*,
>
>   we use an ARM based SOM for a device developed by us, the software is
> developed using Lazarus. Now we are testing a new version of the SOM and
> can't get our software to work.
>
> Old SOM:
> Samsung S5PV210
> one Cortex-A8 (?) core
> Windows CE 6.0 R3 kernel
>
> New SOM:
> Freescale Vybrid dual core CPU
> one Cortex-A5 core
> one Cortex-M4 core
> Windows CE 6.0 R3 / Windows Compact 7
>
>   In order to gather some more information (even wince-stub isn't
> running on the device so we can't use GDB) we used a fresh install of
> FPC 2.6.4.
>
>   A empty FPC program worked without any problems, even using the
> Windows function MessageBox() worked flawless. But if we included the
> unit SysUtils we got access violations right after the start - the same
> behaviour as our Lazarus application.
>
>   By modifying the original source of SysUtils by some MessageBox()
> calls we tracked the first access violation down to the procedure
> GetFormatSettings, to be more precise to the first call of GetLocaleStr.
> If we removed the call to GetFormatSettings, the empty FPC program
> worked flawless.
>
> FPC was used with the following command line:
> fpc -Twince -Parm -FiC:\FPC\2.6.4\units\arm-wince\rtl\inc -O- test.pas
>
>   Any ideas what goes wrong? Did we miss a compiler switch, perhaps?

Since nobody else has suggested anything: is the new hardware
susceptible to alignment errors in a way that the old hardware wasn't?

Have you tried a later compiler? My recollection is that there were
issues on SPARC that might have included alignment problems, and on that
architecture I had to abandon 2.6.4 promptly and move onto trunk. I'm
currently testing Lazarus trunk at about 47318 is OK with FPC 2.7.1
29398 on various CPUs running Linux, can't speak for CE.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: access violations on new ARM hardware

Björn Schreiber
Am 26.01.2015 um 21:15 schrieb Mark Morgan Lloyd:
> Since nobody else has suggested anything: is the new hardware
> susceptible to alignment errors in a way that the old hardware wasn't?

   The question is: how can we know? The ARM documentation says only
"The processor supports unaligned accesses."


> Have you tried a later compiler?

   The problem is that we need the ppcarm.exe for Windows and there are
no prebuilded snapshots available. Seems to me that we must offer some
time to build it by ourself - never done before.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: access violations on new ARM hardware

Mark Morgan Lloyd-5
Björn Schreiber wrote:
> Am 26.01.2015 um 21:15 schrieb Mark Morgan Lloyd:
>> Since nobody else has suggested anything: is the new hardware
>> susceptible to alignment errors in a way that the old hardware wasn't?
>
>   The question is: how can we know? The ARM documentation says only "The
> processor supports unaligned accesses."

Which is obviously a good start.

>> Have you tried a later compiler?
>
>   The problem is that we need the ppcarm.exe for Windows and there are
> no prebuilded snapshots available. Seems to me that we must offer some
> time to build it by ourself - never done before.

I've done it for Linux and found it painless, but I know so little about
CE that my opinion shouldn't be trusted.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: access violations on new ARM hardware

Marco van de Voort
In reply to this post by Björn Schreiber
In our previous episode, Bj?rn Schreiber said:
> Am 26.01.2015 um 21:15 schrieb Mark Morgan Lloyd:
> > Since nobody else has suggested anything: is the new hardware
> > susceptible to alignment errors in a way that the old hardware wasn't?
>
>    The question is: how can we know? The ARM documentation says only
> "The processor supports unaligned accesses."

First narrow it down to the exact line that causes the problem. E.g. copy
relevant parts of sysutils into a program that only uses system, and then
start testing, till you know which line provokes the problem.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: access violations on new ARM hardware

Björn Schreiber
Am 27.01.2015 um 17:58 schrieb Marco van de Voort:

> First narrow it down to the exact line that causes the problem. E.g. copy
> relevant parts of sysutils into a program that only uses system, and then
> start testing, till you know which line provokes the problem.

   What I can say at this time is that the first access violation
happens at the line

   Result:=s;

in the function SysUtils.GetLocalStr in an empty FPC program only
including the unit SysUtils. But I suppose the problem lies elsewhere.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: access violations on new ARM hardware

Sven Barth-2

Am 28.01.2015 10:08 schrieb "Björn Schreiber" <[hidden email]>:
>
> Am 27.01.2015 um 17:58 schrieb Marco van de Voort:
>
>
>> First narrow it down to the exact line that causes the problem. E.g. copy
>> relevant parts of sysutils into a program that only uses system, and then
>> start testing, till you know which line provokes the problem.
>
>
>   What I can say at this time is that the first access violation happens at the line
>
>   Result:=s;
>
> in the function SysUtils.GetLocalStr in an empty FPC program only including the unit SysUtils. But I suppose the problem lies elsewhere.

As said by Marco: please try to reproduce it by copying parts of SysUtils (e.g. GetLocaleStr) into an empty program (and using that code of course ^^) to find an example code that shows the problem.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: access violations on new ARM hardware

Björn Schreiber
Am 28.01.2015 um 11:21 schrieb Sven Barth:
> As said by Marco: please try to reproduce it by copying parts of
> SysUtils (e.g. GetLocaleStr) into an empty program (and using that code
> of course ^^) to find an example code that shows the problem.

   I narrowed it down to the following minimal program:

--- Schnipp On ---
program test;

var
   AString: String;

function AFunction: String;
var
   S: WideString;

begin
   S := 'Test';
   AFunction := S;
end;

begin
   AString := AFunction;
end.
--- Schnipp Off ---

Compiled with a fresh install of FPC 2.6.4 with the command line

   fpc -Twince -Parm test.pas

runs without any problem on the old hardware (Cortex-A8) but produces a
runtime error 216 on the new hardware (Cortex-A5).
   This code follows SysUtils.GetLocalStr, called by
SysUtils.GetFormatSettings. The error doesn't occur if S is defined as
String instead WideString or if I do it without the function call.

Regards,
   Björn
--
Björn Schreiber
DRIGUS GmbH

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: access violations on new ARM hardware

Sven Barth-2

Am 28.01.2015 16:45 schrieb "Björn Schreiber" <[hidden email]>:
>
> Am 28.01.2015 um 11:21 schrieb Sven Barth:
>
>> As said by Marco: please try to reproduce it by copying parts of
>> SysUtils (e.g. GetLocaleStr) into an empty program (and using that code
>> of course ^^) to find an example code that shows the problem.
>
>
>   I narrowed it down to the following minimal program:
>
> --- Schnipp On ---
> program test;
>
> var
>   AString: String;
>
> function AFunction: String;
> var
>   S: WideString;
>
> begin
>   S := 'Test';
>   AFunction := S;
> end;
>
> begin
>   AString := AFunction;
> end.
> --- Schnipp Off ---
>
> Compiled with a fresh install of FPC 2.6.4 with the command line
>
>   fpc -Twince -Parm test.pas
>
> runs without any problem on the old hardware (Cortex-A8) but produces a runtime error 216 on the new hardware (Cortex-A5).
>   This code follows SysUtils.GetLocalStr, called by SysUtils.GetFormatSettings. The error doesn't occur if S is defined as String instead WideString or if I do it without the function call.

Could be a bug in the conversion routines from WideString to AnsiString. Since we are currently preparing release 3.0.0 it might be best to test with that as well (cause string handling was changed in 2.7.1). It shouldn't be hard to compile for WinCE either, just download the source (e.g. by using SVN) and do the following:

First build a native 3.0.0 and install it:

make clean all install INSTALL_PREFIX=c:\wherever\you\want

For example I myself usually install to D:\fpc\3.0.0

make clean all CPU_TARGET=arm OS_TARGET=wince BINUTILSPREFIX=arm-wince- CROSSBINDIR=c:\whereever\arm-wince-as\is

You can also pass additional option like CPU type and FPU type using OPT="xyz" with the same parameters as for the compiler.

Afterwards you can install the newly compiled compiler and RTL:

make crossinstall CPU_TARGET=arm OS_TARGET=wince INSTALL_PREFIX=c:\wherever\you\want

Now you merely need a fpc.cfg. For this you can copy your 2.6.4's fpc.cfg, copy it to c:\wherever\you\want\bin\i386-win32 (or x86_64-win64 if you built a 64-bit native compiler) and adjust its paths. Note: the path c:\wherever\you\want is the one you specified for  INSTALL_PREFIX.

If you have any problems, feel free to ask.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: access violations on new ARM hardware

Björn Schreiber
Am 28.01.2015 um 17:24 schrieb Sven Barth:
> Could be a bug in the conversion routines from WideString to AnsiString.
> Since we are currently preparing release 3.0.0 it might be best to test
> with that as well (cause string handling was changed in 2.7.1). It
> shouldn't be hard to compile for WinCE either, just download the source
> (e.g. by using SVN) and do the following:

   Thanks for the instruction, very helpful. Unfortunately I have to
prioritise other stuff first so this must wait. But I come back when I
continue testing.


Regards,
   Björn Schreiber
--
Björn Schreiber
DRIGUS GmbH

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: access violations on new ARM hardware

Björn Schreiber
In reply to this post by Björn Schreiber
Am 28.01.2015 um 16:44 schrieb Björn Schreiber:

> --- Schnipp On ---
> program test;
>
> var
>     AString: String;
>
> function AFunction: String;
> var
>     S: WideString;
>
> begin
>     S := 'Test';
>     AFunction := S;
> end;
>
> begin
>     AString := AFunction;
> end.
> --- Schnipp Off ---

   Some new information: the manufacturer of the SOM did a analysis of
the compiled program. We were told that the program makes use of the SWP
instruction which is deprecated since ARMv6 and was deactivated in the
kernel we used. They build a new kernel with the deprecated instruction
activated which is running the test program without any error.
   Now we can use this new kernel for further tests.

   Is there any compiler switch to control the generated code and
therefore the chance to avoid this deprecated instruction?


Greetings,
   Björn
--
Björn Schreiber
DRIGUS GmbH


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: access violations on new ARM hardware

Jonas Maebe-2

On 11 Feb 2015, at 12:48, Björn Schreiber wrote:

>  Some new information: the manufacturer of the SOM did a analysis of  
> the compiled program. We were told that the program makes use of the  
> SWP instruction which is deprecated since ARMv6 and was deactivated  
> in the kernel we used. They build a new kernel with the deprecated  
> instruction activated which is running the test program without any  
> error.
>  Now we can use this new kernel for further tests.
>
>  Is there any compiler switch to control the generated code and  
> therefore the chance to avoid this deprecated instruction?

The swp instruction is in the RTL. It will not be included if you  
compile the RTL for an architecture that does not support this  
instruction. The Cortex-A5 is an ARMv7 class cpu, so adding -Cparmv7  
to your cross-options when building the RTL should work.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: access violations on new ARM hardware

Jeppe Johansen-3
In reply to this post by Björn Schreiber

Small correction: -Cparmv7a


------ Oprindelig besked------

Fra: Jonas Maebe

Dato: ons., 11. feb. 2015 13:36

Til: FPC-Pascal users discussions;

Emne:Re: [fpc-pascal] access violations on new ARM hardware


On 11 Feb 2015, at 12:48, Björn Schreiber wrote:>  Some new information: the manufacturer of the SOM did a analysis of  > the compiled program. We were told that the program makes use of the  > SWP instruction which is deprecated since ARMv6 and was deactivated  > in the kernel we used. They build a new kernel with the deprecated  > instruction activated which is running the test program without any  > error.>  Now we can use this new kernel for further tests.>>  Is there any compiler switch to control the generated code and  > therefore the chance to avoid this deprecated instruction?The swp instruction is in the RTL. It will not be included if you  compile the RTL for an architecture that does not support this  instruction. The Cortex-A5 is an ARMv7 class cpu, so adding -Cparmv7  to your cross-options when building the RTL should work.Jonas_______________________________________________fpc-pascal maillist  - [hidden email]p://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: access violations on new ARM hardware

Björn Schreiber
In reply to this post by Jonas Maebe-2
Am 11.02.2015 um 13:36 schrieb Jonas Maebe:
> instruction. The Cortex-A5 is an ARMv7 class cpu, so adding -Cparmv7
> to your cross-options when building the RTL should work.

   Thanks for the info, I will give it a try.


Greetings,
   Björn
--
Björn Schreiber
DRIGUS GmbH


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal