Re: [fpc-devel] first results of using fpc resources instead of lazarus resources

[Marco van de Voort]

On Mon, Nov 30, 2009 at 10:59:45PM +0100, Giulio Bernardi wrote:
> >> perfectly now. Can it save without the BOM even if file had it before?
> > 
> > Yes, that would be possible.
> > 
> > But I think this should be fixed in fpcres. Otherwise windows
> > users editing the lfm files will easily run into this error. 
> > 
> Fixed in rev 14292.
> I had to fix TParser too, since fcl-res uses ObjectTextToBinary to compile 
> dfm/xfm/lfm files.

Is this a single revision and do you think it is mergable?

This is the last week that high-priority stuff can be merged to 2.4.0, and
since the new resource support is a highlight of 2.4.0, this could be a
candidate.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] first results of using fpc resources instead of lazarus resources

[Giulio Bernardi]

Marco van de Voort ha scritto:

On Mon, Nov 30, 2009 at 10:59:45PM +0100, Giulio Bernardi wrote:

perfectly now. Can it save without the BOM even if file had it before?

Yes, that would be possible.

But I think this should be fixed in fpcres. Otherwise windows
users editing the lfm files will easily run into this error. 


Fixed in rev 14292.
I had to fix TParser too, since fcl-res uses ObjectTextToBinary to compile 
dfm/xfm/lfm files.


Is this a single revision and do you think it is mergable?


Yes: http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=14292

It is very simple. If the UTF-8 bom is found at the beginning, it is skipped.
I think it shouldn't hurt: knowing that a file is utf-8 or not makes no 
difference for TParser.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] debug information for Variant type

[Paul Ishenin]

Hello,  FPC developers' list.

Is it known that gdb returns "void" type for the Variant variables when 
STABS debug info is used?


When DWARF is used Variant = TVarData which is also not perfect. I want 
to see only variant value, not the whole record when I debug the program 
in Lazarus. When I need the whole record I can always evaluate TVarData(V).


Is it possible to improve both stabs and dwarf info?

--
Best regards,
Paul Ishenin.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpc.cfg Question

[Henry Vermaak]

2009/12/1 Andrew Haines :
> Hi,
>
> I tried to modify my fpc.cfg like so:
>
> #IFDEF arm
> -XParm-wince-
> -Xd
> #ENDIF
>
> #IFDEF i386
> -Xd
> -Fl/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/32
> -Fl/emul/linux/x86/usr/lib32
> -Fl/emul/linux/x86/lib
> -Fl/lib32
> -Fl/usr/lib32
> -Fl/usr/local/lib32
> #ENDIF
>
> I have a ppc386(linux) and also ppcarm(wince)
>
>
> my computer is linux 64 bit. However these options do not seem to have
> any effect. I have to add these to the "Other" options in lazarus under
> Project -> Compler Options.
>
> commenting out the lines that start with "#" will fix the problem until
> I use a compiler other than the one the options are needed for.
>
> What am I doing wrong?

Hmm, I'm sure I've done something like this.  Does cpuarm and cpui386
work instead of arm and i386?

Henry
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpc.cfg Question

[Marco van de Voort]

In our previous episode, Henry Vermaak said:
> Hmm, I'm sure I've done something like this.  Does cpuarm and cpui386
> work instead of arm and i386?

That would be my guess too, and otherwise inspect fpc -va output.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] error when crosscompile for arm

[Jonas Maebe]

On 30 Nov 2009, at 23:47, Dariusz Mazur wrote:

Is this possible to add special directive, that left the same  
behavior of comp under arm?

or any other hack?


Only a hardware hack: solder an x87-fpu on your ARM processor and use  
that... This cannot be fixed in software without emulating an x87-fpu  
(or 128 bit floats), because a double precision floating point type  
does not have the required precision to represent all comp values.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpc.cfg Question

[Jonas Maebe]

On 01 Dec 2009, at 10:52, Henry Vermaak wrote:


Hmm, I'm sure I've done something like this.  Does cpuarm and cpui386
work instead of arm and i386?


Yes. The "i386" and "arm" defines are conditional defines that are  
present when compiling the compiler itself with code generator support  
for those architectures. The cpui386/cpuarm/... defines are present  
when you are using a compiler that generates code for those  
architectures. So the former are only usable in the compiler sources  
itself.



Jonas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] ARM Illegal instruction debugging howto

[ik]

‎Thanks Jonas,

I'll try it this evening and see if it works.

Ido

http://ik.homelinux.org/


On Tue, Dec 1, 2009 at 12:09 AM, Jonas Maebe wrote:

>
> On 30 Nov 2009, at 22:22, ik wrote:
>
> > It uses ARM EABI version. My latest attempt provides me the following
> > executable:
> > ELF 32-bit LSB executable, ARM, version 1, statically linked, not
> stripped
> >
> > While on "regular" Linux the same file identifier is:
> > hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically
> > linked, for GNU/Linux 2.4.0, stripped
> >
> > A normal executable in OM is:
> > ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.24,
> > dynamically linked (uses shared libs), stripped
> >
> > So how can I look for the proper build of ppcrossarm and normal ppcarm ?
>
> Static or dynamic is unlikely to be related to your problems with illegal
> instructions. The backtrace you previously posted (with the illegal opcode
> in sysinitfpu suggests that you are not compiling an EABI compiler, because
> that one defaults to softfloat. There's another thing I just noticed in your
> previous mail:
>
> > make OPT='dFPC_ARMEL -dFPC_ABI_EABI -Xd' OS=TARGET=linux CPU_TARGET=arm
>
> That first parameter is missing a dash (-), it should read -dFPC_ARMEL.
> Without that dash, you will not get an EABI compiler.
>
> You should also not define -dFPC_ABI_EABI yourself. The compiler will
> define that symbol when the current target is EABI. Defining that symbol
> while you are not compiling for an EABI platform will only result in an RTL
> with invalid code.
>
>
> Jonas___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] debug information for Variant type

[Jonas Maebe]

On 01 Dec 2009, at 10:50, Paul Ishenin wrote:

Is it known that gdb returns "void" type for the Variant variables  
when STABS debug info is used?


Not that I know. Stabs is pretty much legacy though.

When DWARF is used Variant = TVarData which is also not perfect. I  
want to see only variant value, not the whole record when I debug  
the program in Lazarus. When I need the whole record I can always  
evaluate TVarData(V).


Is it possible to improve both stabs and dwarf info?


In Stabs it is impossible to only show the actual variant value, as  
Stabs does not know a "variant" concept. DWARF does, but GDB doesn't  
support it yet.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] debug information for Variant type

[Paul Ishenin]

Jonas Maebe wrote:

In Stabs it is impossible to only show the actual variant value, as 
Stabs does not know a "variant" concept. 


And lazarus does not need that. I think it would be enough to mark the 
variant variables somehow (not "void").



DWARF does, but GDB doesn't support it yet.


We only need to disctinct Variant and TVarData. So when user want to 
watch Variable variable we will perform TVarData() cast and show the 
value ourself. When TVarData is used we will show as TVarData (iow, as 
record).


Best regards,
Paul Ishenin.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] debug information for Variant type

[Jonas Maebe]

On 01 Dec 2009, at 11:53, Paul Ishenin wrote:


Jonas Maebe wrote:


DWARF does, but GDB doesn't support it yet.


We only need to disctinct Variant and TVarData. So when user want to  
watch Variable variable we will perform TVarData() cast and show the  
value ourself. When TVarData is used we will show as TVarData (iow,  
as record).


Would it be enough if the type name were changed to "variant"? It  
would not be 100% safe (since "variant" is not a reserved word, anyone  
can declare a variable/type/... with the name "variant"), but I don't  
immediately see another solution.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpc.cfg Question

[Andrew Haines]

Henry Vermaak wrote:
> 2009/12/1 Andrew Haines :
>> Hi,
>>
>> I tried to modify my fpc.cfg like so:
>>
>> #IFDEF arm
>>
>> #IFDEF i386
>> What am I doing wrong?
> 
> Hmm, I'm sure I've done something like this.  Does cpuarm and cpui386
> work instead of arm and i386?
> 

Yes this was the problem thank you very much!

Andrew Haines
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] debug information for Variant type

[Paul Ishenin]

Jonas Maebe wrote:
Would it be enough if the type name were changed to "variant"? It 
would not be 100% safe (since "variant" is not a reserved word, anyone 
can declare a variable/type/... with the name "variant"), but I don't 
immediately see another solution.

I think yes.

Best regards,
Paul Ishenin.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] ARM Illegal instruction debugging howto

[ik]

The program now execute but does not do anything:

program hello;

begin
  writeln('Hello World');
end.

it does not print anything on the screen.

strace only uses execv as the single executing line.

What am I missing here ?

Ido

http://ik.homelinux.org/


On Tue, Dec 1, 2009 at 12:41 PM, ik  wrote:

> ‎Thanks Jonas,
>
> I'll try it this evening and see if it works.
>
>
> Ido
>
> http://ik.homelinux.org/
>
>
> On Tue, Dec 1, 2009 at 12:09 AM, Jonas Maebe wrote:
>
>>
>> On 30 Nov 2009, at 22:22, ik wrote:
>>
>> > It uses ARM EABI version. My latest attempt provides me the following
>> > executable:
>> > ELF 32-bit LSB executable, ARM, version 1, statically linked, not
>> stripped
>> >
>> > While on "regular" Linux the same file identifier is:
>> > hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically
>> > linked, for GNU/Linux 2.4.0, stripped
>> >
>> > A normal executable in OM is:
>> > ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.24,
>> > dynamically linked (uses shared libs), stripped
>> >
>> > So how can I look for the proper build of ppcrossarm and normal ppcarm ?
>>
>> Static or dynamic is unlikely to be related to your problems with illegal
>> instructions. The backtrace you previously posted (with the illegal opcode
>> in sysinitfpu suggests that you are not compiling an EABI compiler, because
>> that one defaults to softfloat. There's another thing I just noticed in your
>> previous mail:
>>
>> > make OPT='dFPC_ARMEL -dFPC_ABI_EABI -Xd' OS=TARGET=linux CPU_TARGET=arm
>>
>> That first parameter is missing a dash (-), it should read -dFPC_ARMEL.
>> Without that dash, you will not get an EABI compiler.
>>
>> You should also not define -dFPC_ABI_EABI yourself. The compiler will
>> define that symbol when the current target is EABI. Defining that symbol
>> while you are not compiling for an EABI platform will only result in an RTL
>> with invalid code.
>>
>>
>> Jonas___
>> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>>
>
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] ARM Illegal instruction debugging howto

[Jonas Maebe]

On 01 Dec 2009, at 19:09, ik wrote:

> The program now execute but does not do anything:
> 
> program hello;
> 
> begin
>  writeln('Hello World');
> end.
> 
> it does not print anything on the screen.
> 
> strace only uses execv as the single executing line.
> 
> What am I missing here ?

A debugger and single stepping from the start of the program to see what fails 
where.


Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] ARM Illegal instruction debugging howto

[ik]

gdb ./hello
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-oe-linux-gnueabi".
For bug reporting instructions, please see:
...
Reading symbols from /var/volatile/tmp/hello...done.
(gdb) break 1
Breakpoint 1 at 0x807c: file ../../../../../tmp/hello.pp, line 1.
(gdb) break 4
Note: breakpoint 1 also set at pc 0x807c.
Breakpoint 2 at 0x807c: file ../../../../../tmp/hello.pp, line 4.
(gdb) r
Starting program: /var/volatile/tmp/hello

Program received signal SIGILL, Illegal instruction.
0x8abc in SYSTEM_FPC_CPUCODEINIT ()
(gdb) bt
#0  0x8abc in SYSTEM_FPC_CPUCODEINIT ()
#1  0xfbbc in SYSTEM_init ()
#2  0xb268 in fpc_initializeunits ()
#3  0x807c in $main () at ../../../../../tmp/hello.pp:3
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0xf670 in SYSTEM_REENABLE_SIGNAL$LONGINT$$BOOLEAN ()
#2  0x in ?? ()
(gdb) c
Continuing.

Program exited with code 0330.

Thanks,

Ido
http://ik.homelinux.org/


On Tue, Dec 1, 2009 at 8:31 PM, Jonas Maebe wrote:

>
> On 01 Dec 2009, at 19:09, ik wrote:
>
> > The program now execute but does not do anything:
> >
> > program hello;
> >
> > begin
> >  writeln('Hello World');
> > end.
> >
> > it does not print anything on the screen.
> >
> > strace only uses execv as the single executing line.
> >
> > What am I missing here ?
>
> A debugger and single stepping from the start of the program to see what
> fails where.
>
>
> Jonas___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] ARM Illegal instruction debugging howto

[Jonas Maebe]

On 01 Dec 2009, at 19:36, ik wrote:

> gdb ./hello
> GNU gdb (GDB) 7.0
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later > 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "arm-oe-linux-gnueabi".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /var/volatile/tmp/hello...done.
> (gdb) break 1
> Breakpoint 1 at 0x807c: file ../../../../../tmp/hello.pp, line 1.
> (gdb) break 4
> Note: breakpoint 1 also set at pc 0x807c.
> Breakpoint 2 at 0x807c: file ../../../../../tmp/hello.pp, line 4.
> (gdb) r
> Starting program: /var/volatile/tmp/hello
> 
> Program received signal SIGILL, Illegal instruction.
> 0x8abc in SYSTEM_FPC_CPUCODEINIT ()
> (gdb) bt
> #0  0x8abc in SYSTEM_FPC_CPUCODEINIT ()
> #1  0xfbbc in SYSTEM_init ()
> #2  0xb268 in fpc_initializeunits ()
> #3  0x807c in $main () at ../../../../../tmp/hello.pp:3
> (gdb) c
> Continuing.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x in ?? ()
> (gdb) bt
> #0  0x in ?? ()
> #1  0xf670 in SYSTEM_REENABLE_SIGNAL$LONGINT$$BOOLEAN ()
> #2  0x in ?? ()
> (gdb) c
> Continuing.
> 
> Program exited with code 0330.

This does not appear to correspond to what you previously said about strace, 
since strace normally also show signals. I would guess (but these are really 
just wild guesses)  that the problem is one or more of the following:
a) the sigprocmask system call on your device has a different interface than 
the one expected by the rtl, or its sigset has a different number of elements
b) the definition of the signal handler context in the rtl does not correspond 
to whatever the kernel on your device uses. You can compare the definitions in 
rtl/linux/arm/sighndh.inc with similar ones referred to from ucontext_t or a 
similar type in your C headers; it doesn't matter if those structs contain more 
fields *after* the ones defined in the Pascal include file, but if they use a 
different order or other fields are defined in between, then that is a problem.

I'm not really interested in digging further in this though (I have too many 
things on my plate as it is), so I hope that someone else can continue helping 
you to debug and fix your problem.


Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] error when crosscompile for arm

[Dariusz Mazur]

Jonas Maebe pisze:


On 30 Nov 2009, at 23:47, Dariusz Mazur wrote:

Is this possible to add special directive, that left the same 
behavior of comp under arm?

or any other hack?


Only a hardware hack: solder an x87-fpu on your ARM processor and use 
that... This cannot be fixed in software without emulating an x87-fpu 
(or 128 bit floats), because a double precision floating point type 
does not have the required precision to represent all comp values.
I was thinking,  that soft FPU can emulate this, or compiler can use 
comp internal as int64 and external as real.

But now I remove comp and go one.


From these stage I have one suggestion.
on linux-i368  directive $E claim: switch $E is not supported
on linux-arm the same switch cause compiling error (problems with units 
generating with different switch ) remark: all compiled with -CfSOFT



Darek


--
 Darek




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] ARM: problem with uses VFP instructions

[Dariusz Mazur]

HI
I try to crosscompile for arm (uclibc and eabi). Source and listing 
error below.

But when I remove dynlibs form uses section, all goes OK
When I check link.res only few things are changed in section input
prt0->cprt0.o
->crti.o

What I should looking for.


program hello;
uses
 dynlibs,
 sysconst,
 rtlconsts,
 sysutils,
 classes;
var
 i : double;
begin

i:=int(1.1);
writeln('hello world ',i);
end.


and receive error:

darek2...@darek2008-desktop:~/fpcarm/lib/fpc/2.5.1$ ./ppcrossarm 
hello.pas >rr
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR: 
/home/darek2008/fpcarm/praca/arm-linux/hello.o uses VFP instructions, 
whereas hello does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target 
specific data of file /home/darek2008/fpcarm/praca/arm-linux/hello.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR: 
./units/arm-linux/rtl/system.o uses VFP instructions, whereas hello does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target 
specific data of file ./units/arm-linux/rtl/system.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR: 
./units/arm-linux/rtl/objpas.o uses VFP instructions, whereas hello does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target 
specific data of file ./units/arm-linux/rtl/objpas.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR: 
./units/arm-linux/rtl/dynlibs.o uses VFP instructions, whereas hello 
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target 
specific data of file ./units/arm-linux/rtl/dynlibs.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR: 
./units/arm-linux/rtl/sysutils.o uses VFP instructions, whereas hello 
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target 
specific data of file ./units/arm-linux/rtl/sysutils.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR: 
./units/arm-linux/rtl/rtlconsts.o uses VFP instructions, whereas hello 
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target 
specific data of file ./units/arm-linux/rtl/rtlconsts.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR: 
./units/arm-linux/rtl/sysconst.o uses VFP instructions, whereas hello 
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target 
specific data of file ./units/arm-linux/rtl/sysconst.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR: 
./units/arm-linux/rtl/unix.o uses VFP instructions, whereas hello does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target 
specific data of file ./units/arm-linux/rtl/unix.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR: 
./units/arm-linux/rtl/errors.o uses VFP instructions, whereas hello does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target 
specific data of file ./units/arm-linux/rtl/errors.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR: 
./units/arm-linux/rtl/unixtype.o uses VFP instructions, whereas hello 
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target 
specific data of file ./units/arm-linux/rtl/unixtype.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR: 
./units/arm-linux/rtl/baseunix.o uses VFP instructions, whereas hello 
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target 
specific data of file ./units/arm-linux/rtl/baseunix.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR: 
./units/arm-linux/rtl/unixutil.o uses VFP instructions, whereas hello 
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target 
specific data of file ./units/arm-linux/rtl/unixutil.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR: 
./units/arm-linux/rtl/syscall.o uses VFP instructions, whereas hello 
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target 
specific data of file ./units/arm-linux/rtl/syscall.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR: 
./units/arm-linux/rtl/dl.o uses VFP instructions, whereas hello does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target 
specific data of file ./units/arm-linux/rtl/dl.o

./units/arm-linux/rtl/cprt0.o: In function `_start':
(.text+0x4c): undefined reference to `__libc_start_main'

--
 Darek




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] ARM Illegal instruction debugging howto

[ik]

OK, thank you for your help.

For now I did not find anything that is different on the function that is
causing the termination of the program.

Does anyone here knows what/where else I should be looking for, or how to
better debug the problem ?

Thanks,
Ido

http://ik.homelinux.org/


On Tue, Dec 1, 2009 at 9:08 PM, Jonas Maebe wrote:

>
> On 01 Dec 2009, at 19:36, ik wrote:
>
> > gdb ./hello
> > GNU gdb (GDB) 7.0
> > Copyright (C) 2009 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html
> >>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> > and "show warranty" for details.
> > This GDB was configured as "arm-oe-linux-gnueabi".
> > For bug reporting instructions, please see:
> > ...
> > Reading symbols from /var/volatile/tmp/hello...done.
> > (gdb) break 1
> > Breakpoint 1 at 0x807c: file ../../../../../tmp/hello.pp, line 1.
> > (gdb) break 4
> > Note: breakpoint 1 also set at pc 0x807c.
> > Breakpoint 2 at 0x807c: file ../../../../../tmp/hello.pp, line 4.
> > (gdb) r
> > Starting program: /var/volatile/tmp/hello
> >
> > Program received signal SIGILL, Illegal instruction.
> > 0x8abc in SYSTEM_FPC_CPUCODEINIT ()
> > (gdb) bt
> > #0  0x8abc in SYSTEM_FPC_CPUCODEINIT ()
> > #1  0xfbbc in SYSTEM_init ()
> > #2  0xb268 in fpc_initializeunits ()
> > #3  0x807c in $main () at ../../../../../tmp/hello.pp:3
> > (gdb) c
> > Continuing.
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x in ?? ()
> > (gdb) bt
> > #0  0x in ?? ()
> > #1  0xf670 in SYSTEM_REENABLE_SIGNAL$LONGINT$$BOOLEAN ()
> > #2  0x in ?? ()
> > (gdb) c
> > Continuing.
> >
> > Program exited with code 0330.
>
> This does not appear to correspond to what you previously said about
> strace, since strace normally also show signals. I would guess (but these
> are really just wild guesses)  that the problem is one or more of the
> following:
> a) the sigprocmask system call on your device has a different interface
> than the one expected by the rtl, or its sigset has a different number of
> elements
> b) the definition of the signal handler context in the rtl does not
> correspond to whatever the kernel on your device uses. You can compare the
> definitions in rtl/linux/arm/sighndh.inc with similar ones referred to from
> ucontext_t or a similar type in your C headers; it doesn't matter if those
> structs contain more fields *after* the ones defined in the Pascal include
> file, but if they use a different order or other fields are defined in
> between, then that is a problem.
>
> I'm not really interested in digging further in this though (I have too
> many things on my plate as it is), so I hope that someone else can continue
> helping you to debug and fix your problem.
>
>
> Jonas___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] error when crosscompile for arm

[Jonas Maebe]

On 02 Dec 2009, at 00:15, Dariusz Mazur wrote:

> Jonas Maebe pisze:
>> 
>> On 30 Nov 2009, at 23:47, Dariusz Mazur wrote:
>> 
>>> Is this possible to add special directive, that left the same behavior of 
>>> comp under arm?
>>> or any other hack?
>> 
>> Only a hardware hack: solder an x87-fpu on your ARM processor and use 
>> that... This cannot be fixed in software without emulating an x87-fpu (or 
>> 128 bit floats), because a double precision floating point type does not 
>> have the required precision to represent all comp values.
> I was thinking,  that soft FPU can emulate this,

It could once someone adds float80 support to it. Currently only single and 
double are supported.

> or compiler can use comp internal as int64 and external as real.

That would result in precision loss.

> From these stage I have one suggestion.
> on linux-i368  directive $E claim: switch $E is not supported

I think that's quite self-explanatory.

> on linux-arm the same switch cause compiling error (problems with units 
> generating with different switch ) remark: all compiled with -CfSOFT

Compiling with -Cfsoft and {$E-} will indeed probably causes errors. The 
compiler should simply give an error when you try to do that.


Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel