Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
> -Message d'origine-
> De : fpc-devel [mailto:fpc-devel-boun...@lists.freepascal.org] De la
> part de LacaK
> Envoyé : mardi 14 mars 2017 13:30
> À : fpc-devel@lists.freepascal.org
> Objet : [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal
> on Windows
>
> Hi,
>
> I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from
> Intel
> IPP package (they distribute ".lib" and also ".dll" for Windows and
> ".a"
> for Linux)
>
> Can I link in FPC (on Windows) at compile time to this ".lib" versions
> ?
> Or only possible way is link at runtime using ".dll" (and distribute
> DLLs with my EXE)?
> (I guess, that FPC can not link to libraries not created in FPC itself.
> So format of supplied ".lib" is not compatible with what FPC expects)
>
> I am trying do something like:
> {$linklib libippi}
> function ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep:
> int;
> roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
> thresholdGT: Ipp8u;
> valueGT: Ipp8u): IppStatus; external; // 'ippi.dll';
Did you try this:
function ippiThreshold(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT:
Ipp8u;
valueGT: Ipp8u): IppStatus; external 'ippi.dll' name
'ippiThreshold_LTValGTVal_8u_C1IR';
You should use
objdump -p ippi.dll
to get the names of the exported procedures/functions.
You could also test cppdecl; modifier for linux target,
In the hope it will help,
Pierre Muller
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.0.2 released!
Hi Olivier, > -Message d'origine- > De : fpc-devel [mailto:fpc-devel-boun...@lists.freepascal.org] De la > part de Olivier Coursière via fpc-devel > Envoyé : dimanche 12 mars 2017 18:24 > À : FPC developers' list > Cc : Olivier Coursière > Objet : Re: [fpc-devel] FPC 3.0.2 released! > > Hi, > > On 17/02/2017 18:55, Marco van de Voort wrote: > > Hello, > > > > Finally, FPC 3.0.2 has landed. FPC 3.0.2 is an update to 3.0.0 that > > contains some compiler bugfixes and library progress since 3.0.0 > > > > Building is still in progress and some formats (deb) and other minor > targets > > might > > not be available yet. > > > I finally took time to build the Haiku target. Here is the package : > http://www.nan.tf/download/fpc-3.0.2.i386-haiku.tar. I suspect it was built using alpha 4, am I right? > Sorry for the delay, but better late than never ;-) Thanks for this! I will try to put it into 3.0.2 release Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ppudump question
Maybe you are using empty sets in your source code?
An empty set:
[]
has no elements and thus the compiler cannot know what
the type of the elements are.
In the hope that this will help,
Pierre Muller
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Gennady Agranov
Envoyé : dimanche 23 août 2015 00:46
À : fpc-devel@lists.freepascal.org
Objet : [fpc-devel] ppudump question
Hi,
1. I have code that heavily uses enums/sets
When I use ppudump to print *.ppu files I see some sets reported with
null ElType and I do not understand what causes them :(
And I do not believe that they are referenced at all...
Any ideas why set is reported with no ElType?
Thanks,
Gennady
Example:
json version:
{
Type: set,
Id: 236,
Size: 1,
Base: 0,
Max: 0,
ElType: null
},
text version:
** Definition Id 236 **
Set definition
Type symbol : (7357) Nil
DefOptions :
DefStates :
Element type : (7361) Nil
Size : 1
Set Base : 0
Set Max : 0
xml version:
set
id236/id
size1/size
base0/base
max0/max
eltype/eltype
/set
{
Type: set,
Id: 92,
Size: 1,
Base: 0,
Max: 0,
ElType: null
}
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Testing FPC on PPC Mac
Hi Mark, you should use -s option for compilation. This will generate a ppas.sh script that contains the call to the linker. Maybe removing this command line option will be enough to fix linking. I hope you will be able to generate a recent Free Pascal Complier on your machine! Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd Envoyé : jeudi 12 février 2015 12:17 À : fpc-devel@lists.freepascal.org Objet : Re: [fpc-devel] Testing FPC on PPC Mac Mark Morgan Lloyd wrote: Afaik that's it, binutils+make+gdb from xcode + the installer. Thanks, I'll see where I get to. Testing 2.7.1 at revision 29398, compiling with make NOGDB=1 OPT='-V2.6.4 -O- -gl -Xs-' all which has worked for the other architectures I've tried it on, I get /bin/mkdir -p powerpc/units/powerpc-darwin /usr/local/bin/ppcppc -Ur -Xs -O2 -n -Fupowerpc -Fusystems -Fu/usr/local/src/fpc/trunk-2.7.1-29398/rtl/units/powerpc-darwin -Fipowerpc -FE. -FUpowerpc/units/powerpc-darwin -dRELEASE -V2.6.4 -O- -gl -Xs- -dpowerpc -dGDB -dBROWSERLOG -Fuppcgen -Sew pp.pas /usr/bin/ld: unknown flag: -macosx_version_min An error occurred while linking pp.pas(244,13) Error: Error while linking pp.pas(244,13) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted I presume that ld from Xcode 2.0 is slightly too old, and that that flag isn't supported. Is there a way of accommodating this at the command line, or is the only way by finding the flag in the build files and disabling it? [Slightly later] It looks as though it's in the compiler itself, so I'd presumably have to start off with a cross-build or work back to 2.6.0... which is a lot of work for an architecture that I don't really use. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Snapshots mixed on FTP
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Gabor Boros Envoyé : lundi 12 janvier 2015 08:50 À : FPC developers' list Objet : Re: [fpc-devel] Snapshots mixed on FTP 2015.01.11. 13:41 keltezéssel, Tomas Hajny írta: On Sun, January 11, 2015 10:04, Gabor Boros wrote: Hi Gabor, In ftp://ftp.freepascal.org/pub/fpc/snapshot/ v30 and v31 directories is empty. v26/i386-win32 and v26/x86_64-linux and other directories contains 3.0.1 files. v27/i386-win32 and v27/x86_64-linux and other directories contains 3.1.1 files. Thank you, hopefully sorted out now (symbolic links trunk and fixes moved and files placed in the proper directory). Tomas ftp://ftp.freepascal.org/pub/fpc/snapshot/v30/source directory contains source of fixes_2_6. Should be fixed now. Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question about runtime error 219
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Gennady Agranov Envoyé : samedi 10 janvier 2015 05:19 À : FPC developers' list Objet : [fpc-devel] Question about runtime error 219 Hi All, What exactly -CR (Verify object method call validity) code generation is checking and how tested is it? For debugging I prefer to enable all possibles checks - range, overflow, ... But i can not use -CR: 1. I passed some var array of array parameter - error 219 - changed to var array - works... 2. I use generics and 2.7.1 and when I am calling some method that is implemented in grandfather class - runtime error 219 :( But, If I do not set -CR - everything works just fine... Any internal scoop about -CR - please? The -CR option add, before any virtual method call, a call to a special function fpc_check_object_ext to check that the real class of the class variable which is used is indeed a child of the explicit class type specification of this method. Example var c : class; begin derivedclass(c).method1; the call to fpc_check_object_ext will be done with the true class of c (as given by the address of the vitual method table) to the virtual method table of derived type This is more or less equivalent to assert that c is indeed a child type of derivedclass. It is possible that this option -CR will generate a RTE 219 in perfectly working code, a possible case is when two different derived classes implement compatible child methods, that end up at the same position in the virtual method table, but without a common virtual definition for the common ancestor. Pierre Muller assert ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC on SPARC Linux
Hi Mark,
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd
Envoyé : mercredi 7 janvier 2015 12:01
À : fpc-devel@lists.freepascal.org
Objet : Re: [fpc-devel] FPC on SPARC Linux
Mark Morgan Lloyd wrote:
Pierre Free Pascal wrote:
Hi Mark,
did you try to generate the libraries needed to compile FP IDE with
GDB support by
using the script in fpcsrc/packages/gdbint/gen-gdblib-inc.sh ?
If you have a build directory of a certain GDB version (let's say
7.8.1
as an example), simply copy the script over to build-gdb-7.8.1/gdb,
and run
it locally.
This script tries to determine all the libraries needed
and generates a second script called copy-libs.sh
that you should call in turn, with a simple arg, the target
directory,
for example, ./copy-libs.sh ~/pas/libgdb-7.8.1
After that,
using make -C ./packages/gdbint GDBLIBDIR=~/pas/libgdb-7.8.1
followed by
make -C ide GDBLIBDIR=~/pas/libgdb-7.8.1
should makes the things much easier.
One caveat is to avoid system installed libraries to be installed
instead of the ones inside this directory.
On systems on which I got this problem, I had to manually
remove all lines {$librarypath XXX}
where XXX resolved to /usr/lib or /lib
I've found where we discussed this before, about August 2013. Part of
the solution at the time was to use -Xd but...
In the hope this will help,
Pierre Muller
Thanks Pierre, I'll investigate. OTOH the existing GDB 6.7.1
libraries
appear sufficient for 2.2.4 through 2.4.4 and for 2.6.4, all on the
same
system without any underlying adjustments.
The problem is that there's now a -Xd being put in the internal command
line, without a -Fl for the location of libgcc.a since it's no longer
being picked up from fpc.cfg.
This should not matter if you use the script I was talking about,
because GDB compilation also required libgcc, so that it should be
inside the generated gdblib.inc
If I add an explicit -Fl/usr/lib/gcc/sparc-linux-gnu/4.4 (or whatever)
to match libgcc.a then fp builds and runs with libgcc, although I've
not
tested this aggressively. There was an outdated reference to 4.3.2 in
fpc.cfg which had been moved around between several generations of
machines, this could have affected some earlier builds.
Is there a more appropriate way of doing this than using OPT=-Fl...,
and
is having a fixed path for libgcc in fpc.cfg still appropriate?
Yes, see above.
Noting that the makefile is able to work around the case where it can't
find libgdb, could something similar be done for libgcc? In other
words,
a stern warning that something's not right without screwing the entire
build?
I notice that on at least some systems (not limited to SPARC) the
libgcc
path in /etc/fpc.cfg is derived from the gcc version info even if this
doesn't match what's on disc, e.g. something like ...linux-gnu/4.3.2
rather than ...linux-gnu/4.3
I must confess that I don't even know how this is done...
Pierre
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC on SPARC Linux
Hi Mark,
did you try to generate the libraries needed
to compile FP IDE with GDB support by
using the script in fpcsrc/packages/gdbint/gen-gdblib-inc.sh ?
If you have a build directory of a certain GDB version (let's say 7.8.1
as an example), simply copy the script over to build-gdb-7.8.1/gdb, and run
it locally.
This script tries to determine all the libraries needed
and generates a second script called copy-libs.sh
that you should call in turn, with a simple arg, the target directory,
for example, ./copy-libs.sh ~/pas/libgdb-7.8.1
After that,
using
make -C ./packages/gdbint GDBLIBDIR=~/pas/libgdb-7.8.1
followed by
make -C ide GDBLIBDIR=~/pas/libgdb-7.8.1
should makes the things much easier.
One caveat is to avoid system installed libraries to
be installed instead of the ones inside this directory.
On systems on which I got this problem, I had to manually
remove all lines {$librarypath XXX}
where XXX resolved to /usr/lib or /lib
In the hope this will help,
Pierre Muller
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd
Envoyé : mardi 30 décembre 2014 19:13
À : fpc-devel@lists.freepascal.org
Objet : [fpc-devel] FPC on SPARC Linux
I'm having another of my periodic sessions building on minority
architectures, I've been rather off this for several months due to
various issues- mostly blown computers- at this end.
Running on Debian Sqeeze for SPARC, trunk fails if I tell it to add
debugging capability to the FP IDE. Building with
make GDB_V607=1 OPT='-V2.6.4 -O- -gl' all
in multiple places I note
fpmake.pp(49) Warning: crtbegin.o not found, this will probably cause
a linking failure
fpmake.pp(49) Warning: crtend.o not found, this will probably cause a
linking failure
and
Warning: Unable to determine the libgcc path.
although things generally continue until I get to
-8-
./fpmake compile --localunitdir=.. --globalunitdir=../packages
--os=linux --cpu=sparc -o -Ur -o -Xs -o -O2 -o -n -o
-Fu/usr/local/src/fpc/trunk/rtl/units/sparc-linux -o
-Fu/usr/local/src/fpc/trunk/packages/paszlib/units/sparc-linux -o
-Fu/usr/local/src/fpc/trunk/packages/fcl-process/units/sparc-linux -o
-Fu/usr/local/src/fpc/trunk/packages/hash/units/sparc-linux -o
-Fu/usr/local/src/fpc/trunk/packages/libtar/units/sparc-linux -o
-Fu/usr/local/src/fpc/trunk/packages/fpmkunit/units/sparc-linux -o
-V2.6.4 -o -O- -o -gl -o -vt -o -dRELEASE
--compiler=/usr/local/src/fpc/trunk/compiler/ppcsparc -bu
Start compiling package ide for target sparc-linux.
LibGDB was found, build IDE with debugger support
Warning: Unable to determine the libgcc path.
Compiling compiler/compunit.pas
Compiling /usr/local/src/fpc/trunk/compiler/ppheap.pas
Compiling /usr/local/src/fpc/trunk/compiler/cutils.pas
..
Compiling /usr/local/src/fpc/trunk/compiler/dbgstabs.pas
Compiling /usr/local/src/fpc/trunk/compiler/dbgdwarf.pas
Compiling /usr/local/src/fpc/trunk/compiler/browcol.pas
Warning: Unable to determine the libgcc path.
Compiling fp.pas
Compiling fpcatch.pas
Compiling fpcompil.pas
..
Compiling fpcodcmp.pas
Compiling fpcodtmp.pas
Compiling fptemplt.pas
Linking bin/sparc-linux/fp
The installer encountered the following error:
External command /usr/local/src/fpc/trunk/compiler/ppcsparc -Tlinux
-FEbin/sparc-linux -FUunits/sparc-linux/
-Fu/usr/local/src/fpc/trunk/rtl/units/sparc-linux/
-Fu/usr/local/src/fpc/trunk/packages/rtl-extra/units/sparc-linux/
-Fu/usr/local/src/fpc/trunk/packages/fv/units/sparc-linux/
-Fu/usr/local/src/fpc/trunk/packages/rtl-console/units/sparc-linux/
-Fu/usr/local/src/fpc/trunk/packages/chm/units/sparc-linux/
-Fu/usr/local/src/fpc/trunk/packages/fcl-xml/units/sparc-linux/
-Fu/usr/local/src/fpc/trunk/packages/fcl-base/units/sparc-linux/
-Fu/usr/local/src/fpc/trunk/packages/fcl-res/units/sparc-linux/
-Fu/usr/local/src/fpc/trunk/packages/rtl-objpas/units/sparc-linux/
-Fu/usr/local/src/fpc/trunk/packages/iconvenc/units/sparc-linux/
-Fu/usr/local/src/fpc/trunk/packages/regexpr/units/sparc-linux/
-Fu/usr/local/src/fpc/trunk/packages/gdbint/units/sparc-linux/ -Fl -Ur
-Xs -O2 -n -Fu/usr/local/src/fpc/trunk/rtl/units/sparc-linux
-Fu/usr/local/src/fpc/trunk/packages/paszlib/units/sparc-linux
-Fu/usr/local/src/fpc/trunk/packages/fcl-process/units/sparc-linux
-Fu/usr/local/src/fpc/trunk/packages/hash/units/sparc-linux
-Fu/usr/local/src/fpc/trunk/packages/libtar/units/sparc-linux
-Fu/usr/local/src/fpc/trunk/packages/fpmkunit/units/sparc-linux -V2.6.4
-O- -gl -vt -dRELEASE -Ur -dNOCATCH -dBrowserCol -dGDB -dsparc
-Fu../compiler -Fu../compiler/sparc -Fu../compiler/targets
-Fu../compiler/systems -Fi../compiler/sparc -Fi../compiler -Sg
-Fl../libgdb/linux/sparc/ -Xd -viq fp.pas failed with exit code 256.
Console output:
Target OS: Linux for SPARC
Re: [fpc-devel] ThousandSeparator
I am surprised, for me, as French, I always believed that the French thousand separator is simply a space, what else should it be? Pierre Muller from Strasbourg, France -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Mattias Gaertner Envoyé : mardi 25 novembre 2014 17:15 À : fpc-devel@lists.freepascal.org Objet : [fpc-devel] ThousandSeparator Hi, The ThousandSeparator is char and supports only 1 byte characters. For example French and Russian need more. Are there any plans to extend it? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Masm
Would it be possible to give some simple example code that could be tested? Did you try using the external linker to see if this makes a difference? -Xe option should work for that. Regards, Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Adriaan van Os Envoyé : vendredi 7 novembre 2014 11:25 À : FPC developers' list Objet : Re: [fpc-devel] Masm Marco van de Voort wrote: In our previous episode, Adriaan van Os said: It is rather unfortunate that fpc can only link OMF, not COFF on Windows (I read on some previous posts that it is the other way round, but according to http://stackoverflow.com/questions/966597/whats-the-difference- between-the-omf-and-coff-format and http://www.iecc.com/linker/linker03.html that doesn't seem to be the case). Easiest is to check the files with cygwin file, and then you'll see: C:\pp32\units\i386-win32\ptcfile ptc.o ptc.o: MS Windows COFF Intel 80386 object file FPC is COFF, and I don't see anything in the referenced links saying otherwise. The stackoverflow link is quite old. The first link seems to indicate that VSS can generate both omf and coff, so let it generate COFF ? Well, according to http://msdn.microsoft.com/en- us/library/s0ksfwcf.aspx omf Generates object module file format (OMF) type of object module. /omf implies /c; ML.exe does not support linking OMF objects. Not available in ml64.exe. So, COFF seems to be the standard for VCC. When I run mingw-objdump I get file format pe-i386 for both a VCC .obj and an FPC .o. But if the formats are the same, what is the cause of the error message Illegal COFF Magic when trying to statically link with FPC a VCC produced .obj or .lib ? Regards, Adriaan van Os ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Masm
The is no COFF magic. the first 2 bytes indicate normally a MACHINE type. The files I produced start etiher by: 0x8664 indicating a x86 coff header or 0x014c indicating a i386 coff header. Nevertheless, 0x is also listed as IMAGE_FILE_MACHINE_UNKNOWN Could it be that your coff object only contains raw data, so that it is usable on different formats? After some searching, I think that the answer to your problem is here: http://llvm.org/docs/doxygen/html/structllvm_1_1COFF_1_1BigObjHeader.html Your header looks like a BigObjHeader This means that the object is prepared to handle relocation that are not in the 4-byte range... A feature that Free Pascal indeed does not support IIRC... There is probably an option somewhere to use normal 32-bit relocation type objects in you Visual C++ configuration, unless you really need those 64-bit relocations... Pierre -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Adriaan van Os Envoyé : vendredi 7 novembre 2014 13:10 À : FPC developers' list Objet : Re: [fpc-devel] Masm But if the formats are the same, what is the cause of the error message Illegal COFF Magic when trying to statically link with FPC a VCC produced .obj or .lib ? I found the COFF docs here http://wiki.osdev.org/COFF and here http://msdn.microsoft.com/en-us/gg463119.aspx the Visual C++ produced .obj has a header that starts with 00 00 FF FF 01 00 4C 01 The FPC .o has a header that starts with 4C 01 which indicates a standard COFF header (as checked by compiler/ogcoff.pas). I can not make anything of the Visual C++ produced .obj with the Microsoft provides docs. If that isn't typically Microsoft ... How to corrupt any standard by slightly modifying it I will look further to dig up some meaningful info. Regards, Adriaan van Os ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de peter green Envoyé : mardi 21 octobre 2014 10:32 À : FPC developers' list Objet : Re: [fpc-devel] Building 2.7.1 on current Raspbian fails Paul Michell wrote: I should probablly get arround to doing a raspbian version of 2.6.4. Yes please :) Ok, i've just uploaded 2.6.4 Great, I just started to test this out, on a small raspberry. https://archive.raspbian.org/raspbian/pool/main/f/fpc/ The 2.6.4 release is able to successfully compile a 2.7.1 trunk compiler. But I tried to recompile the sources that are part of your packages, but this fails: Several files are missing in this source release: all Makefile's (this is not a real problem as they are generated using fpcmake utility (this works) but also rtl/arm/makefile.cpu and all the assembler source which have a .as suffix instead of the generated assembler file which have just a .s suffix. After adding from official 2.6.4 sources: rtl/arm/makefile.cpu and rtl/linux/arm/*.as compiler/msg/errore.msg (from /usr/lib/fpc/2.6.4/msg directory, not from official source, as there is at least one armhf specific change) using fpcmake -Tall -r in both rtl and compiler directories I was finally able to cycle successfully. But I still think that those files should also be included inside the sources... Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] test results trunk - Re: probably incorrect debug-line-info generated by fpc 2.6.2 and trunk
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Martin Envoyé : dimanche 19 janvier 2014 18:42 À : FPC developers' list Objet : [fpc-devel] test results trunk - Re: probably incorrect debug- line-info generated by fpc 2.6.2 and trunk On 19/01/2014 16:48, Martin wrote: (Existing tests are still running, but since this is for feedback, the results can be submitted later) UNMODIFIED TRUNK rev 26506: utils/digest output/i386-win32/log Total = 6874 (24:6850) Total number of compilations = 4177 (7:4170) Successfully compiled = 3146 Successfully failed = 1024 Compilation failures = 4 Compilation that did not fail while they should = 3 Total number of runs = 2697 (17:2680) Successful runs = 2680 Failed runs = 17 Number units compiled = 132 Number program that should not be run = 314 Number of skipped tests = 240 Number of skipped graph tests = 10 Number of skipped interactive tests = 30 Number of skipped known bug tests = 6 Number of skipped tests for other versions = 4 Number of skipped tests for other cpus = 53 Number of skipped tests for other targets = 137 TRUNK with peephole change rev 26518 (12 revisions later) utils/digest output/i386-win32/log Total = 6874 (19:6855) Total number of compilations = 4177 (7:4170) Successfully compiled = 3146 Successfully failed = 1024 Compilation failures = 4 Compilation that did not fail while they should = 3 Total number of runs = 2697 (12:2685) Successful runs = 2685 Failed runs = 12 Number units compiled = 132 Number program that should not be run = 314 Number of skipped tests = 240 Number of skipped graph tests = 10 Number of skipped interactive tests = 30 Number of skipped known bug tests = 6 Number of skipped tests for other versions = 4 Number of skipped tests for other cpus = 53 Number of skipped tests for other targets = 137 Since I have failing tests either way, it is hard to say anything about the change. Hi Martin, if you want to compare to test runs, you should save at least three files at the end of each run: output/$fpctarget/faillist output/$fpctarget/log and output/$fpctarget/longlog The best is to first compare the two log files with diff utility. Inside longlog, you should be able to find more information about the differences. In the hope this can help you, Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] programmers guide 2.6 issue
Hi John,
in the scanner.pas unit
procedure dir_include,
code starting around line 2324 on current trunk,
you can see that there are only a few special
names allowed.
If there is no match, the compiler looks for
an environment string with that name.
This might be the solution for your problem...
Otherwise you can try to submit a patch
adding such an option.
Pierre
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de John Lee
Envoyé : mercredi 8 janvier 2014 14:21
À : FPC developers' list
Objet : [fpc-devel] programmers guide 2.6 issue
In Pascal programmers guide v2.6 Feb 2013 it explains how to use {$I
... } to include compiler information eg version string, time string
etc so one can include eg in a writeln, but it does not mention not
the optimisation level at which program was compiled.
Is this an omission or is this info elsewhere? If so where 7 how do I
do it please?
TIA
John
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
RE: [fpc-devel] DOS GUI
I would personally be interested in those sources, It would be nice to have it publicly available. Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Anton Kavalenka Envoyé : jeudi 26 décembre 2013 13:46 À : fpc-devel@lists.freepascal.org Objet : [fpc-devel] DOS GUI Dear FPC-Developers! Our institution about 15 years ago was developed Turbo-Vision fork for VGA/SVGA graphics called GraphVision. Key features: * TV-like objects (classes) * BGI graphics with own clipping * Windows bitmap, cursors resource support * resources in external files (streamed objects) Currently the author agreed to give away the sources to community. Does anybody interested in the class library, reagards, Anton Kavalenka ___ 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] Compiling for libgdb, and using make -j on larger SPARC systems
Hi Mark, this is one of the problems with fpmake, sometimes we seems to loose the output of the calls to the assembler or the linker :( Could you try to run make inside ide directory and add -Xd option to OPT? Does this solve your problem? I get the same kind of error on i386-linux system because the compiler chooses a system library for libreadline.a instead of the one that is in GDBLIBDIR... Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd Envoyé : jeudi 8 août 2013 11:02 À : fpc-devel@lists.freepascal.org Objet : [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems I'm having one of my periodic attempts to check FPC trunk on various architectures, this was going to be a question about an exception when trying to link libgdb into 2.6.2 but I find the behaviour has changed so I mention that for information only. Also for information only, when I used -j 8 for 2.6.2 there was a message about left-over directories, I similarly don't get that with trunk (or it's intermittent) so let's leave it. So the current situation is this: when building FPC trunk on Debian Linux on SPARC, everything is fine if I use NOGDB=1. However, if I try to use libgdb (which has in the past but not particularly recently worked OK on this system) I get this make GDB_V603=1 OPT='-O- -gl' all .. ./fpmake compile --localunitdir=.. --globalunitdir=../packages --os=linux --cpu=sparc -o -Ur -o -Xs -o -O2 -o -n -o -Fu/usr/local/src/fpc/fpc-trunk/rtl/units/sparc-linux -o -Fu/usr/local/src/fpc/fpc-trunk/packages/paszlib/units/sparc-linux -o -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-process/units/sparc-linux -o -Fu/usr/local/src/fpc/fpc-trunk/packages/hash/units/sparc-linux -o -Fu/usr/local/src/fpc/fpc-trunk/packages/libtar/units/sparc-linux -o -Fu/usr/local/src/fpc/fpc-trunk/packages/fpmkunit/units/sparc-linux -o -O- -o -gl -o -vt -o -dRELEASE --compiler=/usr/local/src/fpc/fpc-trunk/compiler/ppcsparc -bu Start compiling package ide for target sparc-linux. LibGDB was found, build IDE with debugger support Warning: Unable to determine the libgcc path. Compiling compiler/compunit.pas Compiling /usr/local/src/fpc/fpc-trunk/compiler/ppheap.pas Compiling /usr/local/src/fpc/fpc-trunk/compiler/cutils.pas .. Compiling /usr/local/src/fpc/fpc-trunk/compiler/dbgdwarf.pas Compiling /usr/local/src/fpc/fpc-trunk/compiler/browcol.pas Warning: Unable to determine the libgcc path. Compiling fp.pas Compiling fpcatch.pas Compiling fpcompil.pas .. Compiling fpcodtmp.pas Compiling fptemplt.pas Linking bin/sparc-linux/fp The installer encountered the following error: External command /usr/local/src/fpc/fpc-trunk/compiler/ppcsparc -Tlinux -FEbin/sparc-linux -FUunits/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/rtl/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/fv/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/chm/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-xml/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-base/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-res/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/iconvenc/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/regexpr/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/gdbint/units/sparc-linux/ -Fl -Ur -Xs -O2 -n -Fu/usr/local/src/fpc/fpc-trunk/rtl/units/sparc-linux -Fu/usr/local/src/fpc/fpc-trunk/packages/paszlib/units/sparc-linux -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-process/units/sparc-linux -Fu/usr/local/src/fpc/fpc-trunk/packages/hash/units/sparc-linux -Fu/usr/local/src/fpc/fpc-trunk/packages/libtar/units/sparc-linux -Fu/usr/local/src/fpc/fpc-trunk/packages/fpmkunit/units/sparc-linux -O- -gl -vt -dRELEASE -Ur -dNOCATCH -dBrowserCol -dGDB -dsparc -Fu../compiler -Fu../compiler/sparc -Fu../compiler/targets -Fu../compiler/systems -Fi../compiler/sparc -Fi../compiler -Sg -Fl../libgdb/linux/sparc/ -viq fp.pas failed with exit code 1. Console output: Target OS: Linux for SPARC Compiling fp.pas fp.pas(27,2) (2004) Start reading includefile globdir.inc Compiling fpcatch.pas .. Writing Resource String Table file: fpcatch.rst Assembling fpcatch Writing Resource String Table file: fp.rst Assembling fp Linking bin/sparc-linux/fp fp.pas(554) Error: Error while linking fp.pas(554) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[2]: Leaving directory `/usr/local/src/fpc/fpc-trunk/ide' make[1]: Leaving directory `/usr/local/src/fpc/fpc-trunk' The obvious first question is: are those references to libgcc significant, and what file is being looked for? The normal binary installer hasn't been run on this system since FPC's been built
RE: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Hi, I am sorry, but Ihave no access to a sprac machine anymore. But I remember that we already had a problem like this coming from the fact that we declare somewhere an empty record and this lead to troubles... TVectorREgss from fpregs unit might still be empty for sparc. This was fixed in http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/ncgld.pas?sortby =dater1=19338r2=19337pathrev=19338 in May 2011... But I was hoping it was fixed in 2.6.2 ... Could you try to recompile trunk compiler and check that that one does not crash. Pierre PS :Test bug is tiny: Try to compile the following, with either 2.6.2 or current trunk binary, type emptyrec = record end; var x, y : emptyrec; begin x:=y; end. -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd Envoyé : jeudi 8 août 2013 22:22 À : fpc-devel@lists.freepascal.org Objet : Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems Sven Barth wrote: If I revert to 2.6.2 and run ppcsparc under gdb, I get this as a backtrace: Program received signal SIGFPE, Arithmetic exception. 0x001e61c0 in TCGASSIGNMENTNODE__PASS_GENERATE_CODE (this=0xf5d6abe0) at ncgld.pas:785 785 if (right.location.reference.offset mod alignmentrequirement0) or (gdb) bt #0 0x001e61c0 in TCGASSIGNMENTNODE__PASS_GENERATE_CODE (this=0xf5d6abe0) at ncgld.pas:785 Also (if I'm doing this right) (gdb) print alignmentrequirement $1 = 0 Any thoughts appreciated. This is strange. If you take a look at the code there are at least two checks that should ensure that alignmentrequirement is not 0... Could you maybe step into Min and Max to check whether they produce sane results? (you'll likely need to recompile the RTL with debug information; I'd suggest you to use 2.7.1 for debugging) If you can't recompile the RTL with debug information you could try to break up the assignment statement for alignmentrequirement into single steps and print the values so that we can have a complete picture. I'll take a look at that in the morning, probably by printing temporary values etc. since I'm not very confident trying to single-step somebody else's complex code. Allowing that this is apparently a compiler rather than an fp/libgdb issue, is there test code for this case anywhere? Misbehaving min()/max() rings a horrible bell, but I can't remember the context. I'm glad to say that at least removing the -O- has no beneficial effect :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ 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] How can I distribute code in two different memory areas? (.section)
Maybe the section keyword that was introduced for embedded systems for variables (see compiler/pdecvar.pas unit, look for _SECTION and try_consume_sectiondirective) should be extended to function/procedure header parsing. procedure reset; assembler; nostackframe; public name'_reset'; section '.reset,ax,@progbits'; would then do all you want. Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Jeppe Græsdal Johansen Envoyé : lundi 17 juin 2013 08:54 À : FPC developers' list Objet : Re: [fpc-devel] How can I distribute code in two different memory areas? (.section) Den 17-06-2013 08:20, Sergei Gorelkin skrev: 16.06.2013 23:39, Michael Ring пишет: I had some time this weekend (while beeing grilled by the sun on my balcony) to work on another thing that did not work correct and that I did not understand (Now I do, I least I hope ;-) As said before in this thread, I wanted to distribute Code in two different memory areas because this needs to be done so that pic32 startup code works correctly. But when I linked my binary the elf-file had always a startup address somewhere in the wrong memory area. This is what I tried: procedure reset; assembler; nostackframe; public name'_reset'; asm .section .reset,\ax\,@progbits la $k0, _startup jr $k0 //Jump to startup code nop .text end; In general, the custom section support in compiler needs a lot of improvement... Try the following, maybe it could work: procedure anyname; assembler; nostackframe; asm .section .reset,\ax\,@progbits .globl _reset _reset: // -- correct name here la $k0, _startup jr $k0 nop .text end; Regards, Sergei I agree that it needs some work. Having a way to specify the section with a procedure directive would largely be preferable I think. Such a directive could also be interesting for variables and typed constants Also, I think .section .reset should work just fine in most cases ___ 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] FPC SoftFPU implementation
Hi Max, thank you for your contribution... While testing it, I managed to fix another independent longstanding bug in softfpu.pp (rev 24864) which fixes a int64-single conversion error. I must confess that it's been a long time since I last looked at the software fpu support code... thus I cannot make any prediction on the integration of your code in the compiler. Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Max Nazhalov Envoyé : dimanche 9 juin 2013 18:22 À : fpc-devel-requ...@lists.freepascal.org Objet : [fpc-devel] FPC SoftFPU implementation Some time ago I had to do a few hw-independent experiments with floating point, and faced with ./fpc/rtl/inc/softfpu.pp unit. Its' current state is far from finishing of porting stage, so I had to make some changes to get it up and compile with originally foreseen functionality. This is roughly a draft patch -- just conversion of unfinished porting of C- syntax; it omits some details like 'public'/'alias:'/'compilerproc' placing (since I have no idea about these modifiers). In addition, fixed several lost 'exit's, 'var'-modifier for 'shortShift128Left', some range-warnings.. Ambiguities were checked against John R. Hauser's SoftFloat Release 2b. Missing parts were also ported from there. But almost no serious testing was performed yet by now due to lack of time. Could this patch be reviewed and accepted/adapted/rejected? --- WBR, Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Testsuite database
Thanks to your email, Yuri Sidorov (member of the core team) took the time to look at the problems of the testsuite.cgi program and fixed several issues he found. Please test and report if you still find problems... Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Nikolai Zhubr Envoyé : samedi 2 février 2013 09:43 À : FPC developers' list Objet : [fpc-devel] Testsuite database Hello devels, Apparently the test suite database needs some love? E.g. see this URL (generated automatically by webpage, not by me): http://www.freepascal.org/testsuite/cgi- bin/testsuite.cgi?os=1cpu=8version=44date=submitter=machine=comment=c ond=Category=1action=View+history The application encountered the following error: * Error: : Error executing query: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') AND (TU_VERSION_FK=44) AND (TU_OS_FK=1) ORDER BY TU_ID DESC LIMIT 50' at line 1 * Stack trace: $0049DDD4 line 2147 of fcl-db/src/base/db.pas Nikolai ___ 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] FPC for MIPS
I updated ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/mipsel-linux/ and ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/mips-linux/ directories with new snapshots dated from 2013-01-15. Tell us if these work better, Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de SkyDiablo Envoyé : mardi 15 janvier 2013 02:04 À : fpc-devel@lists.freepascal.org Objet : [fpc-devel] FPC for MIPS hi ho, i'm back again ;) i have try this: http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg27336.html but my Ubuntu Desktop 12.04 LTS can't run the ppcmips binary? $ chmod +x ppcmips $ ./ppcmips -iV bash: ./ppcmips: Kann die Datei nicht ausführen. (Can't run this file) so, if there are any other solution to compile fpc code for MIPS/linux? greez thx, sky... ___ 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] mips-linux and mipsel-linux snapshots available
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de microc...@zoho.com Envoyé : mercredi 26 décembre 2012 16:13 À : fpc-devel@lists.freepascal.org Objet : Re: [fpc-devel] mips-linux and mipsel-linux snapshots available Will this work on other OS running on MIPS? How much work would it be to get it going on OpenBSD for example? It shouldn't be much work... just look at the content of openbsd/CPU/ directories, you will see what needs to be implemented specifically... Starting with the linux equivalent code should work for most include files, the startup prt0.as file might be a little bit more problematic... Pierre On Wed, Dec 26, 2012 at 03:07:16PM +, Mark Morgan Lloyd wrote: Mark Morgan Lloyd wrote: Sergei Gorelkin wrote: This was caused by insufficient alignment of Double-typed temp variables, fixed in r23146. Moreover, it appeared that function UnixToWinAge wasn't doing anything useful since year 2005, so it was removed in r23145, making FindFirst/FindNext routines somewhat faster (and able to run without FPU). Now I am able to run the big-endian MIPS compiler on QEMU. Hoping you'll be able to reproduce it, too. I'll see what I can do, but I've not got any real hardware running here which is causing me problems (Qemu performance isn't brilliant). Basic operation OK. There's a slight problem in that the build produces a directory /usr/local/lib/fpc/2.7.1/units/mips-linux while ppcmips running with the standard fpc.cfg expects .../mipseb-linux Full build works with a standard set of parameters. Albeit slowly. Only peculiarity was that I had to copy the fpc binary manually before I could run sudo make install I'll try to run the test suite for both mipsel and mips(eb), but a higher priority has to be getting one of my SGI machines running. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Sven Barth Envoyé : lundi 10 décembre 2012 16:37 À : fpc-devel@lists.freepascal.org Objet : Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K) Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd: I'm currently cross-compiling the MacOS RTL for PPC on a PC. I've fixed some trivial issues that had crept in since this was last maintained, some of which affect other targets, but am stuck at the errors below. /usr/local/src/fpc/fpc-trunk/compiler/ppcXppc -Ur -Tmacos -Ppowerpc -XPpowerpc-macos- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../powerpc -FE. -FU/usr/local/src/fpc/fpc-trunk/rtl/units/powerpc-macos -dpowerpc -dRELEASE -Us -Sg system.pp text.inc(1789,14) Warning: Implicit string type conversion from AnsiString to UnicodeString text.inc(2013,44) Warning: Implicit string type conversion with potential data loss from UnicodeString to AnsiString system.pp(481,2) Warning: User defined: To be implemented - using GetProcessInformation??? system.pp(571) Fatal: Internal error 2003090901 Fatal: Compilation aborted make[2]: *** [system.ppu] Error 1 make[2]: Leaving directory `/usr/local/src/fpc/fpc-trunk/rtl/macos' Allowing that system.pp ends at line 570, I presume that something after line 481 is confusing the compiler. Any suggestions would be appreciated. Not necessarily. It seems to be related to something external. You could try the following by adjusting the compiler source: before the internalerror (in compiler/powerpc/agppcmpw.pas) add a writeln(tasmsymbol(p).typ) and maybe also a AsmFlush so that the assembler file up to the error will be written so you can see in which function the problem exists. You could also debug the compiler (copy the command line from the Makefile's output) when compiling the system unit and place a breakpoint on the internalerror and then investigate the p variable. I was wondering how many of you know/use the gppc386 trick? The source code is located in compiler/utils do a make -C utils gppc386 this should compile a binary called ./utils/gppc386 You should copy/rename it to, for instance gppc1 cp ./utils/gppc386 ./gppc1 After this, you simply call make, as for instance here: make -C ../rtl clean all FPC=/full/path/to/complier/gppc1 gppc1 will start gdbpas (you can add a symbolic link to normal gdb) load ppc1 (same name with initial letter 'g' removed) and run ppc1 with the parameters given by make... It should stop if something goes wrong and not otherwise. This is how I usually debug the compiler... You need to be careful about a few things, like: if you try to use this for a make cycle you need to change the starting compiler name to something that will not be deleted at start of cycle, and then of course you also need to rename gppc1 accordingly. In the hope that it can be useful! Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] mips-linux and mipsel-linux snapshots available
Hi Mark,
do you use my patch for mips to
handle stack?
Without it, the backtrace doesn't work...
The bad thing is that I submitted it to gdb-patches,
but it was refused, I was told that $fp should be equal to
$sp according to ABI...
If you use a stock GDB, try to unpack a recent
GDB source tree, apply the one line patch below,
and recompile GDB.
Can you tell us if the backtrace looks better after this?
Pierre Muller
2012-06-11 Pierre Muller mul...@ics.u-strasbg.fr
* mips-tdep.c (mpis32_scan_prologue): Fix value of frame_offset
for ADDIU $s8,$sp,FrameSize.
Index: src/gdb/mips-tdep.c
===
RCS file: /cvs/src/src/gdb/mips-tdep.c,v
retrieving revision 1.556
diff -u -p -r1.556 mips-tdep.c
--- src/gdb/mips-tdep.c 6 Jun 2012 21:34:12 - 1.556
+++ src/gdb/mips-tdep.c 10 Jun 2012 23:43:44 -
@@ -3226,6 +3226,7 @@ restart:
(this_frame, gdbarch_num_regs (gdbarch) + 30);
alloca_adjust = (unsigned) (frame_addr - (sp + low_word));
+ frame_offset -= low_word;
if (alloca_adjust 0)
{
/* FP SP + frame_size. This may be because of
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd
Envoyé : samedi 24 novembre 2012 13:45
À : fpc-devel@lists.freepascal.org
Objet : Re: [fpc-devel] mips-linux and mipsel-linux snapshots available
Mark Morgan Lloyd wrote:
The previous version that I compiled is around r22655 and builds OK on
mipsel implemented by Qemu. I'm trying it for mips (big-endian)... I
might be some time.
Definite problem on a big-endian target: fpc -i is OK but fpc -h
fails with
Reading symbols from /usr/local/bin/ppcmips...done.
(gdb) set arg -h
(gdb) run
Starting program: /usr/local/bin/ppcmips -h
Program received signal SIGBUS, Bus error.
0x0043eb88 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT ()
(gdb) bt
#0 0x0043eb88 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT ()
#1 0x0043fa6c in
SYSUTILS_$$_FINDGETFILEINFO$ANSISTRING$TSEARCHREC$$BOOLEAN ()
#2 0x0043fdc4 in SYSUTILS_$$_FINDNEXT$TSEARCHREC$$LONGINT ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
Same failure running fpc -l or trying to compile a trivial program.
Ditto fpc -l- test.pas, or running with no options/parameters other
than what are in the standard fpc.cfg.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or
colleagues]
___
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] Solaris and binutils 2.22 break fpc linking and workaround
On the VM I have access to:
pierre@fpcOpenSolaris:~$ gld --help | grep -i emul
-m EMULATIONSet emulation
-V Print version and emulation information
gld: supported emulations: elf_i386_ldso elf_i386 elf_x86_64
gld: emulation specific options:
pierre@fpcOpenSolaris:~$
pierre@fpcOpenSolaris:~$ gld --version
GNU ld (GNU Binutils) 2.19
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later
version.
This program has absolutely no warranty.
This is pretty bad...
2.19 is not that old, and it doesn't even know about
elf_x86_64_sol2 emulation...
I tested it by manually changing elf_x86_64 into elf_x86_64_sol2
in a ppas.sh script generated with -s option...
Until now, we always managed to avoid
parsing the output of a 'ld --version'
to adapt the command line, but here I have no idea
how we could do it without something like that :(
Pierre Muller
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Helmut Hartl
Envoyé : mardi 20 novembre 2012 14:52
À : FPC developers' list
Objet : [fpc-devel] Solaris and binutils 2.22 break fpc linking and
workaround
Hi,
While building under SmartOS in a buildzone
(IllumOS, former OpenSolaris) i have the problem that with
binutils 2.22 the fpc generated linker script line in ppas.sh
/opt/local/bin/gld -melf_x86_64-s -L. -o my_program link.res
is not working anymore. Because the only targets the new binutils 2.22
support on solaris are elf_x86_64_sol2 and elf_i386_sol2.
Manually linking with: (after compiling with -Cn)
$/opt/local/bin/gld -melf_x86_64_sol2 -s -L. -o fpmake_packages link.res
is working!
Others have similar problems on gentoo:
http://archives.gentoo.org/gentoo-
alt/msg_a4641a1c17ce5f66a05c6440dd5cfc87.xml
The problem is that on SmartOS the build machines and packages default
to gcc47 with binutils 2.22.
I fixed it for me by compiling the compiler only on Openindiana 151a7
(older binutils) with the following applied trivial patch, and copying
the resulting compiler(s) (32/64) bit to the
target system. A full build for a 32 bit and a 64 bit fpc went well.
--- ./systems/t_sunos.pas.bak 2012-08-27 12:24:46.0 +0200
+++ ./systems/t_sunos.pas 2012-11-04 05:59:23.399713956 +0100
@@ -143,12 +143,12 @@
}
{$ifdef x86_64}
const
- gld = 'gld -m elf_x86_64 ';
+ gld = 'gld -m elf_x86_64_sol2 ';
solaris_ld = '/usr/bin/ld -64 ';
{$endif}
{$ifdef i386}
const
- gld = 'gld ';
+ gld = 'gld -m elf_i386_sol2 ';
solaris_ld = '/usr/bin/ld ';
{$endif }
{$ifdef sparc}
What are the options to fix this properly ?
I did not manage to get it working with the existing comand line
options.I think it is needed to influence the -m option which fpc
generates in t_sunos, depending on an switch stating the usage of
binutils greater than
a certain version.
helmut
___
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] mips-linux and mipsel-linux snapshots available
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd Envoyé : mardi 20 novembre 2012 18:38 À : fpc-devel@lists.freepascal.org Objet : Re: [fpc-devel] mips-linux and mipsel-linux snapshots available Pierre Muller wrote: Due to numerous question about mips/mipsel linux, I decided to try to generate snapshot for those systems. It finally worked (with OPT=-O- option added) You can test them at: ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/mipsel-linux/ or ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/mips-linux/ Please give feedback, I'm just about moving again here, but with a decided limp: the system that blew was 2.8GHz and all my guest OSes are now plugged into a 1GHz box. I still find being able to use a significant number of different guests in sleds/caddies useful... Unfortunately I've still not got any real MIPS hardware running here, so I'm still stuck on Qemu. The good news is that I can still run/build trunk for mipsel on Debian Squeeze on Qemu without unanticipated issues (i.e. nobody reading this should assume that Lazarus will work yet). The not-so-good news is that I built from trunk earlier but after having bus errors in Qemu's implementation of big-endian MIPS I'm now looking at the file above. Unfortunately I still get bus errors and I think the binaries have been stripped. This is very strange: I just installed the snapshot onto the big-endian mips machine that I use to generate the snapshot. This machine is the one that does generate daily testsuite results for mips-linux. I just tested a compiler cycle (with DEBUG=1) starting from this snapshot binary, and it seems to be able to generate a vanilla trunk ppcmips: ppcmips -iDW 2012/11/21 2.7.1-r1:23032 Is this a Qemu problem? Pierre If I revert to a binary that I cross-built from trunk earlier, I get this: 217 1markMLl@pye-dev-07c:~$ gdb /usr/local/lib/fpc/2.7.1/ppcmips GNU gdb (GDB) 7.0.1-debian .. Reading symbols from /usr/local/lib/fpc/2.7.1/ppcmips...done. (gdb) run Starting program: /usr/local/lib/fpc/2.7.1/ppcmips Program received signal SIGBUS, Bus error. 0x0043ba68 in SYSUTILS_$$_DATETIMETOFILEDATE$TDATETIME$$LONGINT () (gdb) bt #0 0x0043ba68 in SYSUTILS_$$_DATETIMETOFILEDATE$TDATETIME$$LONGINT () #1 0x0043edb4 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT () #2 0x0043fc88 in SYSUTILS_$$_FINDGETFILEINFO$ANSISTRING$TSEARCHREC$$BOOLEAN () #3 0x0043ffe0 in SYSUTILS_$$_FINDNEXT$TSEARCHREC$$LONGINT () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ 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] mips-linux and mipsel-linux snapshots available
This is just a compressed installation: if you expand everything into directory /your/base/dir then adding /your/base/dir/bin to PATH environment variable should allow you to use this installation. However, there are indeed at least two known problems: 1) The missing symbolic link between bin/ppcCPU to ../lib/fpc/$FPCVERSION/ppcCPU where CPU is etiher mips or mpisel in our case. I don't know if this is just a limitation of tar or something that could easily be added... 2) A basic fpc.cfg file that gets read by the ppcCPU binary to find the installed ppu and object files. I have a .fpc.cfg file in my HOME directory which contains -Fu/home/pierre/pas/fpc-$fpcversion/lib/fpc/$fpcversion/units/$fpctarget/* This is enough to find all installed ppu and object files as long as you install all your different Free Pascal versions into $HOME/fpc-$fpcversion $fpcversion is simply the output of a 'ppcCPU -iV' call. If you want to know where you could put a configuration file (if you prefer to have a different for each version for example) a good way is to use 'ppcCPU -va' which will output a lot of information, but look for lines containing Configfile After those simple operations, you should be able to recompile the whole trunk SVN checkout! Hope this helps, Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de SkyDiablo Envoyé : lundi 5 novembre 2012 18:54 À : fpc-devel@lists.freepascal.org Objet : Re: [fpc-devel] mips-linux and mipsel-linux snapshots available oh, very nice! big thx! i would testing this, but please can you add a little (or more detail) description how to use this snapshot? i see some intrestet files but i cant to bring together... greez thx, sky... Am 05.11.2012 15:49, schrieb Pierre Muller: Due to numerous question about mips/mipsel linux, I decided to try to generate snapshot for those systems. It finally worked (with OPT=-O- option added) You can test them at: ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/mipsel-linux/ or ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/mips-linux/ Please give feedback, Pierre Muller ___ 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] FPC related fairy tale
Are you resurrecting m68k port? Just a guess, of course... Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Sven Barth Envoyé : jeudi 18 octobre 2012 13:13 À : FPC developers' list Objet : [fpc-devel] FPC related fairy tale Hello together! Over the past weeks I've spent some time on getting something to work in FPC and now I'm about to commit this either this evening or at least this weekend (depending on the time I have). Now I thought that I'd make a little test to see how good you know FPC and thus I've written a little fairy tale which is more or less loosely based on the work I've done. One important note beforehand though: it may sound as if I'm critizing some actions of the other FPC core devs in this tale, but this is definitely NOT my intention, so take the story not too seriously, please ;) [and also keep in mind, please, that I'm not a native English speaker...] Here it is: Once upon a time there was a small kingdom ruled by a kind king. The king had two daughters and more children were planned to come. But the king had already problems to find approbiate rooms for his second child. So he ordered his mages to reconstruct the castle in a way that the ever-growing family can easily be accommodated. The mages immediately began with their work and reshaped the castle with their spells. But as the work on the castle neared its completion a terrible accident happend to the second princess when she played between the working mages. She was no longer able to walk or even sit upright without support. The mages tried their best to heal her, but in the end they needed to finish the castle so that the royal family could have their home back before the winter strikes. But even after the castle had been finished they didn't have enough time for the disabled princess as the family had already grown during the mages' work and required their full attention. And so the days and months passed by in which the second daughter of the king was confined to her room and could not join in the family's activities. Then one day a young mage came along and joined the mages of the castle. He helped them with maintaining the magically enhanced castle, but while searching for places to fix and further extend he stumpled upon the room of the isolated princess. He felt sorry for the girl's state and although he did not know much about healing magic he decided to improve his knowledge and help the her. So he spent the evenings after his normal work at the castle in the library and looked through the books about healing magic. Sometimes he then went to the princess' chamber and applied his newly learned knowledge. After some weeks his work finally paid off and the girl was able to feel and move her legs again. And after some more time she was finally able to walk again. Although she needed to move slowly and with the help of crutches, she was finally able to take part in the life at the castle again. The young mage continued to heal her and they all lived happily ever after. So... now I'm curious what you think I have worked on and I'm also curious whether someone can fully decipher that little story. :) Regards, Sven ___ 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] -i and -Cp
PS: Trunk for sparc is currently broken (I added some checks related to nostackframe modifier, ad some CPU do not conform to the idea that the stacksize should be zero in that case...) Thanks, noted. Yell when you want me to test something. This should now be fixed... If you have time to test it, it would be great. Pierre -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ 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] -i and -Cp
You are right: muller@deluxe:~/pas/test$ ppcsparc hello muller@deluxe:~/pas/test$ ppcsparc hello -CpXX Error: Illegal parameter: -CpXX muller@deluxe:~/pas/test$ ppcsparc hello -Cpsparc v7 muller@deluxe:~/pas/test$ ppcsparc hello -Cpsparc v8 muller@deluxe:~/pas/test$ ppcsparc hello -Cpsparc v9 muller@deluxe:~/pas/test$ ppcsparc hello -Cpsparc v19 Error: Illegal parameter: -Cpsparc v19 But I didn't find any use of cputype current_settings field in compiler/sparc directory sources, so the generated result should not change... Pierre PS: Trunk for sparc is currently broken (I added some checks related to nostackframe modifier, ad some CPU do not conform to the idea that the stacksize should be zero in that case...) -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd Envoyé : mercredi 17 octobre 2012 15:59 À : fpc-devel@lists.freepascal.org Objet : [fpc-devel] -i and -Cp When -i returns lines with spaces, e.g. Supported CPU instruction sets: SPARC V7 SPARC V8 SPARC V9 what is the correct form to use for the -Cp option? For the toplevel makefile I've already got make GDB_V607=1 OPT='-O- -gl -vt' all and I presume that what I need is something like make GDB_V607=1 OPT='-O- -gl -vt -CpSPARC V7' all but I'd appreciate confirmation: I'm just about to run a slow compilation to see whether FPC will work on a very small Solaris 7 (SunOS 5.7) system and I'd rather not have to wait a day to discover I've got an option wrong. Just pushing the limit out of curiosity... -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ 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] Testing MIPS: newbie questions
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd Envoyé : lundi 15 octobre 2012 15:39 À : fpc-devel@lists.freepascal.org Objet : [fpc-devel] Testing MIPS: newbie questions In trunk, is there any particular reason why tbs/tb0072.pp refers to CPUSMIPS rather than CPUMIPS? This is probably an error on my side :( Fixed in rev 22655, thanks for noticing! I notice that in system.pp and in linux/ptypes.inc etc., conditionals refer to CPUMIPS while in other places they refer to CPUMIPS32 and/or CPUMIPSEL32. Is this correct? CPUMIPS is defined for both mips big endian and little endian targets, CPUMIPSEL is defined only for little endian mips target, CPUMIPSEB is defined only for big endian mips target. CPUMIPS32 is here to specify that it is a 32bit system, and to possibly separate out future 64bit specific code. (Nothing ready on this side yet...) I am not sure all of the uses in rtl are really correct (in the sense that they apply to the right sub-category of target...) Please do not hesitate to report all suspicious instances. There are still plenty of bug in the code generator, help would be most appreciated! Pierre Muller -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ 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] Testing MIPS: newbie questions
I have a small batch that I use for cross-compilation from i386-win32 to mips(el)-linux. E:\pas\trunk\fpcsrc\compilertype mipsel-cycle.bat set CUR_FPC_VER=2.7.1 if %1 == cont goto cont make cycle OPT=-gl -al -n -O- -Ur -vw OS_TARGET=linux CPU_TARGET=mipsel ALLOW_WARNINGS=1 if errorlevel 1 goto error pscp -load gccmips .\ppcmipsel gcc42.fsffrance.org:bin copy ppcrossmipsel.exe \pas\fpc-%CUR_FPC_VER%\bin\i386-win32 make -C ../rtl install FPC=ppcrossmipsel.exe PREFIX=/pas/fpc-%CUR_FPC_VER% cd utils del gppc386 make FPC=/pas/trunk/fpcsrc/compiler/ppcrossmipsel OPT=-gl clean all gppc386 pscp -load gccmips .\gppc386 gcc42.fsffrance.org:bin/gppcmipsel cd .. goto end :error echo An error occurred :end This uploads a native mipsel compiler that is usable (at least as long as you don't work with too recent GNU as/ld, muller@gcc42:~/pas/test$ ppcmipsel hello.pp Assembler messages: Error: -march=mips2 is not compatible with the selected ABI hello.pp(14,18) Error: Error while assembling exitcode 1 hello.pp(14,18) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted muller@gcc42:~/pas/test$ as --version GNU assembler (GNU Binutils) 2.23.51.20121004 So most of the problems described in http://wiki.lazarus.freepascal.org/Native_MIPS_Systems should not be present anymore... Pierre -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd Envoyé : lundi 15 octobre 2012 17:51 À : fpc-devel@lists.freepascal.org Objet : Re: [fpc-devel] Testing MIPS: newbie questions Pierre Free Pascal wrote: -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd Envoyé : lundi 15 octobre 2012 15:39 À : fpc-devel@lists.freepascal.org Objet : [fpc-devel] Testing MIPS: newbie questions In trunk, is there any particular reason why tbs/tb0072.pp refers to CPUSMIPS rather than CPUMIPS? This is probably an error on my side :( Fixed in rev 22655, thanks for noticing! I notice that in system.pp and in linux/ptypes.inc etc., conditionals refer to CPUMIPS while in other places they refer to CPUMIPS32 and/or CPUMIPSEL32. Is this correct? CPUMIPS is defined for both mips big endian and little endian targets, CPUMIPSEL is defined only for little endian mips target, CPUMIPSEB is defined only for big endian mips target. CPUMIPS32 is here to specify that it is a 32bit system, and to possibly separate out future 64bit specific code. (Nothing ready on this side yet...) I am not sure all of the uses in rtl are really correct (in the sense that they apply to the right sub-category of target...) Please do not hesitate to report all suspicious instances. There are still plenty of bug in the code generator, help would be most appreciated! Thanks for that. What I actually started with this morning was revisiting http://wiki.lazarus.freepascal.org/Native_MIPS_Systems and trying to crossbuild the RTL. I'm afraid that I didn't get very far which led me to look at the defines... should this work yet, or is a full test run a prerequisite? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ 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] Is this a compiler bug ?
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de ik Envoyé : jeudi 27 septembre 2012 15:05 À : FPC developers' list Objet : [fpc-devel] Is this a compiler bug ? Hello, While trying to compile FPC r22471: make CROSSOPT=-O2 -g -FD/usr/share/java/ CPU_TARGET=jvm OS_TARGET=android INSTALL_PREFIX=/usr/ FPC=/usr/bin/ppcx64 all zipinstall I get the following message: /home/ik/projects/foss/fpc/fpc/compiler/ppc -Ur -Xs -O2 -n -Fujvm -Fusystems -Fu/home/ik/projects/foss/fpc/fpc/rtl/units/x86_64-linux -Fijvm -FE. -FUjvm/units/x86_64-linux -Cg -dRELEASE -djvm -dGDB -dBROWSERLOG -Fujvm -dNOOPT -Sew pp.pas hlcgcpu.pas(2392,28) Warning: Constructing a class thlcgjvm with abstract method g_overflowcheck hlcgcpu.pas(2392,28) Warning: Constructing a class thlcgjvm with abstract method g_overflowCheck_loc hlcgcpu.pas(2397) Fatal: There were 2 errors compiling module, stopping The Compiler display two warnings and then it report them as 2 errors. I'm using Free Pascal Compiler version 2.6.0 [2012/05/17] for x86_64 that arrives with Arch-Linux Is this a bug of the compiler (reporting errors as warnings), a bug in the code itself, or something else ? It is a feature of both the compiler capabilities itself and of the fact that we consider that correct code should not generate warnings. -Sew is the option that transforms any warning into an error it is a feature of the compiler that is used by default when cycling (In the sense do a 'make cycle') the compiler. For java target it is known that there are warnings left, but you can still use the Makefiles by adding ALLOW_WARNINGS=1 to the 'make cycle' command line. Pierre Muller ... who's responsible for adding -Sew to the default compiler cycling! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Error building branch targetandroid
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Felipe Monteiro de Carvalho Envoyé : jeudi 13 septembre 2012 16:35 À : FPC developers' list Objet : Re: [fpc-devel] Error building branch targetandroid Ok, so that error was fixed, but now it just fails elsewhere further down =( In Windows I try to build targetandroid with this batch script: SET PATH=;C:\Programas\lazarus31_fpc260\fpc\2.6.0\bin\i386- win32;C:\Programas\android-ndk-r8\toolchains\arm-linux-androideabi- 4.4.3\prebuilt\windows\bin make crossinstall CPU_TARGET=arm OS_TARGET=android OPT=-dFPC_ARMEL CROSSOPT=-CpARMv6 -CfSoft CROSSBINDIR=C:\Programas\android-ndk-r8\toolchains\arm-linux-androideabi- 4.4.3\prebuilt\windows\bin\ BINUTILSPREFIX=arm-linux-androideabi- INSTALL_PREFIX=output pause Try using forward slashes instead CROSSBINDIRT=C:/Programas/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/ I suspect that some shell sees ...bin\ -o as only one parameter because it believes there is an escaped space '\ ' that make ' -o' still part of the previous parameter for fpmake. Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] MIPS target: progress report?
I worked on it quite some time before leaving for holidays, and tried to get it working again with current svn trunk... I haven't yet checked if current svn trunk is usable for mipsel target. Currently, using revision 21906 you should be able to do a complete 'make all install' at fpcsrc level with one restriction: 'make all' normally uses -O2 option by default, but this optimization option is still broken for mipsel cpu. adding FPCCPUOPT=-O1 should enable a successful completion of the 'make all'. As Sven mentioned , it still has something like 145 failures for a testsuite, so there are still lots of open issues. Commit rev 22196 fixes one problem related to fpu register saving. Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd Envoyé : mercredi 22 août 2012 12:16 À : fpc-devel@lists.freepascal.org Objet : [fpc-devel] MIPS target: progress report? Does anybody have an update on where the MIPS port has got to after the flurry of activity in June? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ 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
[fpc-devel] Progress for mips debugging
the generated mips executable were really difficult to
debug because the locals and parameters were not correctly
displayed by GDB.
It turned out that it was not only our fault,
we use a different layout than GCC normally does.
GCC decreases $sp register a function entry,
saves registers (inclusing $s8 regsiter)
and then puts $sp into $s8.
We currently do this:
decrease $sp
save the registers
set $s8 to value of $sp before the initial decrease.
GDB was supposed to also support this, but there
is an error in the handling:
those interested can take a look at:
http://sourceware.org/ml/gdb-patches/2012-06/msg00395.html
To be able to correctly display
locals/parameters of procedures/functions
you will need to patch a recent GDB source with the following one line
patch.
This patch should apply cleanly to current GDB CVS Head,
but is probably usable for other sources too.
Please report if this does not allow you to display
correctly local vars and parameters if using SVN
after revision 21588.
Pierre
Index: src/gdb/mips-tdep.c
===
RCS file: /cvs/src/src/gdb/mips-tdep.c,v
retrieving revision 1.556
diff -u -p -r1.556 mips-tdep.c
--- src/gdb/mips-tdep.c 6 Jun 2012 21:34:12 - 1.556
+++ src/gdb/mips-tdep.c 10 Jun 2012 23:43:44 -
@@ -3226,6 +3226,7 @@ restart:
(this_frame, gdbarch_num_regs (gdbarch) + 30);
alloca_adjust = (unsigned) (frame_addr - (sp + low_word));
+ frame_offset -= low_word;
if (alloca_adjust 0)
{
/* FP SP + frame_size. This may be because of
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] progress of freepascal for mips
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Fuxin Zhang Envoyé : vendredi 8 juin 2012 02:07 À : Jonas Maebe Cc : FPC developers' list Objet : Re: [fpc-devel] progress of freepascal for mips Fuxin Zhang wrote on Sat, 02 Jun 2012: With the attached patch (against revision 21440), most of the tests can now pass, for example, the test directory has only the following failinglist: When committing/submitting patches in the future, please split them up into smaller independent patches. That makes it much easier to review them. OK, I will take some time to clean up things and split them into independent trunks. Florian has open a branch for me, I will try to do it in the branch with clear log. These days I am fight with the parameter passing. It is almost mips O32 compatible, only five of the test/cg/ still fail. foxsen@ubuntu-zfx:/software/data/fpc/tests$ cat output/mipsel-linux/faillist.testlog test/cg/tdivz2 test/cg/tprintf test/cg/tprintf2 test/cg/treadwrt test/cg/tumin Hi Fuxin, I committed to trunk your changes together with a few changes to cpupara that allow me to generate a compiler (not yet operational, but its going forward). Florian asked be to commit it. It is not closely following a specific abi, but for parameters it works like this: Up to 6 parameters are passed in registers $r4 to $r9, others on the stack starting at offset 24 (=6*4). (I had to adapt the 6 parameter very of linux/mips/syscall.inc in order to get fpmmap to work). The startup code of the function pushes these registers back to the 6 4 byte slots from 0 to 24. It sets $fp register ($r29 or $s8) to the previous value of the $sp stack register. This way, function parameters can be accessed by offsets to $fp register, while locals or parameters of function that will be called inside the function are accessed via $sp register. The biggest problem now is that GDB is not pleased this, because it find that there is a frame register ($r29) so that it computes falsely the address of all locals and arguments... I think that we should add a list of all mips known ABI and create a record that lists their specificities, This way, we should be able to convert some constants into ABI specific values. Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] NetBSD and OpenBSD...
Hello Liyuan, That really nice to hear, I do commit some minor changes to those targets, but I only have virtual machines on which these systems run remotely. What would be nice is to have people testing those targets more deeply. In particular, it would be nice to get those two targets as close as possible to their FreeBSD counterparts. After, it mainly depends on your interests, if you want to debug OS specific problems, a good sdtart it to look at the results of nightly testsuite runs. I run nightly testsuites for i386-netbsd target and i386-openbsd: See, for netbsd: http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?os=6cpu=1version =0date= and for openbsd: http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?os=7cpu=1version =0date= And for reference, the corresponding freebsd results: The differences are probably mainly due to: 1) Errors in the OS specific part of the RTL, (like for instance wrong values of some constants in RTL sources) 2) errors in the compiler specific to the given OS (differences in ABI for instance). 3) Packages that have not been tested for the OS. The testsuite are run several times with different Comment fields in the web page, those correspond to different TEST_OPT variable passed to gmake when running the testsuite which alter slightly the results. Ideally we should have no difference in testsuite output, no matter what the CPU or the OS is. Some tests are just failing for all CPU-OS pairs as they correspond to things that are still not implemented in the compiler (one that comes to my mind is support for sets of more than 256 elements, which is not supported and the reason of the failure test/tset6.pp). Another point of interest might be to know if the compiler works on older release versions of the OS, the tests are run of fairly recently installed VM's and I have no clue about a minimal OS version... So you see that the ideas for help are numerous and you can just try out and report your findings. All the above is about current trunk source, I didn't mention fixes branch, where comparison would also be of interest... Anyhow, feel free to work on any topic and report about errors that you think you understood. The best here is usually to send a patch that allows to remove the investigated error! Thanks for your interest in Free Pascal, Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Test suit compilation is broken for win32-i386 after r21341?
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Max Nazhalov
Envoyé : dimanche 20 mai 2012 17:37
À : FPC Developers' list
Objet : [fpc-devel] Test suit compilation is broken for win32-i386 after
r21341?
Trying to run test suit out of r21343 results in
C:\prog\FPC_UTIL\make.exe full TEST_FPC=C:\prog\FPC\bin\i386-win32\fpc.exe
...
Free Pascal Compiler version 2.7.1 [2012/05/20] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling dotest.pp
Compiling redir.pp
redir.pp(980,41) Error: Identifier not found cint
redir.pp(980,47) Error: Identifier not found cint
redir.pp(983,6) Warning: Comparison might be always false due to range of
constant and expression
redir.pp(983,15) Warning: unreachable code
redir.pp(984,14) Error: Identifier not found wifexited
redir.pp(985,41) Error: Identifier not found wexitstatus
redir.pp(986,12) Warning: Comparison might be always true due to range of
constant and expression
redir.pp(988,2) Error: Operator is not overloaded: - erroneous type
redir.pp(1089) Fatal: There were 5 errors compiling module, stopping
Fatal: Compilation aborted
...
This piece of code (TransformfpSystemToShell) was introduced in r21341,
if
I understand right.
Should it be surrounded by {$ifdef UNIX} as it's done for
TransformfpSystemToShell call itself?..
Thanks, I committed a fix in rev 21346
Pierre
___
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] OpenBsd cross compiler
Hi Pierre, finally I got the time to test this. Sadly, this is the ./configure --target=i386-pc-openbsd -program-prefix=i386-openbsd- output. GNU tools like binutils should normally be configured using a build directory (not directly in sources) but I think it's mainly important if you want to use the same sources for different targets... I'm building this from an x86_64 Linux machine. Here's the output: loading cache ./config.cache checking host system type... x86_64-unknown-linux-gnu checking target system type... i386-pc-openbsd checking build system type... x86_64-unknown-linux-gnu checking for a BSD compatible install... (cached) /usr/bin/install -c checking for x86_64-unknown-linux-gnu-ar... no checking for ar... (cached) ar checking for x86_64-unknown-linux-gnu-as... no checking for as... (cached) as checking for x86_64-unknown-linux-gnu-dlltool... no checking for dlltool... (cached) dlltool checking for x86_64-unknown-linux-gnu-ld... no checking for ld... (cached) ld checking for x86_64-unknown-linux-gnu-nm... no checking for nm... (cached) nm checking for x86_64-unknown-linux-gnu-ranlib... no checking for ranlib... (cached) ranlib checking for x86_64-unknown-linux-gnu-windres... no checking for windres... (cached) windres checking for x86_64-unknown-linux-gnu-objcopy... no checking for objcopy... (cached) objcopy checking for x86_64-unknown-linux-gnu-objdump... no checking for objdump... (cached) objdump checking for i386-pc-openbsd-ar... no checking for i386-pc-openbsd-as... no checking for i386-pc-openbsd-dlltool... no checking for i386-pc-openbsd-ld... no checking for i386-pc-openbsd-nm... no checking for i386-pc-openbsd-ranlib... no checking for i386-pc-openbsd-windres... no checking whether to enable maintainer-specific portions of Makefiles... no creating ./config.status creating Makefile Leonardo M. Ramé http://leonardorame.blogspot.com The Makefile was created, so the next step is just to generate the binaries using make all-binutils all-gas all-ld if that also succeeds, you should have cross-binutils binaries that you should be able to install with make install-binutils install-gas install-ld prefix=/your/path/to/cross/binutils/base Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] OpenBsd cross compiler
Hi Leonardo, -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Leonardo M. Ramé Envoyé : jeudi 26 avril 2012 21:10 À : FPC developers' list Objet : [fpc-devel] OpenBsd cross compiler Hi, I usually create Win32 targets using this: make crossinstall OS_TARGET=win32 CPU_TARGET=i386 PP=/home/leonardo/Desarrollo/fpc/i386-linux-ppc386 Now I want to create an OpenBSD cross compiler, so I just replaced win32 by openbsd: Yes, but you do need cross-binutils for openbsd! The problem is that current GNU Binutils source do not generate correct objects/executables for openbsd. Which means that you need to get an openbsd specific binutils source install it, and configure it for the target you are interested in: I checked the internet, and it seems to be difficult to fond. Thus I added it to ftp://ftp.freepascal.org/pub/fpc/contrib/cross/openbsd/ 1) Downloaded ftp://ftp.freepascal.org/pub/fpc/contrib/cross/openbsd/binutils-openbsd-2.15 .tar.gz file. 2) Untar it tar -xvzf binutils-openbsd-2.15.tar.gz 3) Create build directory: mkdir build-cross-i386-openbsd cd build-cross-i386-openbsd 4) Run configure for that target ../binutils-4.9/configure --target=i386-pc-openbsd --program-prefix=i386-openbsd- (That's what I used on mingw32, but to compile on mingw you also need to apply the patch that I added in the same directory on ftp server). 5) Compile and install everything: make all-gas all-binutils all-ld make install-gas install-binutils install-ld prefix=PATH/TO/WHERE/YOU/WANT/IT This should install i386-openbsd-as i386-openbsd-ld and a few more into PATH/TO/WHERE/YOU/WANT/IT/bin directory Note that I didn't use the same procedure on mingw (because I wanted to get binaries that did not depend on any mingw specific DLLs) make crossinstall OS_TARGET=openbsd CPU_TARGET=i386 PP=/home/leonardo/Desarrollo/fpc/i386-linux-ppc386 But the linker is not found. This is the error I get: make[5]: se ingresa al directorio «/home/leonardo/Desarrollo/fpc/rtl/openbsd» /bin/mkdir -p /home/leonardo/Desarrollo/fpc/rtl/units/i386-openbsd i386-openbsd-as -o /home/leonardo/Desarrollo/fpc/rtl/units/i386- openbsd/prt0.o i386/prt0.as make[5]: i386-openbsd-as: No se encontró el programa make[5]: *** [prt0.o] Error 127 make[5]: se sale del directorio «/home/leonardo/Desarrollo/fpc/rtl/openbsd» make[4]: *** [openbsd_all] Error 2 make[4]: se sale del directorio «/home/leonardo/Desarrollo/fpc/rtl» make[3]: *** [rtl] Error 2 make[3]: se sale del directorio «/home/leonardo/Desarrollo/fpc/compiler» make[2]: *** [cycle] Error 2 make[2]: se sale del directorio «/home/leonardo/Desarrollo/fpc/compiler» make[1]: *** [compiler_cycle] Error 2 make[1]: se sale del directorio «/home/leonardo/Desarrollo/fpc» make: *** [build-stamp.i386-openbsd] Error 2 Is there an i386-openbsd-as linker?. Where can I find it. i386-openbsd-as is the assembler, not the linker i386-openbsd-ld is the linker. BTW. I'm on Linux x86_64 (Ubuntu 11.10). You could repeat the steps for x86_64-openbsd target by simply using --target=x86_646pc-openbsd Hoping the above will help, Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] update on freepascal armhf porting, doubles are working now for singles.
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de peter green Envoyé : samedi 17 mars 2012 02:35 À : FPC developers' list Objet : [fpc-devel] update on freepascal armhf porting, doubles are working now for singles. I can now successfully pass doubles to/from C functions on armhf. I've written a test program that passes lots of different combinations of single/double/longint/int64 to C code and all combinations that do not involve singles are working. It would also be helpful to add this test to the testsuite we do have some tests in test/cg but it wouldn't hurt to add more of that type! Pierre A patch with the current state of the work is attatched. I will leave to others the comments about the changes to the compiler as I have little knowledge about ARM specific issues. Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Bounty for MIPS
Anyhow, I just discovered that the /home directory is 99% full on that GCC compile farm machine, meaning that only remote tests will be possible ☹ It seems that lots of developers have the same issue about finding MIPS machines for testing …. Would you consider the NetGear WNDR3800 680Mhz, 128MB RAM with a USB Flash drive of 32GB to be good enough for the development of the FPC toolchain ? (in this case, I can purchase and ship such device to your place), or would you consider that only a qemu virtual MIPS machine which can handle more memory and more disk space to be suitable for the development ? I just googled a bit and read that the USB flash drives are considered as having only a limited number of writes before that fail... (http://en.wikipedia.org/wiki/USB_flash_drive) So I wonder how long such a system like that would last (it probably also depends on the USB key quality itself?) if I run the testsuite each night on it... Would a small USB hard drive be better? But does the device have enough power to support such an external drive? Would the speed be significantly lower or is the USB 2.0 speed the real limitation? Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Bounty for MIPS
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd Envoyé : dimanche 29 janvier 2012 15:19 À : fpc-devel@lists.freepascal.org Objet : Re: [fpc-devel] Bounty for MIPS Florian Klämpfl wrote: Main problem with MIPS is to get hands on a reasonable development system (full fledged unix like Debian Linux, *BSD, CPU in the range of 1 GHz, 128 MB or more RAM, at least 1 GB of HD/SSD). Cross compiling is possible of course, but it makes testing and bug fixing very tedious. If ssh to such a system is available, I'll look into fixing the MIPS port without any bounty. My experience is that Qemu's support of a MIPS target isn't bad, although what I've done so far has been cross-hosted which was certainly good enough for compilation of e.g. the compiler in isolation. Didn't somebody already have loan hardware for this? I'd certainly be happy to continue chugging away at testing once the assembler reader issue was sorted out- at least until the next insurmountable problem :-) It seems that David Zhang's compiler already had such a reader, I will try to adapt it if I find the time. Questions: It seems like GNU AS has a different MUPS syntax as traditional MIPS assembler, but I didn't find precise information about this; Could someone give me some pointers? Pierre PS: I do have access to a GCC Compile farm machine running on gcc42 160G 0.8 GHz ICT Loongson 2F / 512 MB RAM / Lemote Fuloong 6004 Linux mini PC / Debian mipsel muller@gcc42:~$ uname -a Linux gcc42 2.6.27.1 #476 Tue Oct 20 14:25:23 CST 2009 mips64 GNU/Linux No idea how that machine would compare to the one we were talking about here. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Bounty for MIPS
Anyhow, I just discovered that the /home directory is 99% full on that GCC compile farm machine, meaning that only remote tests will be possible L It seems that lots of developers have the same issue about finding MIPS machines for testing . Pierre De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-boun...@lists.freepascal.org] De la part de Jy V Envoyé : dimanche 29 janvier 2012 16:32 À : FPC developers' list Objet : Re: [fpc-devel] Bounty for MIPS Pierre, muller@gcc42:~$ uname -a Linux gcc42 2.6.27.1 #476 Tue Oct 20 14:25:23 CST 2009 mips64 GNU/Linux No idea how that machine would compare to the one we were talking about here. on the WNDR3800 the OpenWRT installed gives root@OpenWrt:~# uname -a Linux OpenWrt 2.6.32.27 #5 Wed Dec 21 01:59:33 CET 2011 mips GNU/Linux root@OpenWrt:~# cat /proc/cpuinfo system type : Atheros AR7161 rev 2 machine : NETGEAR WNDR3700v2 processor : 0 cpu model : MIPS 24Kc V7.4 BogoMIPS: 452.19 wait instruction: yes microsecond timers : yes tlb_entries : 16 extra interrupt vector : yes hardware watchpoint : yes, count: 4, address/irw mask: [0x, 0x0ff8, 0x0ff8, 0x0ff8] ASEs implemented: mips16 shadow register sets: 1 core: 0 VCED exceptions : not available VCEI exceptions : not available the router devices are almost all the same, using the MIPS Atheros the 20 euros target device http://wiki.openwrt.org/toh/tp-link/tl-wr703n is using similar MIPS from Atheros Jerome. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Bounty for MIPS
Questions: It seems like GNU AS has a different MUPS syntax as traditional MIPS assembler, but I didn't find precise information about this; Could someone give me some pointers? I don't think I've got access to any MIPS as other than gas, but if necessary I could put the disc that came with my problematic SGI system into a PC server and investigate whether it has any development software (it's a fairly minimal IRIX). What differences did you have in mind? Take a look at trunk/rtl/linux/mips/prt0.as This file is non-functional, but it seems to contain some disassembly of a start code (probably from some other compiler...) This disassembly syntax seems quite different from the other assembler code (below in same file and in other sources seem more like gnu as generated by GCC if using --save-temps. Well, at least register naming is different (using a4 or s7 instead of $sp and $X where X is a number...) Anyway, maybe the content of rtl/mips/prt0.as isn't really MIPS assembler at all :( Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] issue in heaptrc?
Yes, you are right...
I just committed a fix (together with multi-threaded windows executable
support in trunk)
If you have svn trunk, could you check that revision 20181 fixes
the problem you report?
Thanks in advance,
Pierre
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Martin
Envoyé : jeudi 26 janvier 2012 06:37
À : FPC developers' list
Objet : [fpc-devel] issue in heaptrc?
I ve been playing around with -gc and I found something suspect in heaptrc
procedure CheckPointer(p : pointer); [public, alias : 'FPC_CHECKPOINTER'];
p is a pointer, that should be somewhere *inside* an allocated block
of mem
pp:=loc_info^.heap_mem_root;
while ppnil do
begin
{ inside this block ! }
if
(ptruint(p)=ptruint(pp)+sizeof(theap_mem_info)+ptruint(extra_info_size))
and
(ptruint(p)=ptruint(pp)+sizeof(theap_mem_info)+ptruint(extra_info_size)+ptr
uint(pp^.size))
then
if this loop does not find anything then
writeln(ptext^,'pointer $',hexstr(p),' does not point to valid memory
block');
dump_error(p,ptext^);
runerror(204);
but
procedure dump_error(p : pheap_mem_info;var ptext : text);
expects a pheap_mem_info, p is not a pheap_mem_info
and that is where it crashes (shortly before dump stack trace :( )
Did I miss something or is there a bug?
___
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] Paramstr trailing spaces, bug or not?
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Joost van der Sluis Envoyé : samedi 24 décembre 2011 14:23 À : FPC developers' list Objet : Re: [fpc-devel] Paramstr trailing spaces, bug or not? On Fri, 2011-12-23 at 17:25 +0400, Sergei Gorelkin wrote: 23.12.2011 16:18, Marco van de Voort пишет: - syswin.inc code looks like any number of delimiters between parameters are skipped. .. unless quoted. - this extra whitespace is added by the makefile, suggesting some buggy/incorrect processing in make.exe or makefile itself. It could be that the makefile logic quotes every argument on windows, in case of spaces. We would need a kind of strace tool for Windows to find out. ... it is the trailing backslash escaping the following character (C style). I could reproduce the issue, by using the following command in 'packages' directory: So to conclude, it's a problem of make that it handles the backslash as if it were a escaping-backslash. There's nothing that we have to change, except that fpmake has to trim it's input values to handle this buggy make-behavior. I don't think that its buggy behavior, windows make, be it cygwin, mingw32 (and probably also msys) do expect only forward slashes for directory separators and always handles backward slashes as escapes. Using forward slashes for all parameters of a make call should avoid the problem... If you really wanted backward slashes, then, simply use escaped backslashes, i.e. two in a row, make install PREFIX=c:\\lazarus\\fpc\\2.7.1\\ Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Paramstr trailing spaces, bug or not?
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Joost van der Sluis Envoyé : jeudi 22 décembre 2011 17:36 À : FPC developers' list Objet : Re: [fpc-devel] Paramstr trailing spaces, bug or not? On Thu, 2011-12-22 at 17:18 +0100, michael.vancann...@wisa.be wrote: With this command-line: fpmake --prefix=bla --baseistall=test paramstr(1) gives --prefix=bla . Thus with the trailing space. Is this a bug or a feature? It's what the shell has passed on. The paramstr() code doesn't do any parsing on Linux. It returns the elements in argv[] Most of the time I'm indeed on Linux, but this case it was Windows. But I guess the same thing holds? Hi Jost, I am completely unable to reproduce this... on a windows machine! Futhermore this behavior would break lots of code including the compiler itself... Maybe there is some special configuration you are working on that explains this strange behavior... Which Windows OS version do you use? Is it a Virtual machine? What shell are you using? Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Building trunk on Win32
I tired to reproduce your problem starting from release 2.4.4 compiler, but got no error. Then I tried to find where error code 226 could be generated: it is in rtl/win/systhrd.inc function SysAllocateThreadVars most probably because your system returned nil for a LocalAlloc call. Could you test by only doing a make cycle at compiler level? Pierre Muller De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-boun...@lists.freepascal.org] De la part de Leonardo M. Ramé Envoyé : vendredi 25 novembre 2011 22:01 À : FPC developers' list Objet : [fpc-devel] Building trunk on Win32 Hi, I'm trying to build the latest svn trunk on a Win32 machine. e:\FPC-bin\bin\i386-win32\make.exe PP=e:\fpc-bin\bin\i386-win32\ppc386.exe all Where e:\fpc-bin\bin\i386-win32\ppc386.exe is this revision: E:\fpce:\fpc-bin\bin\i386-win32\ppc386.exe Free Pascal Compiler version 2.4.4 [2011/04/23] for i386 Copyright (c) 1993-2010 by Florian Klaempfl I don't remember but I think it was downloaded from http://www.freepascal.org/down/i386/win32-ftp.freepascal.org.var, so I think it's a stable version. Anyway, the results of my make are this: fmtbcd.pp(2598,49) Warning: Symbol CurrencyString is deprecated fmtbcd.pp(2599,44) Warning: Symbol CurrencyString is deprecated fmtbcd.pp(3844,52) Warning: Implicit string type conversion with potential data loss from WideString to AnsiString fmtbcd.pp(3845,33) Warning: Implicit string type conversion with potential data loss from UnicodeString to AnsiString E:/fpc/compiler/ppc2.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../win -FE. -FUE :/fpc/rtl/units/i386-win32 -di386 -dRELEASE ../inc/macpas.pp make.exe[7]: *** [macpas.ppu] Error 226 make.exe[7]: Leaving directory `E:/fpc/rtl/win32' make.exe[6]: *** [win32_all] Error 2 make.exe[6]: Leaving directory `E:/fpc/rtl' make.exe[5]: *** [rtl] Error 2 make.exe[5]: Leaving directory `E:/fpc/compiler' make.exe[4]: *** [next] Error 2 make.exe[4]: Leaving directory `E:/fpc/compiler' make.exe[3]: *** [ppc3.exe] Error 2 make.exe[3]: Leaving directory `E:/fpc/compiler' make.exe[2]: *** [cycle] Error 2 make.exe[2]: Leaving directory `E:/fpc/compiler' make.exe[1]: *** [compiler_cycle] Error 2 make.exe[1]: Leaving directory `E:/fpc' e:\FPC-bin\bin\i386-win32\make.exe: *** [build-stamp.i386-win32] Error 2 How can I fix this?. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] threads crash on FreeBSD 9 RC1, FPC 2.6RC1
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Helmut Hartl Envoyé : mercredi 9 novembre 2011 20:58 À : fpc-devel@lists.freepascal.org Objet : Re: [fpc-devel] threads crash on FreeBSD 9 RC1, FPC 2.6RC1 Am 09.11.11 14:12, schrieb Pierre Free Pascal: while testing our code on freebsd 9RC1/32 bit with fpc 2.6rc1 it seems that all programs compiled on that system using threads crash with an Illegal Instruction 4 (core dumped) error. Binaries compiled on Freebsd 8.2/32 and transferred to the 9RC1 box work, which is a bit strange. There is no warranty that an executable for a given version will work on a later... If only one system call interface is changed, this is enough to break everything! What made me wonder was, that the (old) binary compiled on 8.2 still worked on 9.0RC1 after the upgrade from 8.2 - 9.0 (same machine) while the new one compiled with the same compiler after the upgrade crashed. If I copy back the new binary (same source) to a 8.2 machine it fails with a linker failure unresolved symbol sem_init. But thats only a observation that i am too dumb to understand atm, and maybe unrelated to the main problem. I retested your test source. test-9rc1 was compiled on 9RC1 machine and copied back to 8.2 machine. On 8.2 machine: [pierre@freelove64 ~/pas/test]$ ./test-9rc1 /usr/libexec/ld-elf.so.1: /usr/home/pierre/pas/test/test-9rc1: Undefined symbol sem_init [pierre@freelove64 ~/pas/test]$ objdump -T ./test-9rc1 | grep sem_ DF *UND* 0056 FBSD_1.2sem_trywait DF *UND* 004a FBSD_1.2sem_init DF *UND* 0007 FBSD_1.2sem_wait DF *UND* 004f FBSD_1.2sem_post DF *UND* 0031 FBSD_1.2sem_destroy [pierre@freelove64 ~/pas/test]$ objdump -T ./test | grep sem_ 00400e38 DF *UND* 0141 FBSD_1.0sem_wait 00400ea8 DF *UND* 0073 FBSD_1.0sem_post 00400f18 DF *UND* 0081 FBSD_1.0sem_trywait 00401008 DF *UND* 0051 FBSD_1.0sem_destroy 00401068 DF *UND* 00f4 FBSD_1.0sem_init [pierre@freelove64 ~/pas/trunk/rtl/freebsd]$ objdump -T /lib/libthr.so.3 |grep sem_init 79e0 gDF .text 00f4 FBSDprivate_1.0 _sem_init 79e0 w DF .text 00f4 FBSD_1.0sem_init DF *UND* FBSD_1.0ksem_init On the 9RC1 machine: [pierre@freelovebeta64 ~/pas/test]$ objdump -T /lib/libthr.so.3 |grep sem_init 7cc0 w DF .text 0005 (FBSD_1.0) sem_init DF *UND* 0083 FBSDprivate_1.0 _libc_sem_init_compat I still don't understand much about shared library versioning, so maybe someone with more knowledge could help us here... I suspect that it is due to the fact that the FBSD_1.2 version is required by the 9RC1 compiled executable, but why does it find the FBSD_1.0 sem_init symbol on 9RC1 and not on 8.2? Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] threads crash on FreeBSD 9 RC1, FPC 2.6RC1
Tanks to Helmut, we now also have a FreeBSD with OS 9RC1 to test Free Pascal on: The testsuite reveals no difference between native OS8 or OS9RC1: http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=1run1id=97 488run2id=97496noskipped=1failedonly=1 I will also try to test in cross configuration to see what happens. On i386, I get: http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=1run1id=97 491run2id=97501noskipped=1failedonly=1 but the difference is simply due to a change in installed libraries So FreBSD 8 and 9RC1 seem to be quite perfectly binary compatible Pierre Muller FreeBSD compilation on 8.2 and test run on 9RC1 gives no noticeable changes: http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=1run1id=97 552run2id=97574noskipped=1failedonly=1 The two changes are simply due to the fact that zlib shared library probably is also installed on the 8.2 VM and not on the 9RC1. The second change is due to the fact that on 8.2 the RTL was compiled using DEUG=1 make option, which changed the outcome of that particular test about setting position of a stream to -1. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] threads crash on FreeBSD 9 RC1, FPC 2.6RC1
while testing our code on freebsd 9RC1/32 bit with fpc 2.6rc1
it seems that all programs compiled on that system using threads crash
with an Illegal Instruction 4 (core dumped) error.
Binaries compiled on Freebsd 8.2/32 and transferred to the 9RC1 box work,
which is a bit strange.
There is no warranty that an executable for a given version
will work on a later...
If only one system call interface is changed, this is enough to break
everything!
Any ideas ?
further details below:
Simple test case:
---
program thrd;
{$mode objfpc}{$H+}
uses
cthreads,Classes;
type
T=class(TThread)
private
i:integer;
procedure Execute;override;
end;
procedure T.Execute;
begin
inc(i);
end;
begin
T.create(false);
end.
---
After compiling fpc 2_6 fixes with debug info, and running the program
gdb stops at the below marked line in cthreads.pp
procedure CAllocateThreadVars;
var
dataindex : pointer;
begin
{ we've to allocate the memory from system }
{ because the FPC heap management uses }
{ exceptions which use threadvars but }
{ these aren't allocated yet ...}
{ allocate room on the heap for the thread vars }
DataIndex:=Pointer(Fpmmap(nil,threadvarblocksize,3,MAP_PRIVATE+MAP_ANONYMOUS
,-1,0));
FillChar(DataIndex^,threadvarblocksize,0);
pthread_setspecific(tlskey,dataindex);
end;
What does
(gdb) x /10i $rip
(or $eip if it is an i386 executable)
give as output?
Pierre Muller
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] 68K
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Sven Barth Envoyé : vendredi 4 novembre 2011 11:35 À : fpc-devel@lists.freepascal.org Objet : Re: [fpc-devel] 68K Am 04.11.2011 10:45, schrieb Michael Schnell: trunk/compiler/m68k/cpupara.pas has just been updated. Does this mean that somebody is working on the 68K compiler ? No. The commiter silenced some warnings, because a new option was introduced where warnings are handled as errors and the compiler is now compiled with this option by default (if I've understood that discussion correctly). * I confirm what Sven answered above, as I am the committer! Sorry for the disappointment this might produce, but it is indeed only related to the use of -Sew option by default now for compiler source compilation. Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] OpenBSD compiler
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Marco van de Voort Envoyé : lundi 10 octobre 2011 08:52 À : FPC developers' list Objet : Re: [fpc-devel] OpenBSD compiler In our previous episode, Pierre Free Pascal said: (*) FreeBSD's pipe command contains an optimization. The array is not passed to the syscall, and the results are stored in regs, not in the array. The wrapper code stores the regs in the array. The current FreeBSD code is i386/x86_64 only... I already installed a 9.0 beta on powerpc :-) I also installed NetBSD in a VM. maybe it should use the normal code you added for other CPUs (even if those are not yet supported...) I think we just soldier on target by target, see the ifdefs grow, and then start thinking about splitting heavily ifdefed parts of the include files in bsd/ over the targets. (and they can decide for themselves if they split them out over the arch dirs) Some other points: 1) no I didn't commit cprt0 since the result didn't work. You were right, it didn't help much: http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?os=7cpu=8version =0date=submitter=machine=comment=cond= 2) Did you test with elf binwriter ? It took me a long time to understand the problem, but I think I found it now: OpenBSD ld seems to do nonsense if you do not explicitly give him a dynamic loader it inserted /usr/lib/libc.so.1 as the dynamic loader... Adding an explicit -FL/usr/libexec/ld.so seems to allow at least tests/test/cg/tprinf to run successfully. I will commit a fix setting a default dynamic linker for OpenBSD if this improves the results significantly! Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] OpenBSD compiler
/bin/rm -f fpcmade.i386-openbsd Package.fpc ppas.sh script.res link.res /bin/rm -f *.s *_ppas.sh gmake[7]: Leaving directory `/var/home/leonardo/fpc/rtl/openbsd' gmake[6]: Leaving directory `/var/home/leonardo/fpc/rtl' gmake -C /var/home/leonardo/fpc/rtl 'OPT=' all gmake[6]: Entering directory `/var/home/leonardo/fpc/rtl' gmake -C openbsd all gmake[7]: Entering directory `/var/home/leonardo/fpc/rtl/openbsd' as -o /var/home/leonardo/fpc/rtl/units/i386-openbsd/prt0.o i386/prt0.as as -o /var/home/leonardo/fpc/rtl/units/i386-openbsd/cprt0.o i386/cprt0.as /var/home/leonardo/i386-openbsd-ppc386 -Ur -FD -Ur -Xs -O2 -n -Fi../inc - Fi../i386 -Fi../unix -Fi../bsd -Fi../bsd/i386 -Fi../openbsd/i386 -FE. - FU/var/home/leonardo/fpc/rtl/units/i386-openbsd -di386 -dRELEASE -Us -Sg ../bsd/system.pp Problem confirmed: I use Sys call number 312 for getdirentries but for 4.4, the last system call is 310. I tested if getdirentries35 works OK, I was able to do a gmake cycle on a 4.4 openbsd. Committed in 19423. Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] OpenBSD compiler
Great!. I did an svn up, then gmake again, but the problem persists. What gmake options did you use?. Maybe you should upload the new bootstrapping compiler to ftp://ftp.freepascal.org/pub/fpc/contrib/ I added a i386 openbsd ppc386 executable in: ftp://ftp.freepascal.org/pub/fpc/snapshot/v27/i386-openbsd/ In the hope that it could be useful for others too... Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] OpenBSD compiler
? I tested if getdirentries35 works OK, I was able to do a gmake cycle on a 4.4 openbsd. Committed in 19423. For me the one before this already worked. I tried a make all, and that failed in the fpmake of fcl-base on the pipe syscall. That's a know gotcha that I know still from 1.0.x times, so it was easily fixed. (*) If you tried make all before, don't forget to run make distclean though, to kill stale fpmake's. I surely spend some time trying to understand that failure... Great you already knew about it! The make all snapshot is still running for more than an hour now, and already way beyond the previous problem point. The slowliness is probably a combination of VM and slower than usual assembling and ARing without binwriter. Ok, the make all just stopped, it breaks on pkgwget when compiling fppkg. I got to the same point now... I will try to launch a native openbsd testsuite overnight. Anyway, if the snapshot runs to completion tomorrow, we'll see if we can upload it. Then we merge openbsd to fixes after 2.6.0-final is branched off, so that we have a 2.6 series starting compiler. (*) FreeBSD's pipe command contains an optimization. The array is not passed to the syscall, and the results are stored in regs, not in the array. The wrapper code stores the regs in the array. The current FreeBSD code is i386/x86_64 only... maybe it should use the normal code you added for other CPUs (even if those are not yet supported...) Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] First i386-OpenBSD compiler testsuite resutls
See http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?os=7cpu=8version =0date=submitter=machine=comment=cond= Marco, didn't you say that you fixed i386/cprt0.as for the missing operatingsystem_parameter vars? Maybe you forgot to commit the fix, anyway, I committed rev 19443. I also restarted a testsuite adding -Fl/usr/local/lib as at least libiconv library is in that directory. Pierre -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Marco van de Voort Envoyé : dimanche 9 octobre 2011 22:19 À : Leonardo M. Ramé; FPC developers' list Objet : Re: [fpc-devel] OpenBSD compiler In our previous episode, Leonardo M. Ram? said: Problem confirmed: ? I use Sys call number 312 for getdirentries but for 4.4, the last system call is 310. ? I tested if getdirentries35 works OK, I was able to do a gmake cycle on a 4.4 openbsd. Committed in 19423. For me the one before this already worked. I tried a make all, and that failed in the fpmake of fcl-base on the pipe syscall. That's a know gotcha that I know still from 1.0.x times, so it was easily fixed. (*) If you tried make all before, don't forget to run make distclean though, to kill stale fpmake's. The make all snapshot is still running for more than an hour now, and already way beyond the previous problem point. The slowliness is probably a combination of VM and slower than usual assembling and ARing without binwriter. Ok, the make all just stopped, it breaks on pkgwget when compiling fppkg. Anyway, if the snapshot runs to completion tomorrow, we'll see if we can upload it. Then we merge openbsd to fixes after 2.6.0-final is branched off, so that we have a 2.6 series starting compiler. (*) FreeBSD's pipe command contains an optimization. The array is not passed to the syscall, and the results are stored in regs, not in the array. The wrapper code stores the regs in the array. ___ 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] OpenBSD compiler
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Marco van de Voort Envoyé : vendredi 7 octobre 2011 23:53 À : FPC developers' list Objet : Re: [fpc-devel] OpenBSD compiler In our previous episode, Pierre Free Pascal said: The ones with compat are probably OK, No, they are old syscalls only kept for compatibility. That means you also have to use the corresponding old syscalls. I also think the getdents=getdirentries alias is not entirely correct. You were right, getdirentries has one more parameter! I adapted bsd/ossysc.inc It is possible that what we see here in trunk is not the same as what worked, long,long ago in the fixes1_0 branch, since in that time release branches were not kept as close in sync to trunk as nowadays. I tried to cross-compile the compiler, but it crashes inside a fsearch call... Probably readdir again, I'll work on it on and off as I have time the coming days. Too late... (at least hopefully) I just achieved a successful 'gmake cycle' on i386 openbsd. Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] OpenBSD compiler
Pierre, glad to hear that. What compiler did you use to bootstrap?. I used a mingw compiled Openbsd Binutils source (available in */usr/src/gnu/usr.bin/Binutils/binutils on a BSD machine with source installed). (with small mods to I've downloaded one from FreePascal's ftp, but it gives me Bad system call when I run it. I uploaded these new cross-binutils to ftp://ftp.freepascal.org/pub/fpc/contrib/cross/mingw in file binutils-2.15-win32-i386-openbsd.zip In the hope that this helps... Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] OpenBSD compiler
I just added a script rtl/openbsd/check_sys.sh to compare Free Pascal syscall numbers in rtl/openbsd/sysnr.inc to the values in /usr/include/sys/syscall.h I fixed the trivial issues, but now I get those: -bash-4.1$ ./check_sys.sh problem for SYS_dup expected 41 line is #define SYS_dup 41 problem for SYS_sigaltstack expected 53 line is #define SYS_sigaltstack 288 problem for SYS_semsys expected 169 line is 169 is compat_10 osemsys */ problem for SYS_msgsys expected 170 line is 170 is compat_10 omsgsys */ problem for SYS_shmsys expected 170 line is 170 is compat_10 omsgsys */ problem for SYS_stat35 expected 188 line is 188 is compat_35 stat35 */ problem for SYS_fstat35 expected 189 line is 189 is compat_35 fstat35 */ problem for SYS_lstat35 expected 190 line is 190 is compat_35 lstat35 */ problem for SYS_getdirentries35 expected 196 line is #define SYS_ogetdirentries 196 problem for SYS_xfspioctl expected 208 line is #define SYS_nnpfspioctl 208 problem for SYS_semop35 expected 222 line is 222 is compat_35 semop */ problem for SYS_shmget35 expected 231 line is 231 is compat_35 shmget */ problem for SYS___semctl35 expected 257 line is 257 is compat_35 semctl35 */ problem for SYS_shmctl35 expected 258 line is 258 is compat_35 shmctl35 */ problem for SYS_msgctl35 expected 259 line is 259 is compat_35 msgctl35 */ problem for SYS_getpeereid expected 273 line is 273 is compat_o47 getpeereid */ problem for SYS_signalstack expected 288 line is #define SYS_sigaltstack 288 The ones with compat are probably OK, but what about SYS_sigaltstack and SYS_signalstack, they seem to be inversed! I tried to cross-compile the compiler, but it crashes inside a fsearch call... Pierre -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Marco van de Voort Envoyé : vendredi 7 octobre 2011 18:51 À : FPC developers' list Objet : Re: [fpc-devel] OpenBSD compiler In our previous episode, Tomas Hajny said: Some status update after some play yesterday evening: . . 4. The next big crash is, as usual for a new port, in fexpand/expandfilename/readdir. . I assume you probably meant FindFirst rather than FExpand/ExpandFileName, right? FExpand needs only GetDir and GetEnv/GetEnvironmentVariable which should hardly be a reason for a crash of any new port hopefully... Don't worry. I'm not dissing your fexpand :-) The unix implementation of getdir can actually enumerate directories. So the problem is in readdir, but on *nix ports the crash will be in expandfilename because getdir stresses readdir hard, and in the compiler that happens before the first findfirst. The problem of readdir is simply that it is one of the few core functionalities with a sizable userland part, and the implementations can be fairly different across OSes. (with even two choices for the kernel call used) I ran into it already with the original FreeBSD port (done just before 1.0, merged in slightly after 1.0) This because in the original Linux port, readdir WAS a system call. Another such traditional issue is the handling of seek and truncate, because they are syscalls with 64-bit types. Some OSes that call syscalls with values in registers still call them as if they were on the stack, and insert extra zero parameters to align, and some don't, with variations per architecture. ___ 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] OpenBSD compiler
I tried to get i386-openbsd port up to date, using mingw cross Binutils that I compiled myself using openbsd sources. Should I add those to ftp? But I am stuck because I have a 64-bit OpenBSD virtual machine (and no room to add a i386 version on my machine) but all cross-compiled executables. Is it possible to install an openbsd equivalent of lib32? How do you compile i386 openbsd executables using GCC on a amd64 machine? Pierre De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-boun...@lists.freepascal.org] De la part de Leonardo M. Ramé Envoyé : mercredi 5 octobre 2011 01:31 À : FPC developers' list Objet : [fpc-devel] OpenBSD compiler Hi, I noted that Pierre is updating the OpenBSD port. Does anyone knows where can I find a bootstraping compiler for this platform?. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] New Windows gdb-binary
Use this new macro: $ cvs diff -u -p gdbtypes.h Index: gdbtypes.h === RCS file: /cvs/src/src/gdb/gdbtypes.h,v retrieving revision 1.153 diff -u -p -r1.153 gdbtypes.h --- gdbtypes.h 5 Jul 2011 13:36:41 - 1.153 +++ gdbtypes.h 3 Oct 2011 14:39:08 - @@ -1115,6 +1115,11 @@ extern void allocate_gnat_aux_type (stru || TYPE_NFN_FIELDS (thistype) == 0) \ (TYPE_STUB (thistype) || !TYPE_STUB_SUPPORTED (thistype))) +/* A helper macro that returns the name of a type or unnamed type if the type + has no name. */ +#define TYPE_SAFE_NAME(type) \ + (TYPE_NAME (type) ? TYPE_NAME (type) : _(unnamed type)) + /* A helper macro that returns the name of an error type. If the type has a name, it is used; otherwise, a default is used. */ #define TYPE_ERROR_NAME(type) \ roflol. Take a good look at this patch. Especially the last few lines... Of course I saw the TYPE_ERROR_NAME macro and I adapted it because I believed that you were using this in a case where the type itself was not an error type. I'll use TYPE_ERROR_NAME. Thanks for the hint. ;) Again, it all depends if you only need it for types that are already flagged as error type (which has a precise meaning inside GDB). Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] New Windows gdb-binary
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Joost van der Sluis Envoyé : lundi 3 octobre 2011 16:24 À : FPC developers' list Objet : Re: [fpc-devel] New Windows gdb-binary On Sat, 2011-10-01 at 10:26 +0200, Florian Klämpfl wrote: Am 30.09.2011 15:02, schrieb Joost van der Sluis: Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip Did you get also a libgdb.a which you could provide for the fpc ide? No. I don't know how to build a libgdb.a. I'll look into it later. Loook at packages/gdbint/gen-gdblib-inc.sh script, it should also work for mingw. Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] New Windows gdb-binary
Hi Joost,
Did you use the mingw 7.3 patch that handles
the windows style path containing ':'?
I recreated the patch below by doing a diff
from official GDB 7.3 release
and mingw7.3.2 sources.
Without this, debug information containing drive letters
are wrongly cut into parts at the ':' position...
Pierre
diff -r -u -p -N gdb-7.3/config.rpath gdb-7.3-mingw/config.rpath
--- gdb-7.3/config.rpath2011-02-13 22:00:08.0 +0100
+++ gdb-7.3-mingw/config.rpath 2011-08-04 03:30:58.0 +0200
@@ -438,7 +438,7 @@ case $host_os in
bsdi4*)
;;
cygwin* | mingw* | pw32*)
-shrext=.dll
+shrext=.dll.a
;;
darwin* | rhapsody*)
shrext=.dylib
diff -r -u -p -N gdb-7.3/gdb/linespec.c gdb-7.3-mingw/gdb/linespec.c
--- gdb-7.3/gdb/linespec.c 2011-07-04 16:19:14.0 +0200
+++ gdb-7.3-mingw/gdb/linespec.c2011-08-04 03:30:58.0 +0200
@@ -1222,7 +1222,8 @@ locate_first_half (char **argptr, int *i
quotes we do not break on enclosed spaces. */
if (!*p
|| p[0] == '\t'
- || (p[0] == ':')
+ || ((p[0] == ':')
+ ((p[1] == ':') || (strchr (p + 1, ':') == NULL)))
|| ((p[0] == ' ') !*is_quote_enclosed))
break;
if (p[0] == '.' strchr (p, ':') == NULL)
diff -r -u -p -N gdb-7.3/gdb/source.c gdb-7.3-mingw/gdb/source.c
--- gdb-7.3/gdb/source.c2011-03-23 19:23:55.0 +0100
+++ gdb-7.3-mingw/gdb/source.c 2011-08-04 03:30:59.0 +0200
@@ -991,6 +991,7 @@ find_and_open_source (const char *filena
char *path = source_path;
const char *p;
int result;
+ char *lpath;
/* Quick way out if we already know its full name. */
@@ -1009,7 +1010,12 @@ find_and_open_source (const char *filena
result = open (*fullname, OPEN_MODE);
if (result = 0)
- return result;
+{
+ lpath = gdb_realpath(*fullname);
+ xfree(*fullname);
+ *fullname = lpath;
+ return result;
+}
/* Didn't work -- free old one, try again. */
xfree (*fullname);
*fullname = NULL;
diff -r -u -p -N gdb-7.3/gdb/utils.c gdb-7.3-mingw/gdb/utils.c
--- gdb-7.3/gdb/utils.c 2011-05-17 23:26:28.0 +0200
+++ gdb-7.3-mingw/gdb/utils.c 2011-08-04 03:30:59.0 +0200
@@ -3634,6 +3634,30 @@ gdb_realpath (const char *filename)
}
#endif
+ /* The MS Windows method. If we don't have realpath, we assume we
+ don't have symlinks and just canonicalize to a Windows absolute
+ path. GetFullPath converts ../ and ./ in relative paths to
+ absolute paths, filling in current drive if one is not given
+ or using the current directory of a specified drive (eg, E:foo).
+ It also converts all forward slashes to back slashes. */
+#if defined (_WIN32)
+ {
+char buf[MAX_PATH];
+char* basename;
+DWORD len = GetFullPathName (filename, MAX_PATH, buf, basename);
+if (len == 0 || len MAX_PATH - 1)
+ return xstrdup (filename);
+else
+ {
+/* The file system is case-preserving but case-insensitive,
+ Canonicalize to lowercase, using the codepage associated
+ with the process locale. */
+CharLowerBuff (buf, len);
+return xstrdup (buf);
+ }
+ }
+#endif
+
/* This system is a lost cause, just dup the buffer. */
return xstrdup (filename);
}
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Arm Thumb2 - Stellaris status
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Geoffrey Barton Envoyé : mardi 9 août 2011 10:20 À : FPC developers' list Objet : Re: [fpc-devel] Arm Thumb2 - Stellaris status On 8 Aug 2011, at 21:13, Florian Klämpfl wrote: Am 08.08.2011 12:49, schrieb John Clymer: Kicking it around in the back of my head at work today... I tried doing a compile to assembly language for the stellaris - and it choked giving the error from t_embed.pas. The error comes from the portion of the program trying to generate a linker script. Looking at t_embed.pas, it looks like every single flavor of ARM controller will require it's own subsection of the case() statement. This can easily get long and ugly. As the only thing that changes between most of the arm variants is the memory layout - why not provide a generic stellaris switch - with reads in a text file containing the memory map and stack top (the rest of the link file remains the same for all variants of ARM) ? This way - switching to a new variant of stellaris only requires tweaking a memory map file - rather than a re-build and patch of t_embed.pas ? For that matter - entirely foreign Cortex M3 parts could be easily supported without requiring changes to the compiler. Just pondering how to make it easier and more flexible ... Yes, this can be done. However, somebody who knows enough about a certain controller family must do this. What in your view is the best way to separate link options such as these variations in memory maps between devices? I often have several projects at once and they can be using different parts within the same family; having to re-compile the compiler when switching between projects is not ideal. What about adding some command line options similar to -WB: -WB4 sets the default load address of Windows PE executables to 0x4. Its value is stored in global variable ImageBase. If only four or five values need to be set, we could just implement option -WE option: E for embedded, with -WEFlashOriginHexDecimalValue -WEFlashLengthHexDecimalValue -WERamOriginHexDecimalValue -WERamLengthHexDecimalValue -WEStackTopHexDecimalValue Of course, this depends if the list of required values is limited or not. Another problem is if the script should include or not those lines. But here also, we could create a list of args, some would be tagged as having a default value, which would be used if no command line option is given, while other args would have no default, meaning that the linker line would only be inserted if the corresponding value are set at command line. If that case, it might be better to combine Origin and Length into a unique argument -WEFlashHexValueOfOrigin-HexValueOfLength where HexValueOfOrigin and HexValueOfLength would both bereplaced by the valid values in order to avoid having only Origin and no Length for Flash (or Ram, or anything else that would be needed). Maybe a special 'custom' controller type would be handy for this... Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] MIPS
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd
Envoyé : vendredi 1 juillet 2011 08:21
À : fpc-devel@lists.freepascal.org
Objet : Re: [fpc-devel] MIPS
Pierre Free Pascal wrote:
I had a MIS related question:
using fullcycle I got a warinng about
defdynlinker not being initialized fro mips in systems/t_linux.pas unit.
Is this a correct fix,
Index: t_linux.pas
===
--- t_linux.pas (révision 17859)
+++ t_linux.pas (copie de travail)
@@ -192,6 +192,9 @@
{$endif FPC_ARMEL}
{$endif arm}
+{$ifdef mips}
+ defdynlinker:='/lib/ld-linux.so';
+{$endif mips}
{
Search order:
glibc 2.1+
or can somoeone tell us what the default linker is for a mips linux
machine?
Pierre Muller
On Debian Squeeze mipsel (using Marco's suggestion):
$ ldd `which gcc`
libc.so.6 = /lib/libc.so.6 (0x2aab)
/lib/ld.so.1 (0x)
So I added /lib/ld.so.1 as default dynamic linker for now to trunk.
Pierre
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] MIPS
I had a MIS related question:
using fullcycle I got a warinng about
defdynlinker not being initialized fro mips in systems/t_linux.pas unit.
Is this a correct fix,
Index: t_linux.pas
===
--- t_linux.pas (révision 17859)
+++ t_linux.pas (copie de travail)
@@ -192,6 +192,9 @@
{$endif FPC_ARMEL}
{$endif arm}
+{$ifdef mips}
+ defdynlinker:='/lib/ld-linux.so';
+{$endif mips}
{
Search order:
glibc 2.1+
or can somoeone tell us what the default linker is for a mips linux
machine?
Pierre Muller
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd
Envoyé : jeudi 30 juin 2011 14:40
À : fpc-devel@lists.freepascal.org
Objet : Re: [fpc-devel] MIPS
Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:
Current situation is that after ensuring the existence of dummy files
I've stepped back from the RTL code and am looking at a problem that
appears to be caused by floating point initialisation in the cross
compiler.
A define incorrectly suggested that MIPS was using MM registers. Now
back following missing files/symlinks in the RTL.
http://wiki.lazarus.freepascal.org/Native_MIPS_Systems#Stall_point
wrt the missing of STAT.inc, IIRC the stat record definition on linux
was
found to be slightly architecture dependant (x86 being a bit different
due
to legacy reasons, of both FPC and Linux).
Probably the wisest is to take the PPC one and check it quickly against
the
header.
Thanks, I'm already using ppc for comparison purposes which is why I had
a hard time finding the MM issue :-)
Question if I may: should I be avoiding symlinks as non-portable?
I'm gradually hacking through with a mixture of command-line compilation
and using Lazarus to step through. I considered looking at FPP to see if
I could log all procedure calls, I thought I was looking for something
that hadn't been initialised properly.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or
colleagues]
___
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] gdb and stopping at the begin line
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Martin Envoyé : vendredi 3 juin 2011 01:03 À : FPC developers' list Objet : [fpc-devel] gdb and stopping at the begin line Having just reported http://bugs.freepascal.org/view.php?id=19466 I started wondering (to late, should have done before the report) and googled. It appears that gdb has a feature to skip function prologue and epilogue. However I could not find any info on what info gdb uses to know what is the prologue. Yes, there is code inside GDB that analyses the start instructions to skip the first instructions if GDB recognizes a prologue What GDB recognizes as a prologue can be rather complicated, it of course depends on CPU (as it is sometimes based on assembly instruction analysis), but DWARF might provide other info for debuggers... (I still know about nothing about DWARF :( ) So it is possible that something tells gdb that the code on which no stop occurs is the proluge. does FPC declare this proluge in some form? Not for stabs debugging information, for DWARF I don't really know... I do remember that I had problems once with methods that called other methods on i386: the method call started by an ESI register push (push of SELF value) which was interpreted by GDB as being part of the register local saves an integrated into the prologue part. This was then further complicated by the fact that all the remaining assembler code until the next line information was also skipped, leading to a breakpoint that was put past the first method call... Prologue of main is a special case for which GDB tries to find and skip a possible call to C __main function, this might lead to GDB skipping the call to the code that loads all startup code of all used units. (But again, I am not sure this is true for all version of GDB nor all version of Free Pascal or cpu/os pairs...) Pierre Muller Free Pascal core member (not very active lately :() and pascal language maintainer for GDB. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] test suite, problem with missing libraries on the target
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Bernd Mueller Envoyé : lundi 30 mai 2011 11:38 À : FPC developers' list Objet : Re: [fpc-devel] test suite, problem with missing libraries on the target Jonas Maebe wrote: On 30 May 2011, at 11:19, Bernd Mueller wrote: Jonas Maebe wrote: Why do you limit it to Linux targets? I am not sure about the other targets. LibraryFileName:= 'lib' + ForceExtension(SplitFileName(PPFile[current]), 'so'); The above code builds the library name out of the test program name. For example Test1.pp becomes libTest1.so. This cannot be right for a Windows target for example. Windows is not supported as a remote target, but it's indeed not correct for all unix targets either. The prefix of a library is always lib on all targets, afaik. The suffix is available via dynlibs.SharedSuffix. The downside of using the dynlibs unit is that it makes the dotest program dependent on libdl (and hence libc) on Linux-targets. I'm not sure about how to best solve this... One could work with a default suffix .so and make this overridable by a new test option for example TEST_LIBRARY_SUFFIX. Just add a LibExt constant to dotest.pp source with the same conditionals as for ExeExt, this should be enough. Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] FPC for Sanos (a minimal Win-32)
I looked a little on the API declared by Sanos and I think that it would probably be easier to use our Unix targets to get a reasonable support for this OS rather than trying to use the Win32 subset. The C API seems to be far more extended than the small Win32 emulation layer. Otherwise you will really need to strip the RTL down a lot: Do not rely on exported function in DLL's looking into sources, you will discover that lots are only pseudo implementations doing nothing. See for instance SetConsoleCtrlHandler implementation in: http://www.jbox.dk/sanos/source/win32/kernel32/kernel32.c.html SetConsoleCtrlHandler is the central function used inside Windows RTL to support exceptions on that target... Using signals.pp unit might help for this particular problem as thread specific exceptions with thread information block seems to be supported (but I didn't test it). Pierre -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd Envoyé : jeudi 24 mars 2011 11:27 À : fpc-devel@lists.freepascal.org Objet : [fpc-devel] FPC for minimal Win-32 I'm currently looking at the potential of a minimal Win32-compatible OS called Sanos, which supposedly implements a useful subset of the Windows console-mode API. As a starting point, I'm using the standard Windows variant of the FPC compiler, but if I build a minimal program (i.e. program test0; begin end.) the executable requires the oleaut32 DLL which is not implemented. Is there an easy way to break this requirement, or do I need to hack and rebuild FPC? If the latter is feasible, could somebody give me a hint where to start? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ 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] FPC for Sanos (a minimal Win-32)
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Sven Barth Envoyé : vendredi 25 mars 2011 11:23 À : fpc-devel@lists.freepascal.org Objet : Re: [fpc-devel] FPC for Sanos (a minimal Win-32) Am 25.03.2011 10:51, schrieb Pierre Free Pascal: SetConsoleCtrlHandler is the central function used inside Windows RTL to support exceptions on that target... Using signals.pp unit might help for this particular problem as thread specific exceptions with thread information block seems to be supported (but I didn't test it). Correct me if I'm wrong, but isn't the central function for this SetUnhandledExceptionFilter? Whoops, you are right, I made a confusion... But looking at the implementation of that one also seems to be an almost empty implementation: It sets topexcptfilter variable and return previous value, but that variable isn't used anywhere... Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Building Linux RTL from win32
I tried it on my trunk checkout and got no problems. Did you try with -n option to avoid reading your default fpc.cfg configuration file? make OS_TARGET=linux OPT=-n Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Alex Shishkin Envoyé : lundi 24 janvier 2011 19:34 À : FPC developers' list Objet : [fpc-devel] Building Linux RTL from win32 When I tried to compile linux RTL from win32 (2.5.1.trunk) I got error: D:\src\fpc\rtlmake OS_TARGET=linux make -C linux all make[1]: Entering directory `D:/src/fpc/rtl/linux' d:/pp/bin/i386-win32/ppc386.exe -Tlinux -XPi386-linux- -Xr -Fi../inc -Fi../i386 -Fi../unix -Fii386 -FE. -FU../../rtl/units/i386-linux -di386 si_prc.pp Free Pascal Compiler version 2.5.1 [2011/01/24] for i386 Copyright (c) 1993-2010 by Florian Klaempfl Target OS: Linux for i386 Compiling si_prc.pp Fatal: Can't find unit objpas used by si_prc Fatal: Compilation aborted make[1]: *** [si_prc.ppu] Error 1 make[1]: Leaving directory `D:/src/fpc/rtl/linux' make: *** [linux_all] Error 2 Something wrong with makefiles or I'm doing something wrong? ___ 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] difference between stabs and dwarf for var param
I even had to revert a patch inside GDB about this issue, see: http://sourceware.org/ml/gdb-patches/2010-11/msg00084.html after my accepted patch: http://sourceware.org/ml/gdb-patches/2010-05/msg00258.html It seems that DW_AT_variable_parameter is an informational attribute only, and as such should only be used for display, but the fact that it is a parameter that is passed by reference should still be mentioned. If we issue both, then we should probably, inside the pascal expression reader, hide the reference, so that the output is the same as for stabs. Pierre Muller as pascal language maintainer of GDB. -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Jonas Maebe Envoyé : jeudi 9 décembre 2010 17:59 À : FPC developers' list Objet : Re: [fpc-devel] difference between stabs and dwarf for var param On 09 Dec 2010, at 17:40, Martin wrote: I understand that a var param is passed by ref (internally), but if Stabs can tell the debugger, to hide this, then shouldn't dwarf be able to do that too? Or is dwarf showing the internal pointer intentionally? GDB does not yet support the concept of var parameters in DWARF, so we currently encode them as C++-style reference parameters. 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] parentfp changed to $parentfp
I added this pseudo-name a looong time ago (lowercased as opposed to all uppercased regular variables, at least at the start of Free Pascal debugging capabilities...) Its main purpose is to allow the Text mode IDE (but I assume that this is also true for Lazarus) to find the variables of an outer function/procedure when the debugger is in an internal (function local) frame. So, in a given sense, it is a non-programmer visible symbol, but to add a dollar in front of it might lead to problems within GDB as GDB uses the dollar sign for its own internal variables i.e. history or user defined variables or special variables like $_exitcode $_siginfo for signal information on Unix-like OS's or $_tlb for thead local base on windows OS's Thus, adding a dollar sign in front seems like a bad idea to me. Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Marc Weustink Envoyé : jeudi 9 décembre 2010 00:41 À : FPC developers' list Objet : Re: [fpc-devel] parentfp changed to $parentfp On 8-12-2010 22:53, Jonas Maebe wrote: On 08 Dec 2010, at 22:32, Martin wrote: It seems that the name of parentfp (used by neted procedures) depends on the dwarf version? -gs and -gw = parentfp -gw3 = $parentfp Is there are reason, does the $ have a meaning? It's a bug in -gw3. $ is an internal compiler convention for non- programmer visible symbol. isn't parentfp a non-programmer visible symbol ? Marc ___ 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] win64 dwarf patch
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Willibald Krenn Envoyé : Wednesday, October 13, 2010 2:54 AM À : FPC developers' list Objet : Re: [fpc-devel] win64 dwarf patch Am 13.10.2010 01:40, schrieb Willibald Krenn: Hi, After adding 'tf_dwarf_only_local_labels' to the Hi Willi, I tested and committed this change as rev 16151 in trunk, thanks for this! flags in i_win.pas (line 105) dwarf2 seems to be working. (Even without -WB0040). Additional remark: The -WB option is still needed, otherwise, e.g., 'disas' is not working correctly in gdb. What version of the win64 GDB are you using? I am using a recently generated from GDB cvs HEAD and I get this: C:\cygwin\home\pierre\pas\trunk\fpcsrc\compilergdb64 ./ppcx64.exe GNU gdb (GDB) 7.2.50.20100928-cvs Copyright (C) 2010 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 x86_64-w64-mingw32. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from C:\cygwin\home\pierre\pas\trunk\fpcsrc\compiler/./ppcx64.ex e...done. (gdb) inf fun err All functions matching regular expression err: File system.pp: procedure fpc_abstracterrorintern; (gdb) disas main Dump of assembler code for function main: 0x00011850 +0: push %rbp 0x00011851 +1: mov%rsp,%rbp 0x00011854 +4: sub$0x40,%rsp 0x00011858 +8: callq 0x1af60 fpc_initializeunits 0x0001185d +13:mov0x1cd8cc(%rip),%rax# 0x1001cf130 TC_SYSTEM_EXITPROC 0x00011864 +20:mov%rax,0x23d795(%rip)# 0x10023f000 U_P$PP_OLDEXIT Note that I didn't use the -WB option, so that the default 0x1 is used, but this doesn't seem to generate disassembly problems. Thanks again for the 'tf_dwarf_only_local_labels' fix. Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] win64 dwarf patch
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Willibald Krenn
Envoyé : Wednesday, October 13, 2010 11:53 PM
À : fpc-devel@lists.freepascal.org
Objet : Re: [fpc-devel] win64 dwarf patch
Am 13.10.2010 21:34, schrieb Willibald Krenn:
Yes, your output seems to be fine! I'll try upgrading my gdb to a
newer
version - hope this helps. If this is working, then I think we should
switch to DWARF2 on Win64 and close all related bugs in mantis. ;-)
I upgraded my version of gdb and that fixed the problem. Small
disadvantage, though: DWARF debug info disables smart linking :-(.
Anyway, while fpc and gdb are working now, Lazarus fails to pick up the
correct address if it is outside of the 32 bit range:
info address FPC_RAISEEXCEPTION
info address FPC_RAISEEXCEPTION\n
~Symbol \FPC_RAISEEXCEPTION\ is at 0x18a30 in a file compiled
without debugging.\n
^done
(gdb)
-break-insert *35376
^done,bkpt={number=2,type=breakpoint,disp=keep,enabled=y,addr=
0x8a30,at=,times=0,original-location=*35376}
(gdb)
This seems like a Lazarus specific problem,
the address is certainly cropped to 32-bit somewhere...
I am sorry, but I know almost nothing about
Lazarus source code, so you will need to find someone else
to fix this.
An interesting piece of information
would be to know if x86_64-linux is working
without this limitation.
Pierre
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] x86_64 stabs info - patch (sort of)
Notice: This fix is absolutely necessary if you are working with Lazarus on Win64, as Lazarus automatically sets a breakpoint in fpc_raise... which then crashes gdb, which in turn crashes any running debugging session - in case an exception is raised. Of course it affects also all methods/funs that take e.g. three params that can be passed in regs... Perhaps someone with more knowledge of stabs and the x86reg.dat can do a proper fix? TIA! Afaik, stabs does not support x86-64 that's why it's probably never fixed/noticed. This is not true: I src/gdb/amd64-tdep.c you can see this (line 2419 on current CVS): /* The default register numbering scheme for AMD64 is referred to as the DWARF Register Number Mapping in the System V psABI. The preferred debugging format for all known AMD64 targets is actually DWARF2, and GCC doesn't seem to support DWARF (that is DWARF-1), but we provide the same mapping just in case. This mapping is also used for stabs, which GCC does support. */ set_gdbarch_stab_reg_to_regnum (gdbarch, amd64_dwarf_reg_to_regnum); set_gdbarch_dwarf2_reg_to_regnum (gdbarch, amd64_dwarf_reg_to_regnum); This means that indeed stabs and dwarf register number are equal, at least for GDB. The problem is that this means that we probably also need to distinguish between stabs32 and stabs64, as we already do for dwarf32 and dwarf64... unless we change the code that reads x86reg.dat to use dwarf64 indexes for amd64 stabs registers. Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] x86_64 stabs info - patch (sort of)
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Jonas Maebe Envoyé : Tuesday, October 12, 2010 10:51 AM À : FPC developers' list Objet : Re: [fpc-devel] x86_64 stabs info - patch (sort of) On 12 Oct 2010, at 10:25, Pierre Free Pascal wrote: This means that indeed stabs and dwarf register number are equal, at least for GDB. The problem is that this means that we probably also need to distinguish between stabs32 and stabs64, as we already do for dwarf32 and dwarf64... There is no stabs64 format, afaik. See http://sourceware.org/bugzilla/show_bug.cgi?id=9327 I think that dwarf32 and dwarf64 here only refers to i386 32-bit registers versus amd64 64-bit registers. It is in that meaning that I said that we should use the dwarf64 column of x86reg.dat to implement the stabs register number for x86_64 CPU. Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] x86_64 stabs info - patch (sort of)
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Jonas Maebe Envoyé : Tuesday, October 12, 2010 10:00 AM À : FPC developers' list Objet : Re: [fpc-devel] x86_64 stabs info - patch (sort of) On 12 Oct 2010, at 09:25, Florian Klaempfl wrote: Afaik, stabs does not support x86-64 that's why it's probably never fixed/noticed. The problem is that for some reason, it's nevertheless the default for Win64. It currently is because dwarf debug information generation for x86_64 is still much more buggy than stabs generation. Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] x86_64 stabs info - patch (sort of)
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Jonas Maebe Envoyé : Tuesday, October 12, 2010 11:56 AM À : FPC developers' list Objet : Re: [fpc-devel] x86_64 stabs info - patch (sort of) On 12 Oct 2010, at 11:49, Pierre Free Pascal wrote: -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Jonas Maebe Envoyé : Tuesday, October 12, 2010 10:00 AM À : FPC developers' list Objet : Re: [fpc-devel] x86_64 stabs info - patch (sort of) On 12 Oct 2010, at 09:25, Florian Klaempfl wrote: Afaik, stabs does not support x86-64 that's why it's probably never fixed/noticed. The problem is that for some reason, it's nevertheless the default for Win64. It currently is because dwarf debug information generation for x86_64 is still much more buggy than stabs generation. Is it? I use it all the time on Mac OS X/x86-64 and Linux/x86-64, and it works fine. It might be specific to win64, especially the internal linker. I only tested win64 target, the others might be OK. Note that a recent fix by Willibald Krenn might have improved things a lot, but I didn't have much time to check it out yet. Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] x86_64 stabs info - patch (sort of)
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Jonas Maebe Envoyé : Tuesday, October 12, 2010 10:51 AM À : FPC developers' list Objet : Re: [fpc-devel] x86_64 stabs info - patch (sort of) On 12 Oct 2010, at 10:25, Pierre Free Pascal wrote: This means that indeed stabs and dwarf register number are equal, at least for GDB. The problem is that this means that we probably also need to distinguish between stabs32 and stabs64, as we already do for dwarf32 and dwarf64... There is no stabs64 format, afaik. See http://sourceware.org/bugzilla/show_bug.cgi?id=9327 This is also not totally true: I heard recently that Apple has a 64-bit extension of the stabs debug format in bfd/mach-o.c:bfd_mach_o_read_symtab_symbol and gdb/machoread.c:macho_symtab_read (this doesn't use dbxread.c) Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] internal error #200602251
Thank you so much! It's been a while that I was trying to understand why stabs generation was messed up for win64 target. Your suggestion is correct, I was able to complete a cycle with DEBUG=1 using internal object writer and linker and get correct stabs information. I will test a complete 'make clean all FPC=ppcx64 DEBUG=1' at fpcsrc level and check in the fix if it completes successfully. Thanks again. Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Willibald Krenn Envoyé : Tuesday, September 28, 2010 1:28 AM À : FPC developers' list Objet : Re: [fpc-devel] internal error #200602251 Proposed fix now in mantis, #0017500. Turns out RELOC_ABSOLUTE32 seems to work, I had forgotten to do a proper clean before checking.. :-\ Cheers, Willi ___ 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] internal error #200602251
The complete compilation worked. Patch committed in rev 16056 in trunk. Thanks again! Pierre -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Pierre Free Pascal Envoyé : Tuesday, September 28, 2010 11:40 AM À : 'FPC developers' list' Objet : RE: [fpc-devel] internal error #200602251 Thank you so much! It's been a while that I was trying to understand why stabs generation was messed up for win64 target. Your suggestion is correct, I was able to complete a cycle with DEBUG=1 using internal object writer and linker and get correct stabs information. I will test a complete 'make clean all FPC=ppcx64 DEBUG=1' at fpcsrc level and check in the fix if it completes successfully. Thanks again. Pierre Muller -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Willibald Krenn Envoyé : Tuesday, September 28, 2010 1:28 AM À : FPC developers' list Objet : Re: [fpc-devel] internal error #200602251 Proposed fix now in mantis, #0017500. Turns out RELOC_ABSOLUTE32 seems to work, I had forgotten to do a proper clean before checking.. :-\ Cheers, Willi ___ 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Beta Dos 2.2.0a downloadable
I will send an email when the files are ready. The beta testing files for Dos 2.2.0a are downloadable from ftp://ftp.freepascal.org/fpc/beta/2.2.0a/go32v2 Please report any problems encountered during installation or use of this beta. Pierre Muller Content of README file: This directory will be used to test the modifications inserted to the 2.2.0 sources in order to be able to generate a valid Dos distribution. The sources are in the svn repository under the branch fixes_2_2_0_dos. Due to some instabilities with the dos executables created with default settings, this test version was compiled with OPT set to -gl -O- -dDEBUG, together with UPXPROG set to echo. This leads to the generations of programs that have debugging information included (which are of course much bigger in size), the setting of UPXPROG to echo prevents copression by upx which would otherwise also lead to the removal of debugging information. As indicated by the BETA subdirectory, this is NOT a release, but just a test version, that will be overwritten in case some problems are detected and fixed while testing. Feedback on problems when trying to install the beta distribution should go to fpc-devel mailing list. If you want to try to install this distribution onto a Dos machine without LFN support, you should try to download the files in shortsep subdirectory. If you want to install the beta distribution on a system that supports LFN, please use the files in separate subdirectory. A very helpful test would be to try to completely rebuild the distribution from the sources provided. Try to unzip all sources, and launch a 'make build OPT=-gl -O- -dDEBUG' at source level. Pierre Muller 2007/10/01 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Beta Dos testers for 2.2.0a wanted
-Original Message- From: Robert Riebisch [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 12:41 PM To: fpc-devel@lists.freepascal.org Cc: [EMAIL PROTECTED] Subject: Re: [fpc-devel] Beta Dos testers for 2.2.0a wanted Pierre Muller wrote: There are several reasons for this, but I am started a small branch that tries to get the minimal changes to get a usable Dos release. Sounds great! My pre-releases (w/o no-LFN fix) are at http://www.bttr-software.de/misc/fpc/. The other more subtle problem seems to be related to problems in the IDE while debugging when compiling with optimizations set to -O2. Please explain these problems! It seems that the IDE compiled without special OPT setting is not stable when you debug a program, but I did not have time to investigate this. Another problem was that the install.dat file, used by the installer, was out of sync with the current sources at release date. As this file is only used for I didn't noticed that before albeit I used the installer several times. What was wrong? It is only for some zip files that have a different name in the install.dat files than the name of the file created by 'make go32v2zip' for instance. It does not affect the required files. I uploaded to ftp.freepascal.org under ftp://ftp.freepascal.org/pub/fpc/beta/2.2.0a/go32v2 separate zip files, with install.exe and install.dat files. I get Permission denied. :-( I tried to upload them to test myself and realized that the change that I made in the fpcmake was incorrect and led to wrong zip files (containing the wrong files or with the wrong directory structure). This is explained in the README at beta/2.2.0a/go32v2 level. As soon as I get a correct upload, I will reopen these directories. I would like to get feedback on the stability of the IDE (especially while debugging executables). IIRC I got internal error 291 (or 219) every time, when I set a breakpoint in a unit and started the main program. Using the IDE with debug info included, you should be able to get a backtrace in such cases. If people are willing to help, it would be great to have persons that would try to do a complete rebuilding of the beta dist of their Dos system. Beware that you will need quite a lot of free disk space for that... I could to that. Thanks, Robert! I will send an email when the files are ready. Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Re: FPC 2.2 HTML docs issues
I once wrong a sed script that was fixing the wrong links after tex4ht was called. I don't know if Michael committed this into the fpcdocs svn repository, but he can probably comment on that? Pierre Muller -Original Message- From: [EMAIL PROTECTED] [mailto:fpc-devel- [EMAIL PROTECTED] On Behalf Of Karl-Michael Schindler Sent: Wednesday, September 26, 2007 12:23 AM To: FPC developers' list Subject: Re: [fpc-devel] Re: FPC 2.2 HTML docs issues Hi, I had another go testing different versions of tex4ht. All of them except one (the one I used originally and fairly old one) produced wrong links. At least the sequence of make (ps, pdf, html ,...) can be excluded as source of the problem. Maybe the logs and protocols give a hint to where the problem is. Best wishes - Michael Schindler ___ 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
