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

2014-01-14 Thread 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   = $5000;
  LPC_GPIO0_BASE = (LPC_AHB_BASE + $0);

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]
strbr1,[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 reinierolislag...@gmail.com
Dato: man., jan. 13, 2014 13:44
Emne: [fpc-pascal] ARM Linux crosscompiler: compiles but... 
executable gives segmentation fault

Til: fpc-pascal@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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




___
fpc-pascal maillist  -fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2014-01-14 Thread Reinier Olislagers
On 10/01/2014 13:27, Reinier Olislagers wrote:
 Thanks to earlier help I got to build an ARM Linux cross compiler module
 in fpcup which even compiles fpcup itself (both using trunk and stable
 starting compiler):
 opt=-fPIC -dFPC_ARMHF
 crossopt=-CpARMV6 -CaEABIHF -CfVFPV2
 
 fpc -g -gl -Tlinux -Parm simple.lpr
 
 Question: should I have compiled with -fPIC?
Just tried without -fPIC, and -CpARMV6Z=compiles and runs nicely
Rest of the options the same.

Tried again with -fPIC, -CpARMV6Z=segmentation fault.

So I'll just leave -fPIC off then

Could also cross-compile fpcup (which uses lclbase) and it seems to run.

@Michael, Jeppe etc: thanks a lot for the help, and hope the other
problem gets solved.

Thanks a lot,
Reinier
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

2014-01-14 Thread 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   = $5000;
  LPC_GPIO0_BASE = (LPC_AHB_BASE + $0);

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]
strbr1,[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 reinierolislag...@gmail.com
Dato: man., jan. 13, 2014 13:44
Emne: [fpc-pascal] ARM Linux crosscompiler: compiles but... 
executable gives segmentation fault

Til: fpc-pascal@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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




___
fpc-pascal maillist  -fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




___
fpc-pascal maillist  -fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2014-01-14 Thread 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   = $5000;
  LPC_GPIO0_BASE = (LPC_AHB_BASE + $0);

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]
strbr1,[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 reinierolislag...@gmail.com
Dato: man., jan. 13, 2014 13:44
Emne: [fpc-pascal] ARM Linux crosscompiler: compiles but... 
executable gives segmentation fault

Til: fpc-pascal@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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




___
fpc-pascal maillist  -fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




___
fpc-pascal maillist  -fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




___
fpc-pascal maillist  -fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2014-01-13 Thread Michael Ring
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.


Michael

Am 11.01.14 14:17, schrieb Reinier Olislagers:

On 11/01/2014 14:03, Florian Klämpfl wrote:

Just type fpc -i to see the possible options. If one does not understand
those options, one does not need them :)

I had a suspicion you were going to say that ;)


As said, arm targets are very different and every target has its optimal
parameters.

Exactly. Having some additional info IMO helps to at least verify the
choice somebody else made in his script/wiki page/build tool is correct ;)


E.g. on my NAS running debian 6.0 I build for thumb with
CROSSOPT=-O4 -Cparmv5te -CIthumb
and for normal arm with
CROSSOPT=-O4 -Cparmv5te
Depending on the distro, one needs different -Fl switches etc. Not to
talk about different OSes.

Yep. -Fl is covered in the cross compiling article, of course also in
the build faq.


Yes. But in my opinion then this info should go to the raspi page. I bet
99% of the raspi users don't know what instruction set the raspi needs.
So explaining that -Cparmv6 turns on armv6 code generation does not help
them :)

Ehm, this is exactly why I didn't put it on the raspi page ;)... but a
link from there to the current page would be nice...


So when /is/ specifying the ABI needed? When supporting a microcontroller?

Seriously: if you want to use an armel compiler to build e.g. for armhf.

Ok.


But then you probably want to have also some other defines and you
really have to know what you are doing. Or if you have a special armel
setup where you want to use hard float code and abi for speed reasons,
e.g. when having softfloat raspberry debian installed. But these are
special setups, officially not supported.

Got it. Not interested in going that deep ;)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

2014-01-13 Thread Reinier Olislagers
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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

2014-01-13 Thread 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 reinierolislag...@gmail.com
Dato: man., jan. 13, 2014 13:44
Emne: [fpc-pascal] ARM Linux crosscompiler: compiles but... executable gives 
segmentation fault
Til: fpc-pascal@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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2014-01-13 Thread 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]
strbr1,[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 reinierolislag...@gmail.com
Dato: man., jan. 13, 2014 13:44
Emne: [fpc-pascal] ARM Linux crosscompiler: compiles but... executable 
gives segmentation fault

Til: fpc-pascal@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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

2014-01-11 Thread Reinier Olislagers
On 11/01/2014 08:02, Florian Klämpfl wrote:
 Am 10.01.2014 13:27, schrieb Reinier Olislagers:
 crossopt=-CpARMV6 -CaEABIHF -CfVFPV2
 
 The eabihf switch is not needed if the cross compiler is build with
 -dFPC_ARMHF.
 
 Though it shouldn't change anything regarding the crash.

Thanks.

As I couldn't find any existing docs, I've started this page:
http://wiki.lazarus.freepascal.org/ARM_compiler_options

Please feel free, as usual, to modify with corrections/additions.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

2014-01-11 Thread Florian Klämpfl
Am 11.01.2014 11:14, schrieb Reinier Olislagers:
 On 11/01/2014 08:02, Florian Klämpfl wrote:
 Am 10.01.2014 13:27, schrieb Reinier Olislagers:
 crossopt=-CpARMV6 -CaEABIHF -CfVFPV2

 The eabihf switch is not needed if the cross compiler is build with
 -dFPC_ARMHF.

 Though it shouldn't change anything regarding the crash.
 
 Thanks.
 
 As I couldn't find any existing docs, I've started this page:
 http://wiki.lazarus.freepascal.org/ARM_compiler_options

Hmm, is this really needed? It clutters only information. I would
completly remove the page and collect only the needed  parameters for
particular targets at their page because every arm target is different.

 
 Please feel free, as usual, to modify with corrections/additions.

I see so need for the abi documention. Specifing the abi is normally not
needed. It confuses only.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

2014-01-11 Thread Reinier Olislagers
On 11/01/2014 13:32, Florian Klämpfl wrote:
 Am 11.01.2014 11:14, schrieb Reinier Olislagers:
 On 11/01/2014 08:02, Florian Klämpfl wrote:
 Am 10.01.2014 13:27, schrieb Reinier Olislagers:
 As I couldn't find any existing docs, I've started this page:
 http://wiki.lazarus.freepascal.org/ARM_compiler_options

First off, thanks again for responding - I do really appreciate solid
info from people who really know what's going on ;)

 Hmm, is this really needed? 
I actually would expect something like that in fpc docs, yes.

It clutters only information. I would
 completly remove the page and collect only the needed  parameters for
 particular targets at their page because every arm target is different.

Well, that depends on your point of view - I think it nicely bundles
information in one spot. Also, there may not be pages for all options
(ARMv7 for example).
People compiling e.g. for Raspberry Pi may not care what all the options
do but they would if they changed from e.g. the original softfloat
raspberry debian to raspbian which has hardfloat. Having this kind of
page IMO helps clarify nicely what the options are.

 Please feel free, as usual, to modify with corrections/additions.
 
 I see so need for the abi documention. Specifing the abi is normally not
 needed. It confuses only.
Well, I wouldn't know. I'm just collecting snippets from all over the
wiki, forum posts, mailing lists and trying to make sense out of them
(like the EABIHF versus -dFPC_ARMHF thing). Sort of trying to demistify
a cargo cult

Of course, I'll be happy to add a note saying that specifying the ABI
normally is not needed - that'll save some other poor soul from
wondering whether it's him, the phase of the moon or the wrong ABI
parameter that caused the compiler to catch fire ;)

So when /is/ specifying the ABI needed? When supporting a microcontroller?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

2014-01-11 Thread Florian Klämpfl
Am 11.01.2014 13:38, schrieb Reinier Olislagers:
 On 11/01/2014 13:32, Florian Klämpfl wrote:
 Am 11.01.2014 11:14, schrieb Reinier Olislagers:
 On 11/01/2014 08:02, Florian Klämpfl wrote:
 Am 10.01.2014 13:27, schrieb Reinier Olislagers:
 As I couldn't find any existing docs, I've started this page:
 http://wiki.lazarus.freepascal.org/ARM_compiler_options
 
 First off, thanks again for responding - I do really appreciate solid
 info from people who really know what's going on ;)
 
 Hmm, is this really needed? 
 I actually would expect something like that in fpc docs, yes.

Just type fpc -i to see the possible options. If one does not understand
those options, one does not need them :)

 
 It clutters only information. I would
 completly remove the page and collect only the needed  parameters for
 particular targets at their page because every arm target is different.
 
 Well, that depends on your point of view - I think it nicely bundles
 information in one spot. Also, there may not be pages for all options
 (ARMv7 for example).

As said, arm targets are very different and every target has its optimal
parameters. E.g. on my NAS running debian 6.0 I build for thumb with
CROSSOPT=-O4 -Cparmv5te -CIthumb
and for normal arm with
CROSSOPT=-O4 -Cparmv5te
Depending on the distro, one needs different -Fl switches etc. Not to
talk about different OSes.

 People compiling e.g. for Raspberry Pi may not care what all the options
 do but they would if they changed from e.g. the original softfloat
 raspberry debian to raspbian which has hardfloat. Having this kind of
 page IMO helps clarify nicely what the options are.

Yes. But in my opinion then this info should go to the raspi page. I bet
99% of the raspi users don't know what instruction set the raspi needs.
So explaining that -Cparmv6 turns on armv6 code generation does not help
them :)

 
 Please feel free, as usual, to modify with corrections/additions.

 I see so need for the abi documention. Specifing the abi is normally not
 needed. It confuses only.
 Well, I wouldn't know. I'm just collecting snippets from all over the
 wiki, forum posts, mailing lists and trying to make sense out of them
 (like the EABIHF versus -dFPC_ARMHF thing). 

Yes, this unneeded -Caeabihf parameter floats around for years already :(

 Sort of trying to demistify
 a cargo cult
 
 Of course, I'll be happy to add a note saying that specifying the ABI
 normally is not needed - that'll save some other poor soul from
 wondering whether it's him, the phase of the moon or the wrong ABI
 parameter that caused the compiler to catch fire ;)
 
 So when /is/ specifying the ABI needed? When supporting a microcontroller?

Simple: if you don't know when it's needed, you don't need it ;)
Seriously: if you want to use an armel compiler to build e.g. for armhf.
But then you probably want to have also some other defines and you
really have to know what you are doing. Or if you have a special armel
setup where you want to use hard float code and abi for speed reasons,
e.g. when having softfloat raspberry debian installed. But these are
special setups, officially not supported.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

2014-01-11 Thread Reinier Olislagers
On 11/01/2014 14:03, Florian Klämpfl wrote:
 Just type fpc -i to see the possible options. If one does not understand
 those options, one does not need them :)
I had a suspicion you were going to say that ;)

 As said, arm targets are very different and every target has its optimal
 parameters. 
Exactly. Having some additional info IMO helps to at least verify the
choice somebody else made in his script/wiki page/build tool is correct ;)

 E.g. on my NAS running debian 6.0 I build for thumb with
 CROSSOPT=-O4 -Cparmv5te -CIthumb
 and for normal arm with
 CROSSOPT=-O4 -Cparmv5te
 Depending on the distro, one needs different -Fl switches etc. Not to
 talk about different OSes.
Yep. -Fl is covered in the cross compiling article, of course also in
the build faq.

 Yes. But in my opinion then this info should go to the raspi page. I bet
 99% of the raspi users don't know what instruction set the raspi needs.
 So explaining that -Cparmv6 turns on armv6 code generation does not help
 them :)
Ehm, this is exactly why I didn't put it on the raspi page ;)... but a
link from there to the current page would be nice...

 So when /is/ specifying the ABI needed? When supporting a microcontroller?
 Seriously: if you want to use an armel compiler to build e.g. for armhf.
Ok.

 But then you probably want to have also some other defines and you
 really have to know what you are doing. Or if you have a special armel
 setup where you want to use hard float code and abi for speed reasons,
 e.g. when having softfloat raspberry debian installed. But these are
 special setups, officially not supported.
Got it. Not interested in going that deep ;)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

2014-01-10 Thread Reinier Olislagers
Hi all,

For the Dutch among us: de dag die je wist dat zou komen...

Thanks to earlier help I got to build an ARM Linux cross compiler module
in fpcup which even compiles fpcup itself (both using trunk and stable
starting compiler):
opt=-fPIC -dFPC_ARMHF
crossopt=-CpARMV6 -CaEABIHF -CfVFPV2

fpc -g -gl -Tlinux -Parm simple.lpr

Question: should I have compiled with -fPIC?

Uploaded resulting executable
http://ubuntuone.com/0y3yXGcU8fEXR6OTMyvfGN

The program:
program simple;

begin
  writeln('hello');
end.

Relevant fpc.cfg snippet:
#IFDEF CPUARM
#IFDEF LINUX
-CpARMV6
-CaEABIHF
-CfVFPV2
-FDC:\development\cross\bin\arm-linux\
-XParm-linux-
-Xd
-FlC:\development\cross\lib\arm-linux\
-Xr/usr/lib
#ENDIF
#ENDIF

However, running the resulting binary on my virtual Raspbian fails with
a segmentation fault. Running under gdb gives
(gdb) run
Starting program: /root/simple

Program received signal SIGSEGV, Segmentation fault.
0x0002b6e4 in
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR ()
(gdb) bt
#0  0x0002b6e4 in
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR ()
#1  0x8124 in _start ()


On the raspbian (which is built on hardfloat), file gives
simple: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically
linked, for GNU/Linux 2.0.0, not stripped

Compare with system-provided binary:
file /usr/bin/yes
/usr/bin/yes: ELF 32-bit LSB executable, ARM, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.26,
BuildID[sha1]=0xf2df9a56df5c7b5490f7dba10f2163acb8971fce, stripped

Question: should I be worried about the GNU/Linux 2.0.0 above?

ldd simple
not a dynamic executable

I've run
readelf -a simple
uploaded to
http://ubuntuone.com/1cAX24nbcPkGo05fFWDbOr

readelf -a /usr/bin/yes
uploaded to
http://ubuntuone.com/6FD65xgakyE9eZOIme2z47

Question: what steps should I take now?

Thanks
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

2014-01-10 Thread Michael Ring
I think this is an ARMV6 specific Problem, I also realized while 
debugging on embedded target that it does not work anymore, same code 
compiled for ARMV7 debugs (and runs) just fine...


Until now I did not find the time to search for the revision that broke 
armv6m.


Michael

Am 10.01.14 13:27, schrieb Reinier Olislagers:

Hi all,

For the Dutch among us: de dag die je wist dat zou komen...

Thanks to earlier help I got to build an ARM Linux cross compiler module
in fpcup which even compiles fpcup itself (both using trunk and stable
starting compiler):
opt=-fPIC -dFPC_ARMHF
crossopt=-CpARMV6 -CaEABIHF -CfVFPV2

fpc -g -gl -Tlinux -Parm simple.lpr

Question: should I have compiled with -fPIC?

Uploaded resulting executable
http://ubuntuone.com/0y3yXGcU8fEXR6OTMyvfGN

The program:
program simple;

begin
   writeln('hello');
end.

Relevant fpc.cfg snippet:
#IFDEF CPUARM
#IFDEF LINUX
-CpARMV6
-CaEABIHF
-CfVFPV2
-FDC:\development\cross\bin\arm-linux\
-XParm-linux-
-Xd
-FlC:\development\cross\lib\arm-linux\
-Xr/usr/lib
#ENDIF
#ENDIF

However, running the resulting binary on my virtual Raspbian fails with
a segmentation fault. Running under gdb gives
(gdb) run
Starting program: /root/simple

Program received signal SIGSEGV, Segmentation fault.
0x0002b6e4 in
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR ()
(gdb) bt
#0  0x0002b6e4 in
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR ()
#1  0x8124 in _start ()


On the raspbian (which is built on hardfloat), file gives
simple: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically
linked, for GNU/Linux 2.0.0, not stripped

Compare with system-provided binary:
file /usr/bin/yes
/usr/bin/yes: ELF 32-bit LSB executable, ARM, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.26,
BuildID[sha1]=0xf2df9a56df5c7b5490f7dba10f2163acb8971fce, stripped

Question: should I be worried about the GNU/Linux 2.0.0 above?

ldd simple
 not a dynamic executable

I've run
readelf -a simple
uploaded to
http://ubuntuone.com/1cAX24nbcPkGo05fFWDbOr

readelf -a /usr/bin/yes
uploaded to
http://ubuntuone.com/6FD65xgakyE9eZOIme2z47

Question: what steps should I take now?

Thanks
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

2014-01-10 Thread Reinier Olislagers
On 10/01/2014 13:39, Michael Ring wrote:
 I think this is an ARMV6 specific Problem, I also realized while
 debugging on embedded target that it does not work anymore, same code
 compiled for ARMV7 debugs (and runs) just fine...
 
 Until now I did not find the time to search for the revision that broke
 armv6m.
 
 Michael

Thanks Michael, guess I'll have to abandon my virtual Raspberry... or
slowly bisect trunk revisions ;)

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

2014-01-10 Thread Pierre Free Pascal


 -Message d'origine-
 De : fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal-
 boun...@lists.freepascal.org] De la part de Michael Ring
 Envoyé : vendredi 10 janvier 2014 13:40
 À : FPC-Pascal users discussions
 Objet : Re: [fpc-pascal] ARM Linux crosscompiler: compiles but...
 executable gives segmentation fault
 
 I think this is an ARMV6 specific Problem, I also realized while
 debugging on embedded target that it does not work anymore, same code
 compiled for ARMV7 debugs (and runs) just fine...
 
 Until now I did not find the time to search for the revision that broke
 armv6m.
 
 Michael
 
 Am 10.01.14 13:27, schrieb Reinier Olislagers:
  Hi all,
 
  For the Dutch among us: de dag die je wist dat zou komen...
 
  Thanks to earlier help I got to build an ARM Linux cross compiler
 module
  in fpcup which even compiles fpcup itself (both using trunk and
 stable
  starting compiler):
  opt=-fPIC -dFPC_ARMHF
  crossopt=-CpARMV6 -CaEABIHF -CfVFPV2
 
  fpc -g -gl -Tlinux -Parm simple.lpr
 
  Question: should I have compiled with -fPIC?
 
  Uploaded resulting executable
  http://ubuntuone.com/0y3yXGcU8fEXR6OTMyvfGN
 
  The program:
  program simple;
 
  begin
 writeln('hello');
  end.
 
  Relevant fpc.cfg snippet:
  #IFDEF CPUARM
  #IFDEF LINUX
  -CpARMV6
  -CaEABIHF
  -CfVFPV2
  -FDC:\development\cross\bin\arm-linux\
  -XParm-linux-
  -Xd
  -FlC:\development\cross\lib\arm-linux\
  -Xr/usr/lib
  #ENDIF
  #ENDIF
 
  However, running the resulting binary on my virtual Raspbian fails
 with
  a segmentation fault. Running under gdb gives
  (gdb) run
  Starting program: /root/simple
 
  Program received signal SIGSEGV, Segmentation fault.
  0x0002b6e4 in
  SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR ()

  Maybe it is just using an unsupported instruction?

what does x /10i $pc return?

Pierre Muller
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

2014-01-10 Thread Michael Ring
It looked more like the stack got messed up, for me it crashed after the 
second (if I remember correctly) procedure was called. I can dig into 
this on Sunday evening, after returning to my home.


Michael

Am 10.01.14 14:29, schrieb Pierre Free Pascal:



-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal-
boun...@lists.freepascal.org] De la part de Michael Ring
Envoyé : vendredi 10 janvier 2014 13:40
À : FPC-Pascal users discussions
Objet : Re: [fpc-pascal] ARM Linux crosscompiler: compiles but...
executable gives segmentation fault

I think this is an ARMV6 specific Problem, I also realized while
debugging on embedded target that it does not work anymore, same code
compiled for ARMV7 debugs (and runs) just fine...

Until now I did not find the time to search for the revision that broke
armv6m.

Michael

Am 10.01.14 13:27, schrieb Reinier Olislagers:

Hi all,

For the Dutch among us: de dag die je wist dat zou komen...

Thanks to earlier help I got to build an ARM Linux cross compiler

module

in fpcup which even compiles fpcup itself (both using trunk and

stable

starting compiler):
opt=-fPIC -dFPC_ARMHF
crossopt=-CpARMV6 -CaEABIHF -CfVFPV2

fpc -g -gl -Tlinux -Parm simple.lpr

Question: should I have compiled with -fPIC?

Uploaded resulting executable
http://ubuntuone.com/0y3yXGcU8fEXR6OTMyvfGN

The program:
program simple;

begin
writeln('hello');
end.

Relevant fpc.cfg snippet:
#IFDEF CPUARM
#IFDEF LINUX
-CpARMV6
-CaEABIHF
-CfVFPV2
-FDC:\development\cross\bin\arm-linux\
-XParm-linux-
-Xd
-FlC:\development\cross\lib\arm-linux\
-Xr/usr/lib
#ENDIF
#ENDIF

However, running the resulting binary on my virtual Raspbian fails

with

a segmentation fault. Running under gdb gives
(gdb) run
Starting program: /root/simple

Program received signal SIGSEGV, Segmentation fault.
0x0002b6e4 in
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR ()

   Maybe it is just using an unsupported instruction?

what does x /10i $pc return?

Pierre Muller
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

2014-01-10 Thread Reinier Olislagers
On 10/01/2014 14:29, Pierre Free Pascal wrote:
 Am 10.01.14 13:27, schrieb Reinier Olislagers:
 a segmentation fault. Running under gdb gives
 (gdb) run
 Starting program: /root/simple

 Program received signal SIGSEGV, Segmentation fault.
 0x0002b6e4 in
 SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR ()
 
   Maybe it is just using an unsupported instruction?
 
 what does x /10i $pc return?

(gdb) run
Starting program: /root/simple

Program received signal SIGSEGV, Segmentation fault.
0x0002b6e4 in
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR ()
(gdb) bt
#0  0x0002b6e4 in
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR ()
#1  0x8124 in _start ()
(gdb) x /10i $pc
= 0x2b6e4
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR+168:
str r0, [r2, r1]
   0x2b6e8
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR+172:
ldr r7, [r11, #-48] ; 0x30
   0x2b6ec
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR+176:
mov r0, r7
   0x2b6f0
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR+180:
ldmdb   r11, {r4, r5, r6, r7, r8, r9, r11, sp, pc}
   0x2b6f4
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR+184:
andeq   r7, r1, r4, lsr #23
   0x2b6f8
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR+188:
andeq   r0, r0, r0, ror #4
   0x2b6fc SYSTEM_$$_STRINGTOPPCHAR$ANSISTRING$SMALLINT$$PPCHAR:
push{r4, lr}
   0x2b700 SYSTEM_$$_STRINGTOPPCHAR$ANSISTRING$SMALLINT$$PPCHAR+4:
ldr r4, [pc, #24]   ; 0x2b720
SYSTEM_$$_STRINGTOPPCHAR$ANSISTRING$SMALLINT$$PPCHAR+36
   0x2b704 SYSTEM_$$_STRINGTOPPCHAR$ANSISTRING$SMALLINT$$PPCHAR+8:
add r4, pc, r4
   0x2b708 SYSTEM_$$_STRINGTOPPCHAR$ANSISTRING$SMALLINT$$PPCHAR+12:
ldr r0, [r0]

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

2014-01-10 Thread Florian Klämpfl
Am 10.01.2014 13:27, schrieb Reinier Olislagers:

 crossopt=-CpARMV6 -CaEABIHF -CfVFPV2

The eabihf switch is not needed if the cross compiler is build with
-dFPC_ARMHF.

Though it shouldn't change anything regarding the crash.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal