from:"Joost van der Sluis"

[fpc-devel] jsonrpc - does it still work?

2023-11-24 Thread Joost van der Sluis via fpc-devel

Hi all,

I'm playing with json-rpc but can't get it to work.

I've tried the examples in fcl-web/examles/jsonrpc. I couldn't follow
the readme as there are no lpi-files, so that the rttirpc.lpg does not
work. But also this fails:

[joost@fed4k rtti]$ ppcx64 demorpcrtti.lpr 
Free Pascal Compiler version 3.3.1 [2023/11/23] for x86_64
Copyright (c) 1993-2023 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling demorpcrtti.lpr
Compiling resource demorpcrtti.or
Linking demorpcrtti
demorpcrtti.lpr(32,1) Warning: "crtbegin.o" not found, this will
probably cause a linking failure
demorpcrtti.lpr(32,1) Warning: "crtend.o" not found, this will probably
cause a linking failure
33 lines compiled, 0.2 sec, 1304576 bytes code, 623944 bytes data
2 warning(s) issued

[joost@fed4k rtti]$ ppcx64 rpcclient.lpr 
Free Pascal Compiler version 3.3.1 [2023/11/23] for x86_64
Copyright (c) 1993-2023 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling rpcclient.lpr
Linking rpcclient
88 lines compiled, 0.2 sec, 1166496 bytes code, 527936 bytes data

[joost@fed4k rtti]$ ./demorpcrtti &
[1] 2913859

[joost@fed4k rtti]$ ./rpcclient 
= Testing SayHello
An unhandled exception occurred at $7F96D7E6A010:
EAccessViolation: Access violation
  $7F96D7E6A010
  $00401A06

It fails at 'client.SayHello'. The invoke-logic is never called.

Maybe I miss a compiler-directive?

Regards,

Joost
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Smart-linking on linux/x86-64

2022-07-09 Thread Joost van der Sluis via fpc-devel


Op 05-07-2022 om 23:45 schreef Sven Barth via fpc-devel:
Joost van der Sluis via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> schrieb am Di., 5. Juli 2022, 
22:37:


I think many people would be glad if you'd solve the issue of smart 
linking with debug information when an external linker is used. :)


That's easy. See the attachment (Linux only). The results are similar as 
gcc produces. Apparently ld does not regard references in debug-sections 
as real references, and replaces them with 0-addresses. Just like our 
internal linker on Windows does.


I don't dare to push it, though. Because:

1: Someone disabled this because some older version of LD cannot handle 
it. Maybe some version we use still use on some targets/systems?


2: Someone disabled this because of some corner-case we now don't know 
of anymore.


Does anyone have some more information?

Regards,

Joostdiff --git a/compiler/options.pas b/compiler/options.pas
index 75d7f6f255..64022a722b 100644
--- a/compiler/options.pas
+++ b/compiler/options.pas
@@ -3870,7 +3870,7 @@ procedure TOption.checkoptionscompatibility;
 {$endif i8086_link_intern_debuginfo}
 
   if (paratargetdbg in [dbg_dwarf2,dbg_dwarf3]) and
- not(target_info.system in (systems_darwin+[system_i8086_msdos,system_i8086_embedded])) then
+ not(target_info.system in (systems_darwin+systems_linux+[system_i8086_msdos,system_i8086_embedded])) then
 begin
   { smartlink creation does not yet work with DWARF
 debug info on most targets, but it works in internal assembler }

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Smart-linking on linux/x86-64

2022-07-07 Thread Joost van der Sluis via fpc-devel





Op 05-07-2022 om 11:51 schreef Sergei Gorelkin via fpc-devel:

05/07/2022 09:39, Sven Barth via fpc-devel wrote:
Joost van der Sluis via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> schrieb am Di., 5. Juli 2022, 
00:17:
The problem is that *something* would need to reference the debug 
sections otherwise they are stripped as well. But as soon as they're 
referenced whatever code or data *they* reference is kept as well.
One of the better solutions might be to write these references as weak 
symbols (on systems that support this) so at least the data/function 
isn't kept around.
Or the section of the data/function would have to contain a reference 
to its corresponding debug entry so that it is kept around as long as 
the function/data is kept around...

How does GCC do this?



As far as I had studied this issue, ld essentially "decompiles" the 
monolithic FDE's from object files into internal representation, and 
then "compiles" it back, omitting information for the code that won't go 
into executable due to smartlinking. It also optimizes for size by using 
8- and 16-bit offsets instead of 32-bit ones when possible.


Indeed, that is also what I have seen. ld Adapts the cfi-contents. (It 
also removed some mistakes in fpc's implementation)


Regards,

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Smart-linking on linux/x86-64

2022-07-05 Thread Joost van der Sluis via fpc-devel






Op 05-07-2022 om 08:39 schreef Sven Barth via fpc-devel:
Joost van der Sluis via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> schrieb am Di., 5. Juli 2022, 
00:17:

Any suggestions? Is it possible to place every fde in it's own section
to solve this?


The problem is that *something* would need to reference the debug 
sections otherwise they are stripped as well. But as soon as they're 
referenced whatever code or data *they* reference is kept as well.
One of the better solutions might be to write these references as weak 
symbols (on systems that support this) so at least the data/function 
isn't kept around.
Or the section of the data/function would have to contain a reference to 
its corresponding debug entry so that it is kept around as long as the 
function/data is kept around...

How does GCC do this?


Apperently GCC does the exact same thing as fpc does on Windows. Replace 
the addresses with 0, and mixup the function-names.


(The link between the CFI and actual code consists of local labels. They 
do not reference the global labels/sections. I guess that is why the 
code is removed, as it's global label is not referenced)


I can adapt fpc so that it does the same on Linux also. So I think I'll 
leave it this way.


Thanks for the help.

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Smart-linking on linux/x86-64

2022-07-04 Thread Joost van der Sluis via fpc-devel




Op 04-07-2022 om 23:37 schreef Sven Barth via fpc-devel:

Am 04.07.2022 um 19:52 schrieb Joost van der Sluis via fpc-devel:

Hi all,

I have a very small application, see below. One procedure is not 
called at all.


But when I compile with

ppcx64 -XX -CX testcfi.pp

The P$TESTCFI_$$_NEVERCALLES symbol is still in the executable.

On Windows (internal linker) this code is omitted from the executable, 
but not on Linux.


Does anyone know why?


I can't reproduce this with main. But considering that you named the 
test file “testcfi”: do you by chance play around with DWARF data? Cause 
DWARF doesn't support smartlinking on non-Windows, at least not in the 
way FPC generates it...


After your and Michael's response, I've tried it again and I can't 
reproduce it anymore either...


I'm still wondering what I did wrong.

But my real issue is this: on Windows, using the internal linker, this 
procedure is also omitted *with* Dwarf debug-data. As you implied.


The problem is, though, that the CFI-information (the FDE) is not 
omitted. This is 'solved' in the internal linker by replacing the 
address with 0. Gdb doesn't mind and I've adapted FpDebug so that it 
allows this too, but this is still invalid, imho.


But as the FDE is written now, as 'one block', without any sections, I 
don't see how the linker could omit the corresponding FDE.


Any suggestions? Is it possible to place every fde in it's own section 
to solve this?


Regards,

Joost.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TInetSocket connect timeout

2022-06-09 Thread Joost van der Sluis via fpc-devel


Op 08-06-2022 om 22:54 schreef Dimitrios Chr. Ioannidis via fpc-devel:
   the TInetSocket ConnectTimeout cannot be smaller than 1 second. The 
reason is that the TInetSocket's CheckSocketConnectTimeout function has 
the microseconds field (tv_usec) of locTimeVal (PTimeVal) variable 
always zero .


   I created a PR ( 
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/239 ) to 
fix this.


Thanks, I've merged it.

Regards,

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] CFI

2022-06-07 Thread Joost van der Sluis via fpc-devel



Op 07-06-2022 om 14:07 schreef Jonas Maebe via fpc-devel:

On 2022-06-07 11:09, Joost van der Sluis via fpc-devel wrote:


This is a snippet of the information that the compiler typically
generates: (x86_64-linux)

fde:
<    0><0x00401090:0x004010c1>
    0x00401090:  
    0x00401091:   r16=-8(cfa) >

    0x004010c0:  

This basically means that when the instruction-pointer is at
0x00401090, the CFA (frame) can be obtained by taking register 7 (rsp)
and add 8 to it.
The return address (called r16 here) if obtained by taking the CFA,
substract 8 and then read the value at that memory location.

So far so good. But then I need the next frame. So use the return
address, substract one (To obtain the call address). And start over...
but, the value of r7 is not available anymore.


The CFA (call frame address) is defined as "the value of %rsp at the 
call site in the previous frame" (*). So the value you calculated above 
in the first rule is the value of r7 in the previous frame and the call 
site address.


Thanks, also for the link. Good to know that it is defined officially 
that way.


Regards,

Joost
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] CFI

2022-06-07 Thread Joost van der Sluis via fpc-devel




Hi all,

I'm working on FpDebug to add support for the Call Frame Information 
(CFI) which is part of the Dwarf specification. (Version 2 onwards)


This is a snippet of the information that the compiler typically 
generates: (x86_64-linux)


fde:
<0><0x00401090:0x004010c1> 0>

0x00401090:  
0x00401091:   r16=-8(cfa) >

0x004010c0:  

This basically means that when the instruction-pointer is at 0x00401090, 
the CFA (frame) can be obtained by taking register 7 (rsp) and add 8 to it.
The return address (called r16 here) if obtained by taking the CFA, 
substract 8 and then read the value at that memory location.


So far so good. But then I need the next frame. So use the return 
address, substract one (To obtain the call address). And start over... 
but, the value of r7 is not available anymore.


But it seems like it that GDB has no problem with it.

This is what the Dwarf-5 specs say: (We/FPC always create CFI version 1 
information, which corresponds with Dwarf-2, but the description in 
Dwarf-5 is easier to understand.)


"The default rule for all columns before interpretation of the initial 
instructions is the undefined rule. However, an ABI authoring body or a 
compilation system authoring body may specify an alternate default value 
for any or all columns."


'Undefined' means that the register is not available. So in principle we 
can not unwind the stack more the one level using the CFI provided by 
FreePascal. Unless there is some ABI rule that overrules the value 
of the r7 register.


Does anyone know if this is the case. And what are those ABI rules 
precisely, or should we add a column to the CFI information to describe r7?


Regards,

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] jUnit output for fpcunit

2021-12-29 Thread Joost van der Sluis via fpc-devel



Op 29-12-2021 om 16:05 schreef Michael Van Canneyt via fpc-devel:


On Wed, 29 Dec 2021, Joost van der Sluis via fpc-devel wrote:


I'm trying to run my fpcunit unit-tests on Gitlab, and let Gitlab show 
the results. But it can only handle JUnit-like xml.


Does someone already have something lying around to convert the 
fpcunit format into junit?


Is the FPCUnit format very different from the JUnit one ? Because 
fpcunit is based on junit.


Well, they are similar, but not similar enough.

fpcunit:



  
  
NumberOfFailures="6" NumberOfRunTests="29" NumberOfIgnoredTests="0">
  NumberOfErrors="0" NumberOfFailures="2" NumberOfRunTests="10" 
NumberOfIgnoredTests="0">
ElapsedTime="00:00:00.211"/>

  

  
  FPCUnit Console test runner
  29
  0
  6
  0
  00:00:16.473
  2021-12-29 15:02:48


junit:





 details about failure 



If nothing exists already, I can add it as a format to fpcunit.

Regards,

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] jUnit output for fpcunit

2021-12-29 Thread Joost van der Sluis via fpc-devel


Op 29-12-2021 om 15:35 schreef Florian Klämpfl via fpc-devel:

Am 29.12.2021 um 14:50 schrieb Joost van der Sluis via fpc-devel:
I'm trying to run my fpcunit unit-tests on Gitlab, and let Gitlab show 
the results. But it can only handle JUnit-like xml.


Does someone already have something lying around to convert the 
fpcunit format into junit?




I assume
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/tests/utils/fpts2junit.pp 


is not what you want?


I thought it could only handle the testsuite-output? (not fpcunit)

Regards,

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] jUnit output for fpcunit

2021-12-29 Thread Joost van der Sluis via fpc-devel



Hi all,

I'm trying to run my fpcunit unit-tests on Gitlab, and let Gitlab show 
the results. But it can only handle JUnit-like xml.


Does someone already have something lying around to convert the fpcunit 
format into junit?


Regards,

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] ARM/AARCH64 work

2020-08-07 Thread Joost van der Sluis


Op 07-08-2020 om 08:00 schreef Sven Barth via fpc-devel:


Yes, the fpc.cfg is intended to have absolute paths and its located 
either in the global /etc/fpc.cfg or the user specific ~/.fpc.cfg (where 
~ is your home directory).


When you use the -va parameter, the compiler will show you where it 
looks for it's configuration-files.


Regards,

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Google APIs - Authenticate using a service account?

2020-07-10 Thread Joost van der Sluis


Op 10-07-2020 om 11:02 schreef Michael Van Canneyt:


There is:

 fppkg install cnocOIDC

And you will have JWT support. Have a look at the 
TcnocOIDCIDTokenClaim and TcnocRSAPublicKey/TcnocRSAPrivateKey classes.


Joost,

I am aware of that, but this kind of basic functionality *really* should 
be in the base distribution.


No, googleapi should be removed from the base distribution. That makes 
it also easier to respond on changes and to release them more often. 
However this is in principle also possible with fppkg when they are in 
the base distribution.


Also I don't think that many other languages have JWT support in their 
base distribution.


To copy this into the base-distribution you also have to copy dcpcrypt. 
(MIT) Another solution would be to add a googleapi-plus package (outside 
the base distribution) that depends on both cnocRSA and the googleapi 
package.


I know we disagree on this. But it is really impossible to keep up with 
all the work that needs to be done if we have to convert all useful 
libraries out there into one base distribution.


Regards,

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Google APIs - Authenticate using a service account?

2020-07-10 Thread Joost van der Sluis


Op 30-06-2020 om 09:47 schreef Michael Van Canneyt:


On Fri, 26 Jun 2020, Wayne Sherman via fpc-devel wrote:


Is there support in the fpc google api units for authenticating as a
service account?

Background:
Service accounts allow an application to interact with Google APIs
without authenticating as a specific user.  Instead a service account
is created with it's own credentials, ID, and key.  By authenticating
as a service account, applications can perform tasks on behalf of the
users in a G Suite domain without having to have their login
passwords.


The problem with the service account is that you must create a JWT Token.
FPC does not yet have a unit that can generate *and sign* a JWT Token.


There is:

 fppkg install cnocOIDC

And you will have JWT support. Have a look at the TcnocOIDCIDTokenClaim 
and TcnocRSAPublicKey/TcnocRSAPrivateKey classes.


Regards,

Joost.





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generic method works on Linux, not on Windows?

2020-05-26 Thread Joost van der Sluis


Op 26-05-2020 om 23:36 schreef Yuriy Sydorov:

Does it happen with the fpc trunk?
If yes, what revision do you use? It looks like an issue with my initial 
implementation of the $parentfp parameter optimization. "$fin$0037" 
is a reference to an internal SEH handler procedure which is a special 
nested procedure.


Yes, Trunk, updated last sunday. (And today, didn't help) x86_64


The latest trunk for win32 compiles fine the following modified example:

{$mode objfpc}{$H+}

generic function CreateObjectFromJSONString(AJSONString: string; 
ADescriptionTag: string = ''): T;

begin
   Result := nil;
end;

var
   LaunchRequest: TObject;
begin
   LaunchRequest := specialize CreateObjectFromJSONString('qwe');
end.


It's this project: https://gitlab.freepascal.org/Joost/fpdserver/

And the generic function is defined in:

https://gitlab.freepascal.org/Joost/cerialization

I'll try your code tomorrow. Maybe I can get an easier example.

Regards,

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Generic method works on Linux, not on Windows?

2020-05-26 Thread Joost van der Sluis


Hi all,

I have something strange.

I have a generic function defined as follows:

generic function TJSONRttiStreamClass.CreateObjectFromJSONString(AJSONString: TJSONStringType; ADescriptionTag: string = ''): T;

begin
  Result := nil;
end;

When I call it, like this:

LaunchRequest := FSerializer.specialize 
CreateObjectFromJSONString(ACommandText);


Then I get a compiler-error on Windows, while it works on Linux:

csjsonrttistreamhelper.pas(81,1) Error: Wrong number of parameters 
specified for call to "$fin$0037"


When I make the function empty (Remove Result := nil) it compiles.

Any idea what to look for?

Regards,

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Nasty generics-bug, already known?

2020-04-24 Thread Joost van der Sluis


Hi all, Sven,

I have a very nasty bug related to generics.

Suppose that I have a unit with a generic-class in it. Nothing more. 
This unit is in a package.


Now I also have a unit which is part of an application. Within this unit 
I specialize the generic class of the first unit.


Now, when I change the first unit. The changed code never makes it into 
my application.


(This has probably to do with the interface of the first unit, which 
does not change)


But also when I remove the original first unit, and recompile the 
package, but do not touch the ppu of the application, the changed code 
is not used. (This because the unit that belongs to the application 
already contains the specialized code from the first unit. It does not 
detect a change in the first unit, so nothings happens.)


The question is: is this a known bug?

If not, I can create an example and a more extensive explanation.

Regards,

Joost.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Add your own fpmake packages to the fppkg-repository

2020-04-15 Thread Joost van der Sluis


Hi all,

As you might know there is an online repository with packages which you 
can use with Free Pascal.


It is now possible to add your own packges at https://fppkg.cnoc.nl/.

At the moment the packages which are installed together with Free Pascal 
are availabe, plus some packages I added myself. Like log4fpc (a clone 
of log4delphi), dcpcrypt and some others.


Everyone can log-in with a bug-tracker of forum account. Note that every 
fpc-version has it's own repository. And that there are two flavours: 
testing and production. Everyone can add packages to testing. For now 
adding to production is only possible for administrators.


I've tried to explain how it works over here:
https://fppkg.cnoc.nl/documentation

I'm really curious which packages will appear...

Regards,

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Finally fixed that MOVZX/SX optimisation!

2020-02-18 Thread Joost van der Sluis


Op 18-02-2020 om 23:04 schreef J. Gareth Moreton:
It seems that not all regressions are caught when you run the test suite 
conventionally, and you have to specify additional options like "-O4", 
which may cause other failures to occur if a test is not expecting any 
kind of intense optimisation, for example.  In response, over here at 
https://bugs.freepascal.org/view.php?id=36687, I've introduced two new 
tests that are copies of the ones that failed, but which explicitly add 
-O4 to the default compiler options.


In fact, *all* test should succeed with an option like -O4. So, 
following your approach we have to add copies for all tests, with all 
possible combination of compiler-options. That's undo-able and that is 
why this isn't done.


So when you are working on optimizations, it might be a good idea to run 
the complete test-suite with optimizations enabled (-O4) on your local 
system.


We also realize that it is undo-able to test with all 
optimization-settings, but to make our live easier, there are nightly 
(daily) tests with all sort of options. You can find the results here:


https://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi

For example, the latest x86_64-linux run with -O4:
https://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?run1id=488056==487938=1=Show%2FCompare

Regards,

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] SEH-based exceptions enabled on win32

2020-01-09 Thread Joost van der Sluis


Hi all,

SEH-based exceptions are made the default on the win32 target in 
fpc-trunk. For win64 they already where the default.


To build a compiler without SEH-based exceptions, the dDISABLE_WIN32_SEH 
option should be given. ie:


make all OPT='dDISABLE_WIN32_SEH'

Please report any regressions on the bug-tracker.

Regards,

Joost
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Compiler gives AV during WPO

2019-10-25 Thread Joost van der Sluis


Hi all,

I have some problems with WPO. When the unit in the attached example is 
compiled for the third time, the compiler crashes while writing the 
WPO-information to the ppu.


This is because the a tobjectdef which has been added to the WPO-list 
with classes which are created has been freed.


I am not sure what happens exactly, and I was not able to generate a 
simpler example. But my guess is that there is a method in which an 
instance of the class is created. Then there are no calls to this method 
so the method is removed. (and with this method the it's symtable with 
the type-definition. This is the part that I do not really understand)
The reference to the type is still in the WPO-table, so when it is 
written to file, the system collapses.


The attached patch fixes the problem, but I doubt that the fix is 
correct. (Especially when a class is created in multiple places. My 
patch will remove the classtype from the list with created classes, 
regardless the count.)


Besides that, I just discovered that the patch breaks cycling of the 
compiler. But it is wrong anyway...


Can someone help me out?

Regards,

Joost.
Index: symdef.pas
===
--- symdef.pas	(revision 43306)
+++ symdef.pas	(working copy)
@@ -523,6 +523,7 @@
   function search_enumerator_current: tsym; override;
   { WPO }
   procedure register_created_object_type;override;
+  procedure deregister_created_object_type;
   procedure register_maybe_created_object_type;
   procedure register_created_classref_type;
   procedure register_vmt_call(index:longint);
@@ -7231,6 +7232,7 @@
 
 destructor tobjectdef.destroy;
   begin
+ deregister_created_object_type();
  if assigned(symtable) then
begin
  symtable.free;
@@ -7939,6 +7941,12 @@
   end;
 
 
+procedure tobjectdef.deregister_created_object_type;
+  begin
+current_module.wpoinfo.removecreatedobjtype(self);
+  end;
+
+
 procedure tobjectdef.register_maybe_created_object_type;
   begin
 { if we know it has been created for sure, no need
Index: wpobase.pas
===
--- wpobase.pas	(revision 43306)
+++ wpobase.pas	(working copy)
@@ -168,6 +168,7 @@
 property calledvmtentries: tfphashlist read fcalledvmtentries;
 
 procedure addcreatedobjtype(def: tdef);
+procedure removecreatedobjtype(def: tdef);
 procedure addcreatedobjtypeforclassref(def: tdef);
 procedure addmaybecreatedbyclassref(def: tdef);
 procedure addcalledvmtentry(def: tdef; index: longint);
@@ -412,6 +413,12 @@
 end;
 
 
+  procedure tunitwpoinfobase.removecreatedobjtype(def: tdef);
+begin
+  fcreatedobjtypes.remove(def);
+end;
+
+
   procedure tunitwpoinfobase.addcreatedobjtypeforclassref(def: tdef);
 begin
   fcreatedclassrefobjtypes.add(def);


bug_test.tgz
Description: application/compressed-tar
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] 0036144: Wrong Dwarf2/3/4 info for array (all array, but affects bitpacked) / incorrect use of DW_AT_bit_stride

2019-10-23 Thread Joost van der Sluis


Op 13-10-2019 om 00:22 schreef Martin:
I have a few wishes with regards to: 
https://bugs.freepascal.org/view.php?id=36144


1)
FpDebug detects fpc as dwarf provider, and checks the fpc version. Based 
on this it can interpret the misplaced tags, and work around the issue.
I have now configured 3.3.0 as the cut-off for the workaround (since fpc 
now puts the tags in the correct location).


Should this patch get merged to 3.2 then please alert me of this. So I 
can adjust the check in FpDebug.


About the patch: I made the original change within the period that I 
tried to get multiple-dimensional arrays to be displayed correctly in 
gdb. Especially arrays of ansistrings. In the end this worked, does this 
still work?


We need some kind of debug-tests. I know you have some, and that there 
are huge differences between gdb versions, but still...



2)
"I shot myself in the foot"
Having reported this issue, and it no being fixed, I realized that I 
(ab)used the presence of this issue.


- ShortString are encoded exactly as
record  len: int;   st: array of char;  end;
- And in dwarf 3, ansistring are encoded as array.

With the only difference that they always had the stride in the array, 
and not in the range.


FpDebug used the knowledge of this implementation detail (in the hope 
that it would not change) to detect the diff between a user defined 
record (with the exact same fieldnames), and an actual shortstring.

That no longer works


Well. If someone creates a record called 'ShortString', (s)he should not 
be surprised that the debugger thinks that it is actually a shortstring?


I do not see the issue here. The compiler generates debug-information 
that makes it possible for any debugger to show the data correctly. For 
shortstrings it repors a structure with a length and the actual 
characters. This is what a shortstring is.


That some debuggers, specially made for fpc (like fpdebug, but in some 
regard this holds for gdb too) show a more convenient format, is nice. 
But I think this is not relevant for the compiler.



So I need a new difference, please.


Adding an artificial difference (some sort of implementation-detail) on 
which some debuggers depend, does not seem to be a good idea, imho.



Ideally using DW_TAG_string_type (available since dwarf 2).
I have currently no idea what gdb will do with that.
For FpDebug I will have to implement it, but that is no problem.


DW_TAG_string_type is deliberately not used, as it describes a 
string-type that fpc does not use.


If that is not an option, can we go for a simpler (implementation detail 
(yes again)) workaround (that then goes into trunk, and/or if the 
original fix is merged, can be merged too):
- The stride is optional. If absent it is equal to the element size 
(shortstring = char = byte)

- Arrays always have a stride
- Drop it from the strings array
And I can then detect that.


If the stride is optional, the compiler should always omit it when not 
necessary, to decrease the executable (debuginfo) size. What you ask is 
to add a bug deliberately, which you can use to detect whether something 
is a string or not.


Regards,

Joost.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

2019-03-26 Thread Joost van der Sluis


On 3/25/19 6:24 PM, Bart wrote:

On Mon, Mar 25, 2019 at 1:55 PM Joost van der Sluis  wrote:


That's correct. That's why it should be provided on the command-line.

fpcmkcfg only shows the values of all defined macro's. For example, try
'fpcmkcfg -d foo=jojo -m'.


As an end user howvere I do not even know that such a thing like
BASEPATH can be set at all.
The only way to know is to study the sourcecode (fpccfg.inc).
IMO to should show all macro's it uses, even if it is empty: eg.:
BASEPATH=


Fpcmkcfg can not know what macro's are used in a template? (You can also 
use your own template)


Yeah, it could parse the template. But it's just a simple tool.


LOCALBASEPATH=$LOCAL_APPDATA\FreePascal\fppkg   //odd name for fppkg
specific folder?


It's being used for ages... You mean the 'FreePascal' part?


I meant that LOCALFPPKGBASEPATH  would have made more sense to me.
LOCALBASEPATH to me suggests what BASEPATH seems to be...
(I really hop I make myself clear.)


You mean that it is strange, because in the fpc.cfg template the same 
name is used for the fpc-prefix. While here it is used as fppkg prefix?


Well, in fpc.cfg -> fpc prefix, in fppkg.cfg -> fppkg prefix. I can live 
with that.


Regards,

Joost.


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

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

2019-03-25 Thread Joost van der Sluis


Op 25-03-19 om 14:07 schreef Martok:

I used '-o "%CD%\fpc.cfg"' exactly because fpcmkcfg does not handle relative
paths well.


When you discover things like this, it's better to report it. That way 
you avoid double work for others with the same problem.


Regards,

Joost.

--
http://lazarussupport.com - Your donation helps to push Free Pascal and 
Lazarus forwards.

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

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

2019-03-25 Thread Joost van der Sluis


Op 25-03-19 om 11:48 schreef Bart:

On Mon, Mar 25, 2019 at 10:45 AM Joost van der Sluis  wrote:


To create a working fpc.cfg, you have to provide the %basepath% on the
command-line. (There are a few build-in macro's, you can see them using
'fpcmkcfg -m')


fpcmkcfg -d does not show the existence of a build-in BASPEPATH though.


That's correct. That's why it should be provided on the command-line.

fpcmkcfg only shows the values of all defined macro's. For example, try 
'fpcmkcfg -d foo=jojo -m'.


The built-in macro's are there because they need some sort of logic. 
Like the BUILDDATE and BUILDTIME which will contain the current 
date/time. FPCTARGET the processor fpcmkcfg is compiled for etc.



C:\pp\bin\i386-win32>fpcmkcfg -m
BUILDDATE=25-3-2019
BUILDTIME=11:45:25
COMPILERCONFIGDIR={LocalRepository}config/
FPCBIN=fpc
FPCTARGET=i386
FPCTARGETOS=Win32
FPCVERSION=3.3.1
LOCALBASEPATH=$LOCAL_APPDATA\FreePascal\fppkg   //odd name for fppkg
specific folder?


It's being used for ages... You mean the 'FreePascal' part?

Regards,

Joost.

--
http://lazarussupport.com - Your donation helps to push Free Pascal and 
Lazarus forwards.

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

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

2019-03-25 Thread Joost van der Sluis


Op 24-03-19 om 23:21 schreef Bart:


Extract from fpc.cfg from 3.0.4 (created by offcial installer)
# searchpath for units and other system dependent things
-FuC:\devel\fpc\3.0.4/units/$fpctarget
-FuC:\devel\fpc\3.0.4/units/$fpctarget/*
-FuC:\devel\fpc\3.0.4/units/$fpctarget/rtl

Extract from fpc.cfg from fpc trunk: created with fpcmkcfg.exe (from trunk)
# searchpath for units and other system dependent things
-Fu/units/$fpctarget
-Fu/units/$fpctarget/*
-Fu/units/$fpctarget/rtl


You have to give fpcmkcfg some parameters. The installer does that (or, 
on unices, samplecfg does this for you.)


fpcmkcfg is just a simple template-processor, with a few templates build 
in. For example, you can see the template for fpc.cfg when you run 
fpcmkcfg as follows: 'fpcmkcfg -0 -b'


It contains the following part:

# searchpath for units and other system dependent things
-Fu%basepath%/units/$fpctarget
-Fu%basepath%/units/$fpctarget/*
-Fu%basepath%/units/$fpctarget/rtl

To create a working fpc.cfg, you have to provide the %basepath% on the 
command-line. (There are a few build-in macro's, you can see them using 
'fpcmkcfg -m')


So in your case the command to generate fpc.cfg would be:

fpcmkcfg -0 -d basepath=C:\devel\fpc\3.3.1

Or, what I would do, to be able to support multiple versions with the 
same fpc.cfg:


fpcmkcfg -0 -d basepath=C:\devel\fpc\$fpcversion


Notice all paths are relative (to what?)
How does fpc know that, in relation to fpc.exe this must be translated to:
..\..\units\$fpctarget  ?


No, that won't work. (At least, it is not how it is designed, might 
work, though. Never tested)




Q1: How come? Why does it find C:\pp\units\i386-win32\fcl-db\db.ppu now?
Q2: why did the installer from 3.0.4 use fully qualified paths and
fpcmkcfg does not?


I think that these questions are answered now?


Second problem:

Is this supposed to happen?

C:\pp\bin\i386-win32>dir fpc.cfg
...
24-03-2019  00:31 7.572 fpc.cfg

C:\pp\bin\i386-win32>fpcmkcfg -o fpc.cfg
Saved old "fpc.cfg" to "fpc.bak"
Error: Directory of file "fpc.cfg" does not exists. User -p to force creation.

C:\pp\bin\i386-win32>dir fpc.cfg
...
Directory of C:\pp\bin\i386-win32
File Not Found

It just killed my fpc.cfg!
(Yes there is a backup)

This works however:
fpcmkcfg -o .\fpc.cfg

I would say that fpc.cfg as commandline parameter should point to the
same file as .\fpc.cfg (as it would do in almost any other program).

Q3: is this a bug or "by design"?


ERhm... I can not think of any design that makes this logical. I'm not 
the one who builds and maintains the windows installers, though. So it's 
a bug, I would say.


Regards,

Joost.

--
http://lazarussupport.com - Your donation helps to push Free Pascal and 
Lazarus forwards.

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

Re: [fpc-devel] TRegistry and Unicode

2019-03-02 Thread Joost van der Sluis


Op 01-03-19 om 22:19 schreef Bart:

On Tue, Feb 26, 2019 at 10:49 AM Marco van de Voort
 wrote:


If I look into e.g. registry.pp, the only use of utf8encode there is
like this:

var  s : string;

 u:unicodestring;

s:=utf8encode(u);

which, IF lazarus is used in the default utf8 mode is equivalent to


s:=u;

   So currently this utf8encode only frustrates the situation for people
that don't set the default codepage to utf8?


Exactly.
It also breaks backwards compatibility.
Strings returned were encode in the systems codepage up to 3.0.4, now
thy are not.


The utf8encode should go, just like the utf8decode's that we fixed already.

Regards,

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

Re: [fpc-devel] Fppkg

2019-02-11 Thread Joost van der Sluis


Op 05-02-19 om 21:55 schreef Ben Grasset:
On Mon, Feb 4, 2019 at 9:53 AM Martok > wrote:


the first-ever fppkg.exe invocation on a machine


Do people actually use fppkg for anything? More specifically what is the 
point of integrating it with Lazarus, which already has the OPM?


Good question.

And I have two answers for you:

First: Fppkg has been integrated with Lazarus for over 10 years. It is 
part of FPC from since the nineties. It has never been used really, 
though. It had potential at the start, but it was too hard to get it 
working properly all the time. It was difficult to get it to compile 
Lazarus properly, due to all the strange exceptions in it's 
build-system. Mattias decided not to wait but to build Lazbuild. Making 
fppkg obsolete in some part. The same happened with OPM. Fppkg never 
gained popularity, and nowadays all Lazarus packages are distributed 
through OPM. So it's questionable what the reason of existing of Fppkg 
is at this moment.


Second: Lazbuild and OPM do only a part of what Fppkg/Fpmake are capable 
of. Remember that the FPC-universe does not only consists of Lazarus. 
For Fppkg/Fpmake, Lazarus is just one of the projects. And it is 
possible to compile (bootstrap) Lazarus using Fppkg, so it replaces 
'Make'. Lazbuild can not do this. (In principle it is possible to 
install Lazarus using 'fppkg install lazarus')
I often see discussions about a certain unit, if it should be part of 
Freepascal or Lazarus. Adding it to Fppkg is the solution. We can also 
use Fppkg to solve problems with bugs in Freepascal's packages between 
two fpc releases.
And about the online packages-part of Fppkg, in contradiction to OPM 
Fppkg has different repositories for different version of FPC. And it 
actually checks for packages if they compile before they can be 
submitted. Also when a package changes, all packages that depend on the 
changed package are recompiled (on several targets) to check if the 
compilation breaks. If this is the case, an update will be refused. 
(Well an administrator can override this, but let's keep it simple)
On moving compiler targets (fpc-trunk) the packages are checked for 
regularly.


So I still think it's worthwhile to work on Fppkg. And I'm really 
pleased with all the bug-reports regarding the invalid 
Fppkg-configurations. I hope that solving these issues now will lead to 
more correct fppkg-installations. That way it will be really possible to 
distribute updates of FPC-packages between FPC-releases.


Ok, I've tried to give a short answer, but it is still a lot of text. 
But I hope this will explain a bit of my motivation to work on the system.


Regards,

Joost.

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

Re: [fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures

2018-08-13 Thread Joost van der Sluis


Op 11-08-18 om 10:22 schreef Christo:

In my mind it was easier to think of subarch/abi options as extending the 
target concept, so
each valid combination of CPU-OS-SUBARCH-ABI results in a unique target, which 
ends up in a
separate directory.  This concept seems to fit in well with the current concept 
of target=CPU-OS
and requires minimal changes on both the Makefile side and fpmake side.


As said, i did not really look into your changes. I had Florian's 
directory layout in mind. Maybe this is also an idea. Florian, what do 
you think?



This is a bit different to how Florian started his modifications, which was 
CPU-OS/SUBARCH-ABI.
This created some bifurcation in directory & file name conventions, hence my 
suggested approach
above.

Note that I am not familiar with the details of fpmkunit. I've looked at 
lcl/interfaces and here
it seems as if each variant has its own list of units required.  In this case 
most/all of the
required units stay the same, it is just the used compiled unit paths and 
unit/binary output
path that would differ.  I'm sure I'm missing something about the way 
PackageVariants are
supposed to work.


PackageVariants can do more than you need, that's true. You only have to 
define some additional compiler-parameters, and search-paths, the rest 
will be done automatically.


Regards,

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

Re: [fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures

2018-08-06 Thread Joost van der Sluis


Op 06-08-18 om 07:32 schreef Christo:

* In fpmkunit.pp:
   * add support for new command line options subarch and abi
   * include subarch and abi in MakeTargetString function


I did not have a look at your patch. But this should not be necessary.

Fpmkunit supports Package-Variants. In principle you could add:

  AddPackageVariant('subarch', True);

to your fpmake.pp, and this package and all packages that depend on it 
will use sub-directories for each 'subarch'. To make it work in this 
case might need some work. (Also: it would be ideal to add the subarch 
to the rtl-package, but this one is not compiled using fpmake..._


It would be nice if we could use this mechanism to create the 
directory-structure you want.


An example is the lcl, with the different widgetsets. Have a look at 
lazarus/lcl/interfaces/fpmake.pp.


Regards,

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

Re: [fpc-devel] Exceptions on wiki

2018-08-02 Thread Joost van der Sluis


Op 01-08-18 om 02:32 schreef Kirinn:
Inspired by Gareth aka. Kit's infectious enthusiasm, and the recent long 
discussion on exceptions on this list, I wrote up an article on 
Exceptions on the FPC wiki. (Strangely enough we didn't have one before.)


http://wiki.freepascal.org/Exceptions


We had some discussion about memory-leaks and exceptions. All condensed 
into this bug report: https://bugs.freepascal.org/view.php?id=33650


Maybe something to add?

Regards,

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

Re: [fpc-devel] Test changes in e.g. a package

2018-07-23 Thread Joost van der Sluis




Op 18-07-18 om 13:39 schreef Michael Van Canneyt:



On Wed, 18 Jul 2018, Bart wrote:


Hi,

Sorry if this is a RTFM question.

Whenever I make some changes to the sourcecode of e.g. a package or an
RTL-file, in order to test these changes I do a make clean/make
install in the root directory.
(e.g. I change one line in packages/fcl-registry/src/regini.inc)
This takes several minutes (which especially sucks if I made a typo
which leads to a syntax error).

Is there a faster way to do this?


In general: no.


No?

cd packages/fcl-registry
fppkg install

That's it. It will also re-compile and install all packages that depend 
on fcl-registry.


Use 'fppkg install -o -gl' when you need debug-info.

Your fppkg configuration has to be correct, though. Which is the case 
when you used the fpc-installer.


If it does not work, use 'fppkg listsettings' and check the results.

Regards,

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

Re: [fpc-devel] AVR debug info - bug 0033914

2018-07-02 Thread Joost van der Sluis


Op 30-06-18 om 21:51 schreef Christo:

I'm trying to figure out how to fix bug 33914. This bug causes gdb to read 
variable addresses
from flash, not RAM.  Looking at the DWARF info, the address of a variable is 
written as a word,
while gdb expects a prefixed address ($80 + address) to indicate a RAM 
address, so the size
of the address needs to be larger than 16 bits.  In dbgdwarf.pas it appears as 
if the size of
addresses are taken from pint/puint in globtype.pas and aitconst_ptr_unaligned 
in aasmtai.pas,
all of which are 16 bit sizes for AVR.



Of course all instances pint/puint types and aitconst_ptr_unaligned constants 
are appended with
"_d" as part of this indirection.  A patch with this approach is attached to 
the bug report.



This appears to work correctly, but I'm not sure this is an elegant way of 
fixing the problem.
Any comments or hints on how to fix the issue more elegantly?


Has been a long time ago, but my guess is that in some DWARF-header 
there is an offset for the memory-locations. (The unit-info maybe?)


You should have a look at the Dwarf-specs. And maybe have a look at 
other platforms, what is generated there.


Regards,

Joost.


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

Re: [fpc-devel] Fppkg web-client

2018-05-01 Thread Joost van der Sluis

Hi all,

I've the web-client for managing fppkg-packages in a web client running.
I've added some packages and will add some more in the future.

It is possible to add your own packages if you want to, if you want to
try, please contact me. I'll explain how to do so.

If you want to use the fppkg-repository, edit your fppkg.cfg file, and
set remotemirrors to http://fpc.cnoc.nl/repo/testing/mirrors.xml.

Regards,

Joost.

Op 06-12-17 om 00:06 schreef Joost van der Sluis:

Hi all,

As some of you might know, I'm working for quite some time for something
like a package-manager for fpc.

I'm working on a system on which you can build, test and upload
packages. And which can be used to create the repository.

I'm using all kind of stuff which is new to me, which means that it
progresses slowly, but it's a lot of fun.

The system is using some kind of micro-services-design, with an Angular
client, Identityserver (Open ID Connect) for authentication, nginx to
bind things together, docker to keep things apart and FPC to build some
services.

What I have online now is only a system to test fppkg-packages. You can
find it at http://fpc.cnoc.nl. Log in with 'Alice' and 'Password'. At
the moment you can only test-built packages with it.

If you want to do more, check out the project at:
https://svn.freepascal.org/svn/fpcprojects/fppkgreposerver/trunk

More information can be found here:
https://svn.freepascal.org/cgi-bin/viewvc.cgi/fppkgreposerver/trunk/readme.md?view=markup=fpcprojects

Regards,

Joost.
___
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

[fpc-devel] Fppkg web-client

2017-12-05 Thread Joost van der Sluis


Hi all,

As some of you might know, I'm working for quite some time for something 
like a package-manager for fpc.


I'm working on a system on which you can build, test and upload 
packages. And which can be used to create the repository.


I'm using all kind of stuff which is new to me, which means that it 
progresses slowly, but it's a lot of fun.


The system is using some kind of micro-services-design, with an Angular 
client, Identityserver (Open ID Connect) for authentication, nginx to 
bind things together, docker to keep things apart and FPC to build some 
services.


What I have online now is only a system to test fppkg-packages. You can 
find it at http://fpc.cnoc.nl. Log in with 'Alice' and 'Password'. At 
the moment you can only test-built packages with it.


If you want to do more, check out the project at: 
https://svn.freepascal.org/svn/fpcprojects/fppkgreposerver/trunk


More information can be found here: 
https://svn.freepascal.org/cgi-bin/viewvc.cgi/fppkgreposerver/trunk/readme.md?view=markup=fpcprojects


Regards,

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

Re: [fpc-devel] Last call for 3.0.4 merges

2017-06-19 Thread Joost van der Sluis


Op 19-06-17 om 22:52 schreef Joost van der Sluis:
I'll see if I can make a list with hotfixes. Which will be a pain to 
merge, as the code in which the fixes are done might even not exist 
anymore.


But I think we have to change http into https in a few places...


Ok, please merge:

32732
32759
33016
33017
33033 *
34141
34142
34144
34145
34190
34314
34396
34401 *
34403 *
34486
35277 (If difficult to merge, skip)
35881
36511
36529 *
36550 (brand new, but needed to handle https downloads and redirects)
36551 (idem)
36552 (idem)
36553 (idem)

Marked with * are really important. The last few are just small changes, 
but necessary for the https-change. It could be that they don't merge 
due to earlier changes. In that case, just change 'http' to 'https' and 
'lnet' to 'FPC' manually


Regards,

Joost.

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

Re: [fpc-devel] Last call for 3.0.4 merges

2017-06-18 Thread Joost van der Sluis


Op 18-06-17 om 09:34 schreef Michael Van Canneyt:


Below a really long list. They are patches that happened after tag of 
3.0.2,
so they suppose that all earlier patches to fcl-pdf, fcl-js, pas2js, 
fcl-passrc

have been merged already (which, I think, should be the case).
 
Everything related to fcl-js:


Which reminds me...

We use fcl-passrc to use pascalscript to validate form-input on 
websites. We evaluate the scripts on the server-side, but also direct on 
the client. With a very simple pascalscript to js converter.


But it doesn't work with trunk anymore, at least, it doesn't parse the 
statement 'false;', together with 'true;' anymore. Which is used a lot 
in our system. (For example for the 'required'-statements.)


Is this intentional?

Regards,

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

Re: [fpc-devel] Last call for 3.0.4 merges

2017-06-17 Thread Joost van der Sluis


Op 17-06-17 om 21:31 schreef Marco van de Voort:


While I have not done much the last month, I did keep up with most of the
merging so most requests have been honoured, and I plan to branch mid next
week or even monday if there is not much response.

If I missed some, or there are important new ones, there is still a few days
time, waiting for the win32/64 findfirst fix.


I'm hesitating about merging all fpmkunit and fppkg changes. Things 
improved a lot, but a little bit more testing could be useful. Not that 
it's used a lot, though.


At least it should handle https, since idefix is https only, now.

What do you think?

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

[fpc-devel] FPC Pestering Peacock (3.0.0) release

2015-11-25 Thread Joost van der Sluis


Hello,

We are happy to announce the release of the Free Pascal Compiler version 
3.0.0 "Pestering Peacock".


This version includes support for, a.o., several new platforms, 
codepage-aware strings, and an integrated Pascal source-repository (fppkg).


New features are listed at
http://wiki.freepascal.org/FPC_New_Features_3.0

Changes that may break backwards compatibility are documented at
http://wiki.freepascal.org/User_Changes_3.0

The 3.0.0 docs is available at
http://www.freepascal.org/docs-html/3.0.0/fpctoc.htm

Downloads are available at our website:
http://www.freepascal.org/download.var

Enjoy!

The Free Pascal Compiler Team


Free Pascal Compiler

   Version 3.0.0


* Introduction


Please also read the platform specific README file, if it exists.

This package contains an advanced freeware 32-bit/64-bit/16-bit pascal
compiler for several platforms. The language and the runtime library are
almost compatible with Turbo Pascal 7.0 and recent Delphi releases. There is
also partial support for the Macintosh pascal dialect.

News and changes related to this release are described in whatsnew.txt.

Free Pascal 3.0.0 is currently available for the following platforms:
- Linux-i386
- Linux-x86_64 (amd64)
- Linux-powerpc
- Linux-sparc
- Linux-ARM
- Win32-i386 (2000/XP, WinNT or later)
- Win64-x86_64 (XP or later)
- Wince-ARM (cross compiled from win32-i386)
- FreeBSD-i386
- FreeBSD-x86_64
- Mac OS X/Darwin for PowerPC (32 and 64 bit)
- Mac OS X/Darwin for Intel (32 and 64 bit)
- iOS (ARM and AArch64/ARM64) and iPhoneSimulator (32 and 64 bit)
- OS/2-i386 (OS/2 Warp v3.0, 4.0, WarpServer for e-Business and eComStation)
- Haiku-i386
- GO32v2-i386
- Nintendo Gameboy Advance-ARM (cross compile from win32-i386)
- Nintendo DS-ARM (cross compile from win32-i386)
- Nintendo Wii-powerpc (cross compile from win32-i386)
- AIX 5.3 and later for PowerPC (32 and 64 bit)
- Java JVM (1.5 and later) and Android Dalvik (Android 4.0 and later)
- Android (ARM, i386, MIPS) via cross-compiling.
- MSDos-i8086 (cross compiled from win32-i386 or Linux)
- Amiga, MorphOS and AROS

There are other platforms (like other BSD variants) which are more or less
working, but there is currently no maintainer for them and thus we cannot
provide adequate support. If you want to change this and create and
maintain versions for other platforms and targets, feel free to contact us,
e-mail addresses are listed below.



* Features


- high speed compiler
- fully 16, 32 or 64-bit code
  - 32 bit compiler can be used on x86_64 Linux distributions to compile
32 bit applications
- language features:
  - almost fully compatible with Borland Pascal and Borland Delphi
  - ansi strings
  - wide strings
  - exception support
  - RTTI support
  - procedure overloading
  - generics (experimental)
  - operator overloading
  - COM, CORBA and raw interfaces support
  - dynamic array support
  - variant support
  - inlining
- code optimizer:
  - peephole optimizer (80x86 only)
  - jump optimizer
  - loading of variables into registers
  - assembler level dataflow analyzer (80x86 only)
  - stack frame eliminations
  - sophisticated register allocator
- integrated BASM (built-in assembler) parser
  - supports ATT syntax used by GNU C
  - supports Intel syntax used by Turbo Pascal (x86-only)
- can compile code into assembler source code for these assemblers:
  - GNU Assembler (GAS)
  - Netwide assembler (Nasm)
  - Microsoft Assembler/Turbo Assembler (Masm/Tasm)
  - Watcom assembler (wasm)
- internal assembler for ultra fast object file generation
- can call external C code
  - h2pas utility to convert .h files to Pascal units
- smart linking (also known as dead code stripping)
- support for the GNU debugger
- integrated development environment (disabled by default on Mac OS X)
  - powerful user friendly Wordstar compatible multi file editor
  - context sensitive help supports help files in HTML, Windows HLP and
Borland TPH format.
  - debugger on most platforms
- can create binaries running natively under both DOS and OS/2 (EMX version)
- no need for Linux distribution specific binaries, programs you write run
  on all distributions
- high quality documentation



* Minimum requirements


Processor:
  i386, x86_64, PowerPC, ARM, MIPS, i8086, Motorola 68k, Sparc or JVM
  runtime
Win32:
 - MS Windows NT/2000/XP or later (Win95, 98 and ME are not supported
   in FPC officially any longer).
 - 16 MB RAM
OS/2:
 - OS/2 Warp v3.0 with one of late fixpaks - FP

Re: [fpc-devel] FPC 3.0.0rc2 and fppkg

2015-11-05 Thread Joost van der Sluis


Op 26-10-15 om 15:14 schreef Joost van der Sluis:

Op 26-10-15 om 14:29 schreef Sven Barth:


> The description is available, but not easy accessible in fppkg. We 
should add some sort of webpage with the available packages and more 
information on those.


IMHO that should be made available with fppkg as well. Other package 
managers like apt-get, pacman, ports etc. do that as well. This way I 
don't need to consult a browser which might not even be available at 
that moment.


Yes, you are right. All this information is available through the 
fppkg-package. There's a Lazarus-package that also shows this 
information in the IDE, I'm not sure if it is still operational, though.


Trunk now supports 'fppkg info '

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

Re: [fpc-devel] Exception problems in FPC 3.0.0

2015-10-26 Thread Joost van der Sluis

Did you compile fpc yourself, or used a binary release? If you did it yourself, 
please try 3.0.1. There was a last minute fix that did not make it into the 
source-archive.

Joost Op 26-10-15 20:39 schreef Sergio Flores:
Hi guys, congrats for the 3.0 release!

However after upgrading FPC, my Android game now crashes with division by zero 
exceptions (it happens always in the same place).


I changed nothing in the code, only the compiler changed from a 2.7.x to 3.0.0 
(cross compiler windows to Arm binary version obtained from the link that was 
distributed in the mailing list last week).

If I revert to using the old compiler, no exceptions happen.


Note that I have this line in one of my units:

Initialization
SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow, 
exUnderflow, exPrecision]);

End.


I masking all of those stuff because it is a requisite for OpenGL graphics.



Looking at the breaking changes section of the wiki, I dont see anything 
related. Anyone has an idea of what changed that could cause this or at least 
how I can debug it?





___

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] FPC 3.0.0rc2 and fppkg

2015-10-26 Thread Joost van der Sluis


Op 26-10-15 om 09:19 schreef Anthony Walter:

I got it working, somewhat.

It would seem that you have to duplicate the entire FPC lib tree 
underneath {UserDir}.fppkg/


No, that should not be necessary. Fppkg uses two locations to install 
packages. One is {UserDir}.fppkg (the local version), but the other one 
should be the location where fpc is installed. That way there is no need 
to duplicate. Read the other mail for hints why it can not find your 
global configuration.


The instructions at the page referenced in my last post are very 
unclear about that.


I suppose under normal fpc install this is needed because the lib 
files are typically only create as root under some folder other than 
your $HOME (done during install). This copy (assuming everything in 
fpc/lib is needed) results in an extra 900MB of files duplicated and 
eating up disk space (I use small SSDs on my laptop),


However, since I always clone FPC and Lazarus from sources and build 
somewhere under my $HOME folder (normally $HOME/Development/Base or 
$HOME/Development/FreePascal), I was able to set LocalRepository 
and GlobalPrefix in ~/.config/fppkg.cfg to my FPC folder 
( $HOME/Development/Base/fpc) and then fppkg worked, sort of.




This should have worked 'out-of-the-box', and it should work with fpc 
3.0.0-rc2, but it could be that you hane to tweak fpc 3.1.1.


I found that almost all package were already "installed". I take 
installed to mean the package source were are already included with 
FPC and compile when I ran "make all" some time ago.


Of the 6 package not installed, I could only compile half. The rest 
complained with results similar to the following:


Target OS: Linux for x86-64
Compiling custembweb.pp
PPU Loading 
/home/gigauser/Development/Base/fpc/lib/fpc/3.1.1/units/x86_64-linux/lnet/lnetssl.ppu

PPU Source: lnetssl.pp not found
Recompiling lNetSSL, checksum changed for openssl
lnetssl.pp(43,57) Fatal: Can't find unit lNetSSL used by lhttp
Fatal: Compilation aborted


Each compiler-version has it's own repository. I did test all packages 
in the 3.0.0 repository. I'll update the 3.1.1 packages later.


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

Re: [fpc-devel] FPC 3.0.0rc2 and fppkg

2015-10-26 Thread Joost van der Sluis


Op 26-10-15 om 12:25 schreef Anthony Walter:

Okay, I'll check into more a bit later.

As a package manager, where is the description of packages? How is 
anyone to know what webdesign is and what it does other than by just 
looking at the package name and perhaps trying to google it?


The description is available, but not easy accessible in fppkg. We 
should add some sort of webpage with the available packages and more 
information on those.


The first google result for "fpc webdesign package" leads to a copy of 
a mailing list question asking what the package does. After a bit more 
googling it would seem that the OP is the author of the package.


To be of any value IMO, a package manager it ought to provide brief of 
descriptions next to package names, otherwise people will have no idea 
what they are looking at.


Those are packages that we are using at my work.

I had to guess at the above and might be wrong. The only reason I 
picked those packages is because they are only one which show up when 
libs isn't configured they way fppkg expects.


I had to start with *some* packages. I think that only lnet is of a real 
value, maybe I should remove the others. We should work on a decent list 
of packages. Maybe add 'libmicrohttpd', 'googleapi' and the new 
IPC-package...


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

Re: [fpc-devel] FPC 3.0.0rc2 and fppkg

2015-10-26 Thread Joost van der Sluis


Op 26-10-15 om 14:29 schreef Sven Barth:


> The description is available, but not easy accessible in fppkg. We 
should add some sort of webpage with the available packages and more 
information on those.


IMHO that should be made available with fppkg as well. Other package 
managers like apt-get, pacman, ports etc. do that as well. This way I 
don't need to consult a browser which might not even be available at 
that moment.


Yes, you are right. All this information is available through the 
fppkg-package. There's a Lazarus-package that also shows this 
information in the IDE, I'm not sure if it is still operational, though.


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

Re: [fpc-devel] FPC 3.0.0rc2 and fppkg

2015-10-26 Thread Joost van der Sluis


Op 26-10-15 om 08:43 schreef Anthony Walter:

*Nothing works for me.*


You are using fpc 3.1.1. The repository for fpc 3.1.1 only contains the 
'extra' packages, like embweb, gecko etc. This is because all the other 
packages can constantly change...



*Following the instructions at http://wiki.freepascal.org/fppkg*
*
*
*When I do fppkg list I see:*

$ fppkg list -l
Name Installed (G)  Installed (L)  Available
embweb   -  -  0.9.1-968
gecko-  -  2.9.0-3
jquery   -  -  0.9.0-842
lazmkunit-  -  0.9.3-1
lnet -  -  0.6.6-2606
webdesign-  -  0.9.0-906



But it should list all the installed packages, although they are not 
available for download.



*When I try to install I get this:*

$ fppkg install embweb
The FPC Package tool encountered the following error:
[embweb] Package fcl-web  is not available



Because it can not find the installed packages. (In this case fcl-web)


*When I try with fcl-base I get this:*

$ fppkg install fcl-base
The FPC Package tool encountered the following error:
Package "fcl-base" not found.



Normal for fpc 3.1.1


*What's the issue? A valid fpc is in the path as well as a valid fpc.cfg.*
*
*
*Output of fppkg listsettings:*

Using global configuration from file "/home/gigauser/.config/fppkg.cfg":
 RemoteMirrorsURL: http://www.freepascal.org/repository/mirrors.xml
 RemoteRepository:  auto
 LocalRepository:   "{UserDir}.fppkg/" -> "/home/gigauser/.fppkg/"
 BuildDir:  "{LocalRepository}build/" -> 
"/home/gigauser/.fppkg/build/"
 ArchivesDir:   "{LocalRepository}archives/" -> 
"/home/gigauser/.fppkg/archives/"
 CompilerConfigDir: "{LocalRepository}config/" -> 
"/home/gigauser/.fppkg/config/"

 DefaultCompilerConfig: "default"
 FPMakeCompilerConfig:  "default"
 Downloader:lnet
Using compiler configuration file "/home/gigauser/.fppkg/config/default":
 Compiler: "/home/gigauser/Development/Base/fpc/bin/fpc"
 Target:   x86_64-linux
 Version:  3.1.1
 GlobalPrefix: "/home/gigauser/Development/Base/fpc/bin" -> 
"/home/gigauser/Development/Base/fpc/bin/"

 LocalPrefix:  "{LocalRepository}" -> "/home/gigauser/.fppkg/"
 GlobalInstallDir: "{GlobalPrefix}lib/fpc/{CompilerVersion}/" -> 
"/home/gigauser/Development/Base/fpc/bin/lib/fpc/3.1.1/"


This setting should point to the location where the packages are 
installed. And it looks right. Do you have a directory called 'fpmkinst' 
here:

/home/gigauser/Development/Base/fpc/bin/lib/fpc/3.1.1/fpmkinst/x86_64

And does this directory contain a lot of .fpm files?

It should...

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

[fpc-devel] FPC 3.0.0rc2 and fppkg

2015-10-25 Thread Joost van der Sluis


Hi all,

One of the new (or rather improved) features of fpc 3.0.0 is the Free 
Pascal packages repository, or shortly fppkg. Basically this is an 
online repository in which you can find several Free Pascal libraries 
that you can use in your projects.


It would be nice if some people can test if it works correctly. It 
should be configured correctly when you used one of the official 
3.0.0-rc2 releases.


First test would be to run 'fppkg list -l'. It should list the name of 
all available packages. All packages that come by default with fpc 
should be marked as installed. If this does not work, there is probably 
a flaw in the configuration. Or you are on Windows, in which case you 
should read the note below this mail. To troubleshoot the configuration, 
use 'fppkg listsettings'.


Second test is to install a package, for example fcl-base, by running 
'fppkg install fcl-base'. This should download the fcl-base package, 
compile it, install it, and thereafter recompile all packages that have 
a dependency on fcl-base. In case the code of these packages is not 
available it should also download those.


This test might look useless, as fcl-base is already installed, but try 
'fppkg list -l' after the installation. You will see that the fcl-base 
package is not installed into the default location (G, short for global) 
but in another location (L, short for local). The local-repository is 
user-specific and useful if you want to test a change in a package, or 
want to have the package compiled with different compiler settings.


So the next test is to install fcl-base with debug-information. You do 
this with 'fppkg install fcl-base -o -gl'. This will install fcl-base 
compiled with debug information and re-compile all depending packages. 
(With the same compiler-settings they were compiled with earlier - so 
normally without debug-information)


Now fcl-base is installed into the local repository with debug 
information, you can create an application using the contnrs unit, and 
see if you can step into it inside the debugger. If not, the Free Pascal 
compiler might not be configured correctly, so that is does not add the 
local repository to it's search path.


Instead of adding debug-information to a package, you could also try to 
add some new functionality to an unit in a package and install it 
without getting into troubles with packages that depend on the changed 
package, as they are automatically re-compiled.


Last, and real, test is to install a package that is not available in 
fpc by default. Like lnet.


Please test and send your findings here.

Regards,

Joost

Note for Windows users: It seems that there is a bug in the 
inno-installer of 3.0.0rc2, with as result that fppkg can not find the 
packages that are installed by the official installer. This should not 
be a big problem, as fppkg will download all the packages that it needs 
and install those. So in the case of fcl-base, it will also download and 
install all packages that fcl-base itself depends on.
There is one other issue, though, and that is that fppkg needs the 
fpmkunit-package to compile packages. There is a fallback-mode to work 
without fpmkunit, but this might not work in all cases due to another 
bug in 3.0.0rc2. You can work-around this bug by installing the fpmkunit 
package before you try to install any other package. ('fppkg install 
fpmkunit')


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

[fpc-devel] FPC 3.0.0-rc2 release

2015-10-21 Thread Joost van der Sluis


Hello

We have placed the second release candidate of the Free Pascal Compiler
version 3.0.0 on our ftp servers. Most important change since the first 
release candidate is a change in the unicode resource-string handling. 
Also there is a new Windows to Android cross-compiler installer.


You can help improve the upcoming 3.0.0 release by downloading and
testing this release. If you want you can report what you have done here:
http://wiki.freepascal.org/Testers_3.0.0

New features are listed at
http://wiki.freepascal.org/FPC_New_Features_3.0

Changes that may break backwards compatibility are documented at
http://wiki.freepascal.org/User_Changes_3.0.0

Issues with this release candidate that we already know of are listed in
the wiki: http://wiki.freepascal.org/Issues_3.0.0

A preview of the 3.0.0 docs is available at
http://www.freepascal.org/docs-html/3.0.0/

Downloads are available at:
* ftp://gd.tuwien.ac.at/languages/pascal/fpc/beta/3.0.0-rc2
* ftp://ftp.freepascal.org/pub/fpc/beta/3.0.0-rc2

Enjoy!

The Free Pascal Compiler Team


Free Pascal Compiler

 Version 3.0.0-rc2


* Introduction


Please also read the platform specific README file, if it exists.

This package contains an advanced freeware 32-bit/64-bit/16-bit pascal
compiler for several platforms. The language and the runtime library are
almost compatible with Turbo Pascal 7.0 and recent Delphi releases. There is
also partial support for the Macintosh pascal dialect.

News and changes related to this release are described in whatsnew.txt.

Free Pascal 3.0.0 is currently available for the following platforms:
- Linux-i386
- Linux-x86_64 (amd64)
- Linux-powerpc
- Linux-sparc
- Linux-ARM
- Win32-i386 (2000/XP, WinNT or later)
- Win64-x86_64 (XP or later)
- Wince-ARM (cross compiled from win32-i386)
- FreeBSD-i386
- FreeBSD-x86_64
- Mac OS X/Darwin for PowerPC (32 and 64 bit)
- Mac OS X/Darwin for Intel (32 and 64 bit)
- iOS (ARM and AArch64/ARM64) and iPhoneSimulator (32 and 64 bit)
- OS/2-i386 (OS/2 Warp v3.0, 4.0, WarpServer for e-Business and eComStation)
- Haiku-i386
- GO32v2-i386
- Nintendo Gameboy Advance-ARM (cross compile from win32-i386)
- Nintendo DS-ARM (cross compile from win32-i386)
- Nintendo Wii-powerpc (cross compile from win32-i386)
- AIX 5.3 and later for PowerPC (32 and 64 bit)
- Java JVM (1.5 and later) and Android Dalvik (Android 4.0 and later)
- Android (ARM, i386, MIPS) via cross-compiling.
- MS-DOS-i8086 (cross compiled from win32-i386 and Linux)
- Amiga, MorphOS and AROS

There are other platforms (like other BSD variants) which are more or less
working, but there is currently no maintainer for them and thus we cannot
provide adequate support. If you want to change this and create and
maintain versions for other platforms and targets, feel free to contact us,
e-mail addresses are listed below.



* Features


- high speed compiler
- fully 16, 32 or 64-bit code
  - 32 bit compiler can be used on x86_64 Linux distributions to compile
32 bit applications
- language features:
  - almost fully compatible with Borland Pascal and Borland Delphi
  - ansi strings
  - wide strings
  - exception support
  - RTTI support
  - procedure overloading
  - generics (experimental)
  - operator overloading
  - COM, CORBA and raw interfaces support
  - dynamic array support
  - variant support
  - inlining
- code optimizer:
  - peephole optimizer (80x86 only)
  - jump optimizer
  - loading of variables into registers
  - assembler level dataflow analyzer (80x86 only)
  - stack frame eliminations
  - sophisticated register allocator
- integrated BASM (built-in assembler) parser
  - supports ATT syntax used by GNU C
  - supports Intel syntax used by Turbo Pascal (80x86-only)
- can compile code into assembler source code for these assemblers:
  - GNU Assembler (GAS)
  - Netwide assembler (Nasm)
  - Microsoft Assembler/Turbo Assembler (Masm/Tasm)
  - Watcom assembler (wasm)
- internal assembler for ultra fast object file generation
- can call external C code
  - h2pas utility to convert .h files to Pascal units
- smart linking (also known as dead code stripping)
- support for the GNU debugger
- integrated development environment (disabled by default on Mac OS X)
  - powerful user friendly Wordstar compatible multi file editor
  - context sensitive help supports help files in HTML, Windows HLP and
Borland TPH format.
  - debugger on most platforms
- can create binaries running natively under both DOS and OS/2 (EMX version)
- no need for Linux distribution specific binaries, programs you write run
  on all distributions
- high quality documentation

Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as

2015-10-07 Thread Joost van der Sluis


Op 06-10-15 om 08:47 schreef Jonas Maebe:


As Sergei mentioned, this is definitely not the right approach. The 
difficulty with finding these files automatically is that they're 
often in non-standard locations. Normally, fpcmkcfg 
(utils/fpcmkcfg/fpcmkcfg.pp, executed to create /etc/fpc.cfg) will ask 
GCC for the path to these object files by extracting the path from the 
output of "gcc --print-libgcc-file-name". It will then prepend -Fl to 
that path and add the result to fpc.cfg
There has been a patch to fix the extraction of the libgcc-path in trunk 
very recently. There was a problem with non-English versions of gcc. 
(using set language)


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

Re: [fpc-devel] FPC 3.0.0-rc1 release

2015-09-05 Thread Joost van der Sluis

-Oorspronkelijk bericht-
Van:Luiz Americo Pereira Camara 
Verzonden:  zo 30-08-2015 19:56
Onderwerp:  Re: [fpc-devel] FPC 3.0.0-rc1 release
Aan:FPC developers' list ; 
> Em 30/08/2015 12:43, "Marco van de Voort"   > escreveu:
> >
> > In our previous episode, Luiz Americo Pereira Camara said:
> > > packages/fcl-web/src/base/[restcodegen.pp, restbase.pp] were merged to 3.0
> > > branch by marco after the last googleapi change.
> > >
> > > Units in the bottom of stack like custcgi.pp and httpdefs.pp were also
> > > merged
> >
> > True, but that is well before rc1 was branched. And it was part of a batch
> > of fcl-web updates.
> 
> No problem at all
> 
> Is not hard to get working
> 
> @Michael
> 
> Do you think is doable to copy googleapi code to a subdiretory of the Lazarus 
> components/googleapi and compile conditionally only in fpc300?

Maybe we can add it to the fppkg repository for 3.0.0.

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

Re: [fpc-devel] What means -Oodfa ?

2015-09-05 Thread Joost van der Sluis

-Oorspronkelijk bericht-
Van:Marcos Douglas 
Verzonden:  do 13-08-2015 19:29
Onderwerp:  Re: [fpc-devel] What means -Oodfa ?
Aan:FPC developers' list ; 
> On Sun, Mar 22, 2015 at 12:55 PM, Florian Klaempfl
>  wrote:
> > Am 22.03.2015 um 15:53 schrieb Juha Manninen:
> >> There are some false positive warnings.
> >
> > Trunk or fixes?
> >
> >> [...]
> >
> > This should be fixed in trunk.
> 
> Could be fixed in "fixes" too?

I don't know. Florian, do you know the revision and is it mergeable?

Regards,

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

[fpc-devel] FPC 3.0.0-rc1 release

2015-08-25 Thread Joost van der Sluis


Hello

We have placed the first release candidate of the Free Pascal Compiler
version 3.0.0 on our ftp servers.

You can help improve the upcoming 3.0.0 release by downloading and
testing this release. If you want you can report what you have done here:
http://wiki.freepascal.org/Testers_3.0.0

New features are listed at
http://wiki.freepascal.org/FPC_New_Features_3.0

Changes that may break backwards compatibility are documented at
http://wiki.freepascal.org/User_Changes_3.0.0

Issues with this release candidate that we already know of are listed in
the wiki: http://wiki.freepascal.org/Issues_3.0.0

A preview of the 3.0.0 docs is available at
http://www.freepascal.org/docs-html/3.0.0/

Downloads are available at:
* ftp://freepascal.stack.nl/pub/fpc/beta/3.0.0-rc1
* ftp://gd.tuwien.ac.at/languages/pascal/fpc/beta/3.0.0-rc1
* ftp://ftp.freepascal.org/pub/fpc/beta/3.0.0-rc1

Enjoy!

The Free Pascal Compiler Team


Free Pascal Compiler

 Version 3.0.0-rc1


* Introduction


Please also read the platform specific README file, if it exists.

This package contains an advanced freeware 32-bit/64-bit/16-bit pascal
compiler for several platforms. The language and the runtime library are
almost compatible with Turbo Pascal 7.0 and recent Delphi releases. 
There is also partial support for the Macintosh pascal dialect.


News and changes related to this release are described in whatsnew.txt.

Free Pascal 3.0.0 is currently available for the following platforms:
- Linux-i386
- Linux-x86_64 (amd64)
- Linux-powerpc
- Linux-sparc
- Linux-ARM
- Win32-i386 (Win95/98/Me/XP/2000/2003/Vista/7 and WinNT)
- Win64-x86_64 (XP/Vista/2003)
- Wince-ARM (cross compiled from win32-i386)
- FreeBSD-i386
- FreeBSD-x86_64
- Mac OS X/Darwin for PowerPC (32 and 64 bit)
- Mac OS X/Darwin for Intel (32 and 64 bit)
- iOS, iPhoneSimulator
- OS/2-i386 (OS/2 Warp v3.0, 4.0, WarpServer for e-Business and eComStation)
- GO32v2-i386

There are other platforms (like other BSD variants) which are more or 
less working, but there is currently no maintainer for them and thus we 
cannot provide adequate support. If you want to change this and create 
and maintain versions for other platforms and targets, feel free to 
contact us, e-mail addresses are listed below.




* Features


- high speed compiler
- fully 16, 32 or 64-bit code
  - 32 bit compiler can be used on x86_64 Linux distributions to compile
32 bit applications
- language features:
  - almost fully compatible with Borland Pascal and Borland Delphi
  - ansi strings
  - wide strings
  - exception support
  - RTTI support
  - procedure overloading
  - generics (experimental)
  - operator overloading
  - COM, CORBA and raw interfaces support
  - dynamic array support
  - variant support
  - inlining
- code optimizer:
  - peephole optimizer (80x86 only)
  - jump optimizer
  - loading of variables into registers
  - assembler level dataflow analyzer (80x86 only)
  - stack frame eliminations
  - sophisticated register allocator
- integrated BASM (built-in assembler) parser
  - supports ATT syntax used by GNU C
  - supports Intel syntax used by Turbo Pascal (80x86-only)
- can compile code into assembler source code for these assemblers:
  - GNU Assembler (GAS)
  - Netwide assembler (Nasm)
  - Microsoft Assembler/Turbo Assembler (Masm/Tasm)
  - Watcom assembler (wasm)
- internal assembler for ultra fast object file generation
- can call external C code
  - h2pas utility to convert .h files to Pascal units
- smart linking (also known as dead code stripping)
- support for the GNU debugger
- integrated development environment (disabled by default on Mac OS X)
  - powerful user friendly Wordstar compatible multi file editor
  - context sensitive help supports help files in HTML, Windows HLP and
Borland TPH format.
  - debugger on most platforms
- can create binaries running natively under both DOS and OS/2 (EMX version)
- no need for Linux distribution specific binaries, programs you write run
  on all distributions
- high quality documentation



* Minimum requirements


i386, x86_64, PowerPC or Sparc processor
Win32:
 - MS Windows NT/2000/2003/XP/Vista/7 (Win95, 98 and ME are not supported
   in FPC officially any longer).
 - 16 MB RAM
OS/2:
 - OS/2 Warp v3.0 with one of late fixpaks - FP 35 should be fine,
   OS/2 Warp v4.0 with FP 5 and above, WSeB, MCP or any eComStation version
   (OS/2 2.0/2.1 currently not supported, not even for compiled programs).
 - Certain features (e.g. Unicode

[fpc-devel] Some examples on fpc's new optimization level -O4

2015-04-23 Thread Joost van der Sluis


Hi all,

I saw a short mail from Florian about the possibilities of fpc's new 
optimization-level -O4. I thought it could be interesting for others 
also, so I've added some explanation and placed it here: 
http://www.cnoc.nl/en/differences-between-optimization-levels-3-and-4-03-and-o4/.


Just for those interested.

Regards,

Joost.
___
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

2014-12-30 Thread Joost van der Sluis


On 12/30/2014 07:12 PM, Mark Morgan Lloyd wrote:

/usr/bin/ld: cannot find -lgcc


Install the libc-(devel) package. And your message is not completely 
clear, does it compile without gdb?


See also the Lazarus-FAQ.

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

Re: [fpc-devel] Question about building fpc for linux_x86 vs linux_x64

2014-12-29 Thread Joost van der Sluis


On 12/29/2014 05:28 AM, Gennady Agranov wrote:

  1. Sounds like fpmake doesn't recursively add dependencies? e.g.
rtl-objpas should come as dep of fcl-base.

I am not familar at all with fpmake design - if fcl-base depends on
rtl-objpas - does it mean that rtl-objpas dependency is exported -
i.e. -Fu to rtl-objpas will be added if only fcl-base dependency is
added in fpmake.pp?


Yes, it should. As Marco also wrote.

But last night I remembered that the system to resolve those 
dependencies has been changed. A few weeks back, files called 
'fpmkunit.cfg' were used to resolve these dependencies. At the moment 
this is done by files called packagename.fpm.


So, can you test if removing all files called 'fpmkunit.cfg' solves your 
problem?


Regards,

Joost.

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

Re: [fpc-devel] Question about building fpc for linux_x86 vs linux_x64

2014-12-29 Thread Joost van der Sluis


On 12/29/2014 04:27 PM, Marco van de Voort wrote:

In our previous episode, Joost van der Sluis said:

On 12/29/2014 05:28 AM, Gennady Agranov wrote:
Yes, it should. As Marco also wrote.

But last night I remembered that the system to resolve those
dependencies has been changed. A few weeks back, files called
'fpmkunit.cfg' were used to resolve these dependencies. At the moment
this is done by files called packagename.fpm.

So, can you test if removing all files called 'fpmkunit.cfg' solves your
problem?


Does fpmake still resolve both, or do you suspect fpmakes not being cleaned?


In theory both. But I tested this only artificially.

What could go wrong is this:

1: build fpc (using fpmkunit)
2: svn update, without a clean before this, so the fpmkunit remains
3: build fpc (using .fpm)
4: a dependency changes
5: fpmake resolves using the old fpmkunit.

But even then, in step 5, fpmake will search for a .fpm file first.

I don't think that this is the case here. I have no idea what really 
happened.


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

Re: [fpc-devel] Question about building fpc for linux_x86 vs linux_x64

2014-12-28 Thread Joost van der Sluis


On 12/28/2014 06:35 PM, Gennady Agranov wrote:

I have built FPC from trunk - thanks to fpcup!!!

For linux_x64 it built as is - great!

For linux_x86 I had to add dependencies for rtl-objpas, rtl-extras,
rtl-console and fcl-base to the following packages:

M   ide/fpmake.pp
M   utils/fpdoc/fpmake.pp
M   utils/fpmake.pp
M   utils/fppkg/fpmake.pp
M   utils/pas2jni/fpmake.pp
M   utils/pas2ut/fpmake.pp
M   utils/unicode/fpmake.pp

What I do not understand is the following - why these missing
dependencies were not required for linux_x64?


What I do not understand is why you needed theses changes in the first 
place? Can you send the commands you used to compile fpc, and the last 
part of the output?



PS. I can submit changes (i guess?) or send a patch file if somebody
needs it.


No, you do not have enough permissions to commit. But can you send the 
patch, so that I can see what you've changed?


Regards,

Joost.

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

Re: [fpc-devel] fpc trunk compile failure...

2014-12-08 Thread Joost van der Sluis


On 12/03/2014 02:05 AM, waldo kitty wrote:


i wasn't able to figure this out but i did make it a little further
after i updated all the .O and .ppu files in the
trunk/units/i386-win32/fcl-base directory... the next error was

=== snip ===
Start compiling package utils for target i386-win32.
Compiling BuildUnit_utils.pp
Compiling usubst.pp
Compiling ptopu.pp
Compiling ptop.pp
Linking bin\i386-win32\ptop.exe
Compiling ppdep.pp
Linking bin\i386-win32\ppdep.exe
Compiling rstconv.pp
The installer encountered the following error:
External command c:/freepascal/fpc/trunk/compiler/ppc386.exe -Twin32
-FEbin\i386-win32 -FUunits\i386-win32\
-Fuc:\freepascal\fpc\trunk\rtl\units\i386-win32\
-Fuc:\freepascal\fpc\trunk\units\i386-win32\fcl-base
-Fuc:\freepascal\fpc\trunk\units\i386-win32\paszlib
-Fuc:\freepascal\fpc\trunk\units\i386-win32\hash -Ur -Xs -O2 -n
-Fuc:/freepascal/fpc/trunk/rtl/units/i386-win32
-Fuc:/freepascal/fpc/trunk/packages/paszlib/units/i386-win32
-Fuc:/freepascal/fpc/trunk/packages/fcl-process/units/i386-win32
-Fuc:/freepascal/fpc/trunk/packages/hash/units/i386-win32
-Fuc:/freepascal/fpc/trunk/packages/libtar/units/i386-win32
-Fuc:/freepascal/fpc/trunk/packages/fpmkunit/units/i386-win32
-Fuc:/freepascal/fpc/trunk/packages/fcl-json/units/i386-win32 -di386
-dRELEASE -viq rstconv.pp failed with exit code 1. Console output:
Target OS: Win32 for i386
Compiling rstconv.pp
Fatal: Can't find unit variants used by fpjson
Fatal: Compilation aborted
=== snip ===

so i gave up, renamed my existing trunk directory and pulled a
completely new update from the repository... that compiled just fine...

i have no clue what the difference is between the old and new... if
anyone has any idea where to possibly look, i'll give it a try... other
than that, in a few weeks or months, i'll be killing off my old trunk
directory...


You  probably have some .ppu or .o files in locations where they should 
not be. This can happen for example if you compile one of the units from 
a command line-yourself. Or by adding the path to the sources to a 
Lazarus-project. If a .ppu file is placed between the sources, this kind 
of problems may arise. (And a make clean does not fix that)


Maybe you could check if this is the case. (You can also search for all 
.ppu and .o files in the checkout and remove them all. See if that helps)


Regards,

  Joost.

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

Re: [fpc-devel] fpmkunit - support for listing of packages for install.dat updates (Was: Re: [Core] Short 8.3 archive-filenames by fpmake)

2014-12-08 Thread Joost van der Sluis


On 12/06/2014 05:14 AM, Tomas Hajny wrote:

As mentioned above, I've prepared a patch for fpmkunit to allow
listing of packages in a way supporting simplification of updates of
install.dat (the file used by the text-mode installer under OS/2 and
GO32v2).

It works by adding a new command ('pkglist'). If used for standard
packages (rather than 'utils'), '-zp units-' needs to be passed among
fpmake options. I've added special recognition for explicit passing
of 'osnone' as target OS which is used in this command to generate
list of zip files with sources (instead of archive with compiled
files). I had to use different rules for evaluation of the
AllLimit83fsOSes (generation of files supporting manual editing of
install.dat for its update in SVN should not depend on the host
operating system where this operation is performed), but this special
treatment is limited to this new command, of course.

Please, let me know what you think about it and if I may commit these
changes.


I don't see anything strange. You could argue if this is the right 
moment to add such a functionality. But otoh it doesn't change any vital 
functionality, and if we don't do it now it will only be functional with 
the next release.


So go ahead.

Regars,

Joost.

___
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

2014-10-24 Thread Joost van der Sluis


On 10/24/2014 12:39 AM, Jonas Maebe wrote:

On 23/10/14 17:16, Vsevolod Alekseyev wrote:

There's no separate makefile for fpcmake alone, is there?


It used to be as simple as going into utils/fpcm and performing a make
all, but with the new FPC-based build system I think that is
unfortunately no longer possible.


With the fpcmake-buildsystem it was possible to build one package from 
fpc-trunk using a fpc-release-compiler with a simple make all. But the 
release-version of all dependencies were used.


So when fpcm-trunk uses a new feature in trunk-fcl-base, there was no 
way to compile the trunk-version of fpcm with a release-compiler.


With fppkg this all changed. Now it's always possible to compile 
(single) trunk-packages using the latest release-compiler. The command 
has been altered, though. You have to do 'fppkg build', instead of 'make 
all'. Fppkg will then compile all the packages that fpcm depend on using 
the new compiler.


This does not work if the new fpcm-package uses new compiler features 
offcourse. And the same holds for the rtl because that one is still 
compiled using the fpcmake-system.


There's one problem, still, and that's the same problem you have with 
the fpcmake-system. When the Makefile's do not support a new target, you 
have to re-generate those first using a new version of fpcmake.


The same holds with the fpmake-system. When your fpmake uses some new 
functionality that is only available in the new compiler or a new 
fpmkunit-unit, you have a problem. For this case fppkg uses two 
configurations. One to compile the fpmake.pp-files, and one to compile 
the actual packages. But that's not configured by default.


Joost.
___
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

2014-10-24 Thread Joost van der Sluis


On 10/24/2014 03:32 PM, Joost van der Sluis wrote:

On 10/24/2014 12:39 AM, Jonas Maebe wrote:

On 23/10/14 17:16, Vsevolod Alekseyev wrote:

There's no separate makefile for fpcmake alone, is there?


It used to be as simple as going into utils/fpcm and performing a make
all, but with the new FPC-based build system I think that is
unfortunately no longer possible.



The same holds with the fpmake-system. When your fpmake uses some new
functionality that is only available in the new compiler or a new
fpmkunit-unit, you have a problem. For this case fppkg uses two
configurations. One to compile the fpmake.pp-files, and one to compile
the actual packages. But that's not configured by default.


I've tried to build trunk's fpcm with fpc 2.6.2 and that failed due to 
new features being used in the fpmake.pp. ;(


So in this case already you'll need the double-fpmake-setup. Or you can 
use the attached patch.


Joost.

Index: utils/fpcm/fpmake.pp
===
--- utils/fpcm/fpmake.pp	(revision 28900)
+++ utils/fpcm/fpmake.pp	(working copy)
@@ -85,7 +85,9 @@
   BuildEngine.Log(vlWarning, 'File revision.inc not found. Svn-revision will not be included in fpcmake executable.');
   Exit;
 end;
-
+{$IFDEF VER2_6}
+  Exit;
+{$ELSE}
   // Run svn info, and catch output.
   P := sender as TPackage;
   P.Options.Add('-dREVINC');
@@ -194,6 +196,7 @@
 end
   else
 BuildEngine.Log(vlWarning,'Subversion executable (svn) not found. Svn-revision in fpcmake executable might be out of date.');
+{$ENDIF}
 end;
 end;
 {$endif HAS_UNIT_PROCESS}
@@ -221,7 +224,9 @@
 P.Directory:=ADirectory;
 {$endif ALLPACKAGES}
 P.Version:='2.7.1';
+{$IFNDEF VER2_6}
 P.SeparateArchive:=false;
+{$ENDIF}
 
 P.Dependencies.Add('fcl-base');
 
@@ -233,8 +238,10 @@
 writeln('Process-unit not available. Svn-revision in fpmake executable might be out-of-date.');
 {$endif HAS_UNIT_PROCESS}
 
+{$IFNDEF VER2_6}
 Data2IncBin := AddProgramExtension('data2inc',Defaults.BuildOS);
 p.Commands.AddCommand(caBeforeCompile, Data2IncBin, '-b -s fpcmake.ini fpcmake.inc fpcmakeini','fpcmake.inc','fpcmake.ini');
+{$ENDIF}
 T:=P.Targets.AddUnit('fpcmmain.pp');
 T.install:=false;
 T.ResourceStrings:=true;
___
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

2014-10-23 Thread Joost van der Sluis


On 10/23/2014 11:49 AM, Jonas Maebe wrote:

On 23/10/14 11:28, Thaddy de Koning wrote:



The starting compiler is any official FPC 2.6.4 compiler that can be
downloaded from our website. With any of those compilers, you can build
both cross and native trunk compiler for any of the targets supported
only by trunk. That's how all targets are bootstrapped.


Not for ARMV6 EABIHF


That's why I said you have to cross-compile. E.g.:
* download FPC 2.6.4 of Linux/i386


And for those who are wondering why Jonas is making such a big point out 
of this: http://bugs.freepascal.org/view.php?id=26930 (Just a bug report 
from today)


We get this kind of bugs, questions and comments all the time. All from 
people who try to build trunk-with-trunk, while they do not know what 
they are doing.


That must stop. So, please, please, *never* say you can/have to build 
fpc-trunk with fpc-trunk. (Unless it's the same revision)


Joost.

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

Re: [fpc-devel] fpcmkcfg invocation for two versions (linux)

2014-10-21 Thread Joost van der Sluis

 thank you,
 
 but my question was more about where to put fpc.cfg so that both 
 versions can use it properly, or, if that is not possible, where to 
 stuff different fpc.cfg's for the same purpose?
 and what would be the basepath in either case?

Normally, if you install both versions at the same location, you don't need two 
fpc.cfg files. Inside the fpc.cfg you can use macro's so that the the compiler 
searches for the right units (ppu's). This is done by fpcmkcfg by default. (Or 
samplecfg which is a wrapper around fpcmkcfg)

Overall the proces is quite simple: install fpc version A. Rename the 
compiler-executable from ie. ppcx64 to ppcx64_2_6_4. Then install fpc version 
b. Now you can select which version you want to use by calling the compiler 
using different names. (ppcx64 and ppcx64_2_6_4). This works perfectly if you 
use an IDE like Lazarus, in which you can simply select which 
compiler-executable to use. If you want to use 'fpc' to call the compiler, you 
need some additional tricks.

But to answer your question: you can place a fpc.cfg in the same location as 
the executable. If you place the executables of both compiler-versions in a 
different directory, they can both have their own fpc.cfg. (You can use the -va 
compiler option to see which fpc.cfg is actually used)

My current setup is that I have fpc-trunk installed in my home-directory. (I 
use 'make install PREFIX=~/fpc') And I have added ~/fpc/bin/x86_64 to my path. 
And I have a fpc.cfg in ~/fpc/bin/x86_64.

But I also have fpc 2.6.4 installed, the version provided by my 
Linux-distribution. If I need the original/latest release I use the full path 
to the compiler, or rename ~/fpc to ~/fpc_.

In short: there are a lot of configurations possible, and everyone can decide 
what's the best setup for his/her needs.

Joost.___
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

2014-10-17 Thread Joost van der Sluis


On 10/17/2014 12:09 PM, Paul Michell wrote:

I'm currently trying to build 2.7.1 from SVN on the latest Raspbian 
(2014-09-09).
I've previously built this with either 2.6.0 from the repository, or with 
Thaddy de Koning's build from March 2014.

Currently, neither of these will build 2.7.1 on a Raspberry Pi.  So I have also 
tried with the generic arm-linux
release archive (fpc-2.6.4.arm-linux.tar).  This installed without error and I 
can compile projects on the Pi with it.

However, when trying to build 2.7.1 (make all) it creates a compiler binary, 
but fails whilst compiling fpmake.
This looks similar to the bug 0024056 which is flagged as resolved.  The 
solution suggested there is to install
build-essential, but this is installed by default on Raspbian, so I think there 
must be something else wrong?


Did you try

make clean all NO_UNIT_PROCESS OPT=-dNO_THREADING

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

Re: [fpc-devel] Invalid line-info on array of const

2014-10-15 Thread Joost van der Sluis


On 09/04/2014 10:36 PM, Florian Klämpfl wrote:

Am 04.09.2014 um 21:52 schrieb Joost van der Sluis:


I can add this check to the debugger anyway, but am I right that the line info 
in the example is
wrong? Then I can try to fix it.


Yes, it is wrong. Go ahead and fix it :)


Done. (r28824) The hesitated to write the line-number of the start of 
the current function in this case, but a remark in the 
dwarf-specification suggest to use 0 as line number in cases like these, 
so I used that.


But gdb choked on it. Probably because with this change line-information 
is generated for instructions that do not correspond to the start of a 
statement/line. In that case IsStatement has to be set to false, so I 
added that too.


Regards,

Joost.





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

Re: [fpc-devel] MIPS big-endian program starts but does nothing

2014-09-08 Thread Joost van der Sluis


On 09/08/2014 10:25 AM, Reinier Olislagers wrote:

gdb ./hellomips


dlopen failed on 'libthread_db.so.1' - File not found
GDB will not be able to debug pthreads.

GNU gdb 6.8
Copyright (C) 2008 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 mips-openwrt-linux...
(no debugging symbols found)
(gdb) run
Starting program: /usbstorage/backup/hellomips




That's it? Nothing more? You could try to send a sigint (ctrl-c) and 
then ask for a backtrace (bt).


Or add a breakpoint on main first, and then run the appication. (b main)

Joost.

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

[fpc-devel] Invalid line-info on array of const

2014-09-04 Thread Joost van der Sluis


Hi all,

I think I've found a bug while testing the fpdebug-debugger. The 
line-info for the attached program is not entirely correct, I think.


Here's the generated assembly:

# [12] case i of
movl-12(%rbp),%eax
testl   %eax,%eax
jl  .Lj10
testl   %eax,%eax
jne .Lj10
jmp .Lj9
.Lj10:
.Ll5:
# [18] writeln('hallo');
callfpc_get_output
movq%rax,%rbx
movq$_$PROJECT4$_Ld1,%rdx
movq%rbx,%rsi
movl$0,%edi
callfpc_write_text_shortstr
callFPC_IOCHECK
movq%rbx,%rdi
callfpc_writeln_end
callFPC_IOCHECK
.Lj9:
.Lj5:
callFPC_POPADDRSTACK
.Ll6:
# [20] end;
leaq-24(%rbp),%rdi
callfpc_ansistr_decr_ref
movq-120(%rbp),%rax
testq   %rax,%rax
je  .Lj6
callFPC_RERAISE
.Lj6:
movq-128(%rbp),%rbx
leave
ret

As you can see, according to the line-info the call to FPC_POPADDRSTACK 
belongs to the writeln. But the jump in the case goes to label Lj9.


Imaging stepping through this procedure. When the writeln is skipped, 
the 'call fpc_popaddrstack' is the next command. And the debugger will 
think that the 'writeln' is the current command. (ie: the debugger jumps 
from line 12 to 18. Even if line 18 is never executed)


Gdb does not show this. I think because it also checks if the current 
instruction pointer is at the start of the line as given in the debug 
info. FpDebug also does that check in some cases, but not in this case 
since it should not be necessary. At least so I thought.


I can add this check to the debugger anyway, but am I right that the 
line info in the example is wrong? Then I can try to fix it.


Joost.
program project4;

uses
  sysutils;

function Test: string;
var
  i: Integer;
  AValue: string;
begin
  i := 0;
  case i of
0: begin
 if false then
   raise exception.CreateFmt('Test',[AValue]);
   end
  else
writeln('hallo');
  end;
end;

begin
  test;
end.

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

Re: [fpc-devel] fpc 2.6.2 gives AV on arm

2013-08-23 Thread Joost van der Sluis


On 08/15/2013 12:16 PM, Mattias Gaertner wrote:

On Thu, 15 Aug 2013 11:45:38 +0200
Jonas Maebe jonas.ma...@elis.ugent.be wrote:



On 15 Aug 2013, at 11:26, Mattias Gaertner wrote:


On Fri, 09 Aug 2013 23:10:05 +0200
Florian Klämpfl flor...@freepascal.org wrote:



Where did you get the CROSSOPT=-dFPC_ARMEL from? It is not needed at all.


It's on the wiki:
http://wiki.lazarus.freepascal.org/Custom_Drawn_Interface/Android#Building_the_compiler_yourself_in_Linux


It only mentions OPT=-dFPC_ARMEL, not CROSSOPT=-dFPC_ARMEL.


You are right. I misread the mails and misunderstood Joost
statement. Sorry.


I think I got confused and mixed the two. Probably because of some other 
things I've tried with other CROSSOPT options.


Joost.


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

[fpc-devel] fpc 2.6.2 gives AV on arm

2013-08-09 Thread Joost van der Sluis


Hi all,

I've cross-compiled a ppcarm, and now I try to use that compiler on qemu 
to build fpc (2.6.2).


But the compiler crashes on compiling the system-unit. But with trunk 
(2.7.1) this all works.


Thing is that I'm trying to get fpc 2.6.2 working on the new arm-target 
of Fedora (armv7, hardware float, little endian). Maybe someone knows in 
which revision this could have been fixed, so that I can apply that fix 
to 2.6.2 on Fedora?


Here's the stacktrace:

/home/joost/ppcarm -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../arm -Fi../unix 
-Fiarm -FE. 
-FU/home/joost/rpmbuild/BUILD/fpcbuild-2.6.2/fpcsrc/rtl/units/arm-linux 
-k--build-id -gl -darm -dRELEASE -Us -Sg system.pp -dFPC_ARMEL

Fatal: Compilation aborted
An unhandled exception occurred at $0003CDD0 :
EAccessViolation : Access violation
  $0003CDD0  FINDGETFILEINFO,  line 711 of ../unix/sysutils.pp
  $0003D118  FINDNEXT,  line 774 of ../unix/sysutils.pp
  $0003D350  FINDFIRST,  line 816 of ../unix/sysutils.pp
  $0004B970  TCACHEDDIRECTORY__RELOAD,  line 266 of cfileutl.pas
  $0004B678  TCACHEDDIRECTORY__FORCEUSECACHE,  line 223 of cfileutl.pas
  $0004B624  TCACHEDDIRECTORY__TRYUSECACHE,  line 212 of cfileutl.pas
  $0004BE94  TCACHEDDIRECTORY__DIRECTORYEXISTS,  line 346 of cfileutl.pas
  $0004C464  TDIRECTORYCACHE__DIRECTORYEXISTS,  line 422 of cfileutl.pas
  $0004CF90  PATHEXISTS,  line 676 of cfileutl.pas
  $0004E6BC  TSEARCHPATHLIST__ADDPATH,  line 1120 of cfileutl.pas
  $0004DFC8  TSEARCHPATHLIST__ADDPATH,  line 975 of cfileutl.pas
  $000E0AB8  TOPTION__INTERPRET_OPTION,  line 1058 of options.pas
  $000E53C0  TOPTION__READ_PARAMETERS,  line 2280 of options.pas
  $000E6ACC  READ_ARGUMENTS,  line 2808 of options.pas
  $0002CE74  INITCOMPILER,  line 187 of compiler.pas
  $0002CF68  COMPILE,  line 234 of compiler.pas
  $8360  main,  line 223 of pp.pas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpc 2.6.2 gives AV on arm

2013-08-09 Thread Joost van der Sluis


On 08/09/2013 07:07 PM, Jonas Maebe wrote:


On 09 Aug 2013, at 18:46, Joost van der Sluis wrote:


Thing is that I'm trying to get fpc 2.6.2 working on the new arm-target of 
Fedora (armv7, hardware float, little endian).


The EABI with hardfloat is not supported at all in 2.6.2.


That's good to know. But in that case it should still work with 
soft-float, no?


If I explicitly add -Cfsoft it gives the exact same result. This is what 
I use to build the compiler:


make clean all CPU_TARGET=arm BINUTILSPREFIX=arm-linux-gnu- 
CROSSOPT=-O- -CaEABI -gl -dFPC_ARMEL -Cfsoft


I did not add armv7, because if I do that, the ppcarm executable crashes 
immediately after startup.


Joost.



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

Re: [fpc-devel] fpc 2.6.2 gives AV on arm

2013-08-09 Thread Joost van der Sluis


On 08/09/2013 06:46 PM, Joost van der Sluis wrote:

Hi all,

I've cross-compiled a ppcarm, and now I try to use that compiler on qemu
to build fpc (2.6.2).

But the compiler crashes on compiling the system-unit. But with trunk
(2.7.1) this all works.

Thing is that I'm trying to get fpc 2.6.2 working on the new arm-target
of Fedora (armv7, hardware float, little endian). Maybe someone knows in
which revision this could have been fixed, so that I can apply that fix
to 2.6.2 on Fedora?


Hard to do a bisect when you have to cross-compile and copy the binary 
to another machine each time... but it was r19562.


Which is the revision to switch to armel by default.

I had to add OPT=-dFPC_ARMEL, CROSSOPT=-dFPC_ARMEL alone was not enough.

Joost.

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

[fpc-devel] Cross-compile compiler itself

2013-08-08 Thread Joost van der Sluis


Hi all,

How can I cross-compile the compiler itself? I tried it by:

make clean all CPU_TARGET=arm

Then:
make all CPU_TARGET=arm PP=ppcrossarm

But that one failes, because the first step it does is compiling the rtl 
for the host platform (x86_64). Which fails when ppcrossarm is used for 
that...


There has to be a way, but how?

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

Re: [fpc-devel] Cross-compile compiler itself

2013-08-08 Thread Joost van der Sluis


On 08/08/2013 12:54 PM, Jonas Maebe wrote:


On 08 Aug 2013, at 12:51, Joost van der Sluis wrote:


How can I cross-compile the compiler itself? I tried it by:

make clean all CPU_TARGET=arm

Then:
make all CPU_TARGET=arm PP=ppcrossarm

But that one failes, because the first step it does is compiling the
rtl for the host platform (x86_64). Which fails when ppcrossarm is
used for that...

There has to be a way, but how?


After the first command, there is already a cross-compiled compiler in
the compiler subdirectory (called ppcarm).


Ohh.. so easy...

Thanks.

Joost.

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

RE: [fpc-devel] bootstrapping FPC trunk

2013-06-02 Thread Joost van der Sluis

-Oorspronkelijk bericht-
 1. can FPC 2.6.0 (bootstrap) be used to bootstrap trunk or do i need to 
 replace 
 my current binutils/ppc386.exe with the 2.6.2 one?

Officially: yes. In practice: no.

But the 'in practice' part can change. ;)
 
 2. do i need to update my binutils/i386-win32 directory? everything in there 
 is 
 physically dated 21 May 2012 which i guess is when i reinstalled everything 
 from 
 scratch the last time... the SVN URL that i used for that directory is 
 http://svn.freepascal.org/svn/fpcbuild/branches/fixes_2_6/install/binw32 and 
 and 
 according to the properties, it looks like it is actually dated 11 Dec 2011...

You can still use those files.

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

Re: [fpc-devel] Linux x86_64 trunk fails to build

2013-04-26 Thread Joost van der Sluis

On Fri, 2013-04-26 at 00:07 -0500, Michal Wallace wrote:
 On Apr 25, 2013 10:57 PM, Anthony Walter sys...@gmail.com wrote
  nx64flw.pas(32,37) Error: Identifier not found tcgraisenode

 Someone (you?) mentioned this on #fpc earlier. I tracked down the
 cause of the problem but do not have a fix.

No, that was me. And meanwhile this is fixed in trunk. (although there
might be some other issues)

Joost.

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

[fpc-devel] Failed to compile ios-headers from fpc's trunk

2013-02-16 Thread Joost van der Sluis

Hi all,

When I try to parse  compile the ios-headers as supplied in cocoaint/utils, I 
get the following error:

NSEnumerator.inc(18,18) Fatal: Syntax error, ; expected but identifier 
__UNSAFE_UNRETAINEDPTR found

The offending code is: 
function countByEnumeratingWithState_objects_count(state: 
NSFastEnumerationStatePtr; buffer: id __unsafe_unretained; len: NSUInteger): 
NSUInteger;

Apparently the parser does not handle the __unsafe_unretained identifier 
properly. I used fpc-trunk and the ios 5.1 sdk. 

I know that there are other versions of the ios-headers available that do work, 
but what is the status of the version in fpc-trunk? Is it useable? And should 
it be used?

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

Re: [fpc-devel] Bug 18702

2012-08-22 Thread Joost van der Sluis

I saw some activity on this bug, so I thought it would be a good idea to
draw some attention to this message. 

On Sat, 2011-12-24 at 16:03 +0100, Joost van der Sluis wrote:
 Hi all,
 
 Seems like it that bug 18702 has nothing to do with my changes to the
 stack-balancing code, and that nested function proc's never functioned
 well on Windows.
 
 The problem is that pop_parasize() is used to pop the stack-frame
 pointer form the stack. But on 32-bit Windows, pop_parasize() has some
 code to ensure that the funcret pointer is removed from the stack by the
 caller. This is not applicable to the situation where only the
 stack-frame pointer has to be popped from the stack.
 
 A possible solution is attached, but I didn't commit it yet because I'm
 nut sure if it is 'allowed' to use a 'target_info.system =
 system_i386_win32' condition in ncgcal.pas. Other solutions could be to
 add a parameter to pop_parasize or to add something like
 pop_funcret_parasize().
 
 Thoughts?
 
 Joost.

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

Re: [fpc-devel] Re: Class field reordering

2012-07-22 Thread Joost van der Sluis

On Sun, 2012-07-22 at 12:53 +0200, Jonas Maebe wrote:
 On 22 Jul 2012, at 12:40, Martin Schreiber wrote:
  AFAIK TObject is the only class which depends on compiler magic? Are there 
  other classes which can not be duplicated?
 
 Pretty much anything in the system and dialect units (objpas, macpas, objc, 
 iso7185) is/can be(come) tightly bound to the compiler. The rest should be 
 safe.

There are more, like typinfo. In fact you could copy that one, but when
the underlying rtti-information generated by the compiler changes...

Joost.

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

[fpc-devel] class-attributes

2012-05-24 Thread Joost van der Sluis

On 17 May 2012, at 23:32, Joost van der Sluis wrote:

 I'm trying to implement extended RTTI property attributes as
 supported by recent Delphi versions.

Please add this functionality first to a separate branch for easier
reviewing.

I could, but I attached a patch first. Before I commit this to a branch
I want to know that I'm on the right track. Could you and/or others have
a look at the patch?

I'm especially interested if things are done in the right units, and if
the code in ptypes.pas is acceptable.

Attached are the patch and a simple test-program. 

First an example what class-attributes are:

type
  TMyObject = class
  published
[TAttributeClassName('param1','param2')]
property AProperty;
  end;

When you request the class-property that belongs to the property
AProperty, then you get an instance of the TAttributeClassName class
which is constructed by calling it's constructor with the supplied
parameters. (In this case 'param1' and 'param2')

How I implemented this:
For each attribute a function is generated that returns a class-instance
of the attribute. This function is generated in ptypes by creating a
tcgprocinfo. All the necessary nodes are added to it and then
tcgprocinfo.generate_code is executed.

In the rtti-info (ppropinfo) the address of this function is stored so
that it is possible to read those attributes.

If I'm on the right track I'll add a branch with this patch and work
from there. Some issues:

- In Delphi an attribute-class has to be defined as a TCustomAttribute.
That way it's also clear which constructor has to be called. For now, it
calls the first constructor it can find.

- The rtti-info is now stored inside PPropInfo, I don't think that this
is how Delphi does it, also because in Delphi you need the 'rtti' unit
to get this information. I've added it to typinfo and later on a 'rtti'
unit could be written as a wrapper around typinfo.

- When we add more rtti-information to types we need a way to specify
what to generate and what not and where to store it. Especially because
the rtti-info will grow. 

- No error is generated when you define an attribute for something else
then a property.

- The attribute-definition is stored in the .ppu, but that's not really
needed. Since at compile-time this information is never used by another
unit. I used it for debugging though (with ppudump) A side-effect is
that when an attribute is changed, a recompilation of the unit is
forced. Do we want that? (For now only the attribute-type is stored in
the ppu, not the parameters)

Joost.







-- 
Met vriendelijke groeten,

  Joost van der Sluis
  CNOC Informatiesystemen en Netwerken
  http://www.cnoc.nl
Index: compiler/ptype.pas
===
--- compiler/ptype.pas	(revision 21375)
+++ compiler/ptype.pas	(working copy)
@@ -60,11 +60,14 @@
 { parse hint directives (platform, deprecated, ...) for a procdef }
 procedure maybe_parse_hint_directives(pd:tprocdef);
 
+{ generate hidden RTTI attribute functions which return the attribute classes }
+procedure generate_rttiattribute_procs;
+
 implementation
 
 uses
{ common }
-   cutils,
+   cutils,sysutils,pparautl,
{ global }
globals,tokens,verbose,constexp,
systems,
@@ -80,10 +83,11 @@
fmodule,
{ pass 1 }
node,ncgrtti,nobj,
-   nmat,nadd,ncal,nset,ncnv,ninl,ncon,nld,nflw,
+   nmat,nadd,ncal,nset,ncnv,ninl,ncon,nld,nflw,nmem,nbas,
+   ncgutil,
{ parser }
scanner,
-   pbase,pexpr,pdecsub,pdecvar,pdecobj,pdecl,pgenutil
+   pbase,pexpr,pdecsub,pdecvar,pdecobj,pdecl,pgenutil,psub
 {$ifdef jvm}
,pjvm
 {$endif}
@@ -1618,7 +1622,138 @@
 read_named_type(def,nil,nil,nil,parseprocvardir);
   end;
 
+procedure generate_rttiattribute_proc(APropertySym: tpropertysym; AnAttribute: trtti_attribute; attribute_index: longint);
+var
+  pd: tprocdef;
+  aprocsym: tprocsym;
+  st:TSymtable;
+  checkstack : psymtablestackitem;
+  old_current_procinfo : tprocinfo;
+  old_current_structdef: tabstractrecorddef;
+  old_current_genericdef,
+  old_current_specializedef: tstoreddef;
+  block: tblocknode;
+  load: tloadnode;
+  statement: tstatementnode;
+  call: tcallnode;
+  assignment: tassignmentnode;
+  constrdef: tprocdef;
+  vmtaddrnode: tloadvmtaddrnode;
+begin
+  aprocsym:=tprocsym.create(make_mangledname('_RTTI_ATTRIBUTE_',symtablestack.top,APropertySym.Name+'_'+IntToStr(attribute_index)));
+  symtablestack.top.insert(aprocsym);
+  aprocsym.visibility:=vis_hidden;
 
+  st:=nil;
+  checkstack:=symtablestack.stack;
+  while assigned(checkstack) do
+begin
+  st:=checkstack^.symtable;
+  if st.symtabletype in [staticsymtable,globalsymtable,localsymtable] then
+break;
+  checkstack:=checkstack^.next;
+end;
+  pd

Re: [fpc-devel] class-attributes

2012-05-24 Thread Joost van der Sluis

On Thu, 2012-05-24 at 18:48 +0200, Sven Barth wrote:
 On 24.05.2012 15:27, Joost van der Sluis wrote:
  On 17 May 2012, at 23:32, Joost van der Sluis wrote:
  I could, but I attached a patch first. Before I commit this to a branch
  I want to know that I'm on the right track. Could you and/or others have
  a look at the patch?

 * please call your generate_rttiattribute_procs after the 
 generate_specialization_procs as methods of generics could force the 
 specialization of a class that is not yet specialized, but that carries 
 attributes

Ok, I'll change that.

 * maybe it's better not to generate attribute data for generics, I don't 
 know... (simply check for df_generic in ttypesym(p).typedef.defoptions 
 in generate_rttiattribute_procs_classes)

I'll will look what Delphi does. In principle i don't a reason why it
shouldn't work.

 * in generate_rttiattribute_procs_properties you also need to handle 
 nested classes

Ah yes, offcourse. I will also look at the 'normal' rtti generation, I
copied the code from there. Maybe that there is no rtti information
generated for nested classes at all at this moment.

 * you might want to call me blind, but where did you add the field 
 rtti_attributesdef to, to which you assign the current_rttiattributedef? 
 (can it be that you forgot that in the patch?)

See the second change in pdecobj. (In procedure truct_property_dec) 

 And two questions:
 * does the usage of attributes with methods/fields depend on the 
 availability of the extended RTTI?

Yes. Without extended RTTI you can not get a list of method/fields at
runtime. So where should the attributes be bound to?

 * can attributes also be used with records in Delphi? (as they can now 
 carry properties as well)

I don't know. Do we support rtti on records? I think this is also a part
of what Delphi calls 'extended rtti'.

Joost

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

Re: [fpc-devel] Differences between 'tsym' and 'tdef'

2012-05-18 Thread Joost van der Sluis

On Fri, 2012-05-18 at 06:30 +0800, Paul Ishenin wrote:
 18.05.12 5:32, Joost van der Sluis wrote:
 
  Now I'm wondering if I should make this new field of Tpropertysym a TDef
  or a TSym(table). I know that Tsym can store itself to a ppu while a
  TDef does not. But There was something else, too. But I don't remember
  exactly.
 
 TSym is about symbol and TDef is about definition. Each symbol is just 
 an identifier which compiler founds during parse which may have  1 
 definitions (overloaded functions for example). A definition does not 
 have a name (generally) but instead have information how to work with 
 it. It may refer to no symbol at all. Both are stored in a TSymTable and 
 ppu (look at TStoredDef).
 
 A property does not have a definition of itself - only a symbol and list 
 of fields/procedures for read,write,stored.

Thanks.

  So two questions: how should I extend the Tpropertysym for the extended
  attributes, and what is the dfference/use of Tdef and Tsym.
 
 Does any symbol in delphi may have this information? If property has 
 this information and you created a descendant property - will it have 
 the same attributes as an ancestor property?

This information can be bound to a properties but also whole classes at
least. (I'll have to test for methods and public fields) So no, not only
properties may have this information.

And, to answer your second question, properties in a descendant class do
*not* inherited the properties of the ancestor. I found that pretty
strange, but that's how it is implemented in Delphi. 

 For now if only property may have this information then choose 
 TPropertySym for storing it.

So in this case create a special symbol and symtable for it?

Joost.

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

Re: [fpc-devel] Differences between 'tsym' and 'tdef'

2012-05-18 Thread Joost van der Sluis

On Fri, 2012-05-18 at 15:13 +0800, Paul Ishenin wrote:
 18.05.2012 14:23, Joost van der Sluis wrote:
 
  This information can be bound to a properties but also whole classes at
  least. (I'll have to test for methods and public fields) So no, not only
  properties may have this information.
 
 If methods may have this information then it is not possible to put it 
 to tsym because paticular method is a tprocdef and several tprocdefs may 
 have 1 tprocsym (overloaded methods). Therefore I would put this info to 
 tstoreddef. But what to do with a property? Create a special def for it?
 
  And, to answer your second question, properties in a descendant class do
  *not* inherited the properties of the ancestor. I found that pretty
  strange, but that's how it is implemented in Delphi.
 
 There may be 3 cases. Does it work in any:
 
 case 1: property descendant
 
 TAncestor = class
[attributes]
property SomeProp: TSomeType read GetSomeProp;
 end;
 
 TDescendant = class(TAncestor)
property SomeProp write SetSomeProp; // - this is property descendant
 end;

This one should not have any attributes.

 case 2: new property hides old
 
 TDescendant = class(TAncestor)
property SomeProp: TSomeType read GetSomeProp; // - this property 
 hides old SomeProp
 end;

Also not.

 case 3: new class uses property as is
 
 TDescendant = class(TAncestor)
 end;

Also not. (I know, it is strange behavior. But there are more strange
things, as there is no type-checking in attributes. It seems like they
just hacked this together rather quickly...) 

  So in this case create a special symbol and symtable for it?
 
 Looking at 
 http://docwiki.embarcadero.com/RADStudio/en/Annotating_Types_and_Type_Members 
 I see that attribute is a class + a list of arguments for that class 
 contructor. As this is a class - compiler already creates a symbol and a 
 definition for it and all it members. So you need to store a link to 
 this class (or to class contructor) + a list of arguments to pass there. 
 So it is not a special symbol, just a reference to it. If you need an 
 example of how to store/restore reference to a class then look at how it 
 is done with tobjectdef.childof or tobjectdef.extendeddef.

Indeed. And I do have the symbol of the corresponding type and a list of
parameters already. I thought I needed a symbol/definition to store the
references. Else I would have to store those references in the
TPropertySym, but also in the symbol of the class. That doesn't look
good to me?

Joost.

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

Re: [fpc-devel] Differences between 'tsym' and 'tdef'

2012-05-18 Thread Joost van der Sluis

On Fri, 2012-05-18 at 11:31 +0200, Sven Barth wrote:
 Am 18.05.2012 09:49 schrieb Joost van der Sluis jo...@cnoc.nl:
  Also not. (I know, it is strange behavior. But there are more
 strange
  things, as there is no type-checking in attributes. It seems like
 they
  just hacked this together rather quickly...)
 
 
 You mean typechecking regarding the constructor arguments? Would it be
 possible to add this?

I think I can. But in Delphi you can also give a non-exsisting
attribute, ie:

  TMyClass=class
  private
FName: string;
  published  
[TThisTypeIsNowhereDefined('You','Can','Enter','Anything','here'1)]
property Name: string read FName;
  end;

This will compile in Delphi, but it won't work. This is especially
annoying if you forgot to add the unit in which
TThisTypeIsNowhereDefined is defined. In that case it will also compile,
but it will not work. And you will seek for that error for long. I
know. ;)

 Another note: does Delphi allow/support attributes in interfaces? If
 so you need to check that GUIDs are handled correctly (AFAIK they can
 also be string constants instead of naked strings)

I started my implementation by copying the part where interface GUID's
are parsed, so I already took care of that. (But it's simple: interfaces
do not support attributes)

Joost

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

[fpc-devel] Differences between 'tsym' and 'tdef'

2012-05-17 Thread Joost van der Sluis

Hi all,

I'm trying to implement extended RTTI property attributes as supported
by recent Delphi versions. Extending the parser to allow the property
attributes syntax was easy.

Now I want to add the extended-attribute information to Tpropertysym,
but have to decide how to do that. It is possible to add more then one
such property attribute to one property, so it needs some kind of table.

Now I'm wondering if I should make this new field of Tpropertysym a TDef
or a TSym(table). I know that Tsym can store itself to a ppu while a
TDef does not. But There was something else, too. But I don't remember
exactly. 

So two questions: how should I extend the Tpropertysym for the extended
attributes, and what is the dfference/use of Tdef and Tsym.

I once figured this out for another compiler-patch but I forgot it.

Joost 

___
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?

2011-12-24 Thread Joost van der Sluis

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.

Joost.

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

[fpc-devel] Bug 18702

2011-12-24 Thread Joost van der Sluis

Hi all,

Seems like it that bug 18702 has nothing to do with my changes to the
stack-balancing code, and that nested function proc's never functioned
well on Windows.

The problem is that pop_parasize() is used to pop the stack-frame
pointer form the stack. But on 32-bit Windows, pop_parasize() has some
code to ensure that the funcret pointer is removed from the stack by the
caller. This is not applicable to the situation where only the
stack-frame pointer has to be popped from the stack.

A possible solution is attached, but I didn't commit it yet because I'm
nut sure if it is 'allowed' to use a 'target_info.system =
system_i386_win32' condition in ncgcal.pas. Other solutions could be to
add a parameter to pop_parasize or to add something like
pop_funcret_parasize().

Thoughts?

Joost.
Index: i386/n386cal.pas
===
--- i386/n386cal.pas	(revision 19881)
+++ i386/n386cal.pas	(working copy)
@@ -81,16 +81,6 @@
 exit;
   end;
 
-{ on win32, the caller is responsible for removing the funcret }
-{ pointer from the stack, unlike on Linux. Don't know about}
-{ elsewhere (except Darwin, handled above), but since the default  }
-{ was callee removes funcret pointer from stack until now, we'll }
-{ keep that default for everyone else (ncgcal decreases popsize by }
-{ sizeof(aint) in case of ret_in_param())  }
-if (target_info.system = system_i386_win32) and
-paramanager.ret_in_param(procdefinition.returndef,procdefinition.proccalloption) then
-  inc(pop_size,sizeof(aint));
-
 { better than an add on all processors }
 if pop_size=4 then
   begin
Index: ncgcal.pas
===
--- ncgcal.pas	(revision 19881)
+++ ncgcal.pas	(working copy)
@@ -875,6 +875,18 @@
 (tf_safecall_exceptions in target_info.flags)) and
paramanager.ret_in_param(procdefinition.returndef,procdefinition.proccalloption) then
   dec(pop_size,sizeof(pint));
+
+{ on win32, the caller is responsible for removing the funcret }
+{ pointer from the stack, unlike on Linux. Don't know about}
+{ elsewhere (except Darwin, handled above), but since the default  }
+{ was callee removes funcret pointer from stack until now, we'll }
+{ keep that default for everyone else (ncgcal decreases popsize by }
+{ sizeof(aint) in case of ret_in_param())  }
+if (not paramanager.use_fixed_Stack) and
+   (target_info.system = system_i386_win32) and
+paramanager.ret_in_param(procdefinition.returndef,procdefinition.proccalloption) then
+  inc(pop_size,sizeof(aint));
+
 { Remove parameters/alignment from the stack }
 pop_parasize(pop_size);
   end
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Paramstr trailing spaces, bug or not?

2011-12-22 Thread Joost van der Sluis

Hi all,

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?

Joost
-- 
My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog

___
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?

2011-12-22 Thread Joost van der Sluis

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?

Joost.
-- 
My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog

___
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?

2011-12-22 Thread Joost van der Sluis

On Thu, 2011-12-22 at 19:15 +0100, Pierre Free Pascal wrote:
 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?

What I did was this: 'make install PREFIX=c:\lazarus\fpc\2.7.1\' the
trailing backslash is important...

Then make runs (among others) the following command:
.\fpmake.exe install --localunitdir=../.. --globalunitdir=.. --os=win32 
--cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o 
-FuC:/svn/fpc-trunk/rtl/units/i386-win32 -o 
-FuC:/svn/fpc-trunk/packages/hash/units/i386-win32 -o 
-FuC:/svn/fpc-trunk/packages/paszlib/units/i386-win32 -o 
-FuC:/svn/fpc-trunk/packages/fcl-process/units/i386-win32 -o 
-FuC:/svn/fpc-trunk/packages/fpmkunit/units/i386-win32 -o -FE. -o 
-FUunits/i386-win32 -o -di386 -o -dRELEASE 
--compiler=C:/svn/fpc-trunk/compiler/ppc386.exe --prefix=c:\lazarus\fpc\2.7.1\  
--unitinstalldir=c:\lazarus\fpc\2.7.1\/units/i386-win32/fcl-base -ie -d

Note the two spaces after the prefix. Which result in the error message
that the directory c:\lazarus\fpc\2.7.1 \bin coudn't be created. (Note
the space)

Can you reproduce that? I tried with a simple hello-world kind of
application and in that case I can't reproduce it either.

This is on Windows 7 in a virtual machine. (kvm)

Joost.

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

Re: [fpc-devel] Cross compile Linux-N9 (arm-linux)

2011-11-23 Thread Joost van der Sluis

On Mon, 2011-11-21 at 21:11 +0100, Felipe Monteiro de Carvalho wrote:
 On Mon, Nov 21, 2011 at 6:45 PM, Joost van der Sluis jo...@cnoc.nl wrote:
  This is really nice, I can just run LCL (qt) applications on that phone.
  Almost as easy as with WinCE.
 
  Joost. (Who is really happy with his new phone)
 
 The sad part is that the platform was abandoned by Nokia and now is no
 longer supported by any significant smartphones manufacturer. Buying a
 N9 was in my plans, but I gave up when Nokia went to the dark side of
 the force.

I don't care what Nokia does, I bought the N9 just out of fun. And fun
it is.

 I am working hard on LCL-CustomDrawn so hopefully in the not so
 distant future LCL apps will support Android too very reliably.
 Actually will support almost anything since the porting requirements
 will be so dramatically reduced in comparison to now.

Working with Android may be interesting for commercial reasons, but fpc
is also my hobby, and then Android is not interesting at all..

Joost.

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

[fpc-devel] Cross compile Linux-N9 (arm-linux)

2011-11-21 Thread Joost van der Sluis

Hi all,

I successfully cross-compiled 'Hello World' for my new Nokia N9. the N9
uses a Linux version. (Called Maemo-6 or Meego-Harmattan, depending on
who you ask)

But when I try to link to libc, (for example by adding the cwstrings
unit) the application crashes at startup (in _dl_init, called from
ld-linux.so)

Most probably because a invalid entry point, the linker gives the
following error:

Linking hello
/home/CNOC/joost/QtSDK/Madde/toolchains/arm-2009q3-67-arm-none-linux-gnueabi-x86_64-unknown-linux-gnu/arm-2009q3-67/bin/arm-none-linux-gnueabi-ld:
 warning: cannot find entry symbol 
cs=/home/CNOC/joost/QtSDK/Madde/targets/harmattan_10.2011.34-1/specs; 
defaulting to 8484
11 lines compiled, 0.2 sec

As you can see I use the toolchain (ld, as and libraries/so-files) from
the toolchain from the Nokia-sdk. I don't know what that specs file is
for, but it contains the following:

===
%rename cc1 old_cc1

*cc1:
-march=armv7-a -mcpu=cortex-a8 -mfpu=vfp -mfloat-abi=hard
-fno-omit-frame-pointer -fno-optimize-sibling-calls %(old_cc1)

%rename link old_link

*link:
-O 1 --hash-style=gnu -L=/usr/lib/gcc/arm-linux-gnueabi/4.4 %(old_link)
===

Any idea how to proceed?

Joost.

-- 
My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog

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

Re: [fpc-devel] Cross compile Linux-N9 (arm-linux)

2011-11-21 Thread Joost van der Sluis

On Mon, 2011-11-21 at 17:16 +0100, Joost van der Sluis wrote:

 But when I try to link to libc, (for example by adding the cwstrings
 unit) the application crashes at startup (in _dl_init, called from
 ld-linux.so)

Never mind, I've found the problem. The linker that I used was actually
a wrapper, which called another linker with some extra options. Those
options aren't applicable to Free Pascal.

Now it run. 

Joost. 
-- 
My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog

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

Re: [fpc-devel] Cross compile Linux-N9 (arm-linux)

2011-11-21 Thread Joost van der Sluis

On Mon, 2011-11-21 at 18:34 +0100, Joost van der Sluis wrote:
 Now it run. 

This is really nice, I can just run LCL (qt) applications on that phone.
Almost as easy as with WinCE.

Joost. (Who is really happy with his new phone)

-- 
My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog

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

Re: [fpc-devel] Segmentation fault for Firebird exception inside thread

2011-10-25 Thread Joost van der Sluis

On Tue, 2011-10-25 at 14:10 +0200, Ludo Brands wrote:
  I'm using FPC 2.2.5, so perhaps the error is already known, 
  but I did not find any solution in the web.
  
  I tested the code on Windows 32 bits and Linux 32 bits too, 
  but there everything seems ok.
  
 
 Tried your code on ubuntu 10.04 x86_64 using both libfbclient and libfbembed
 2.1, fpc 2.7.1. It doesn't create a SIGSEGV. Just a EIBDataBaseError.
 Problem seems to have been solved in the mean time.

Stefan, maybe that the debugger had problems showing the error. Please
try to run your application outside the debugger. Maybe that in that
case you'll see an EIBDatabaseError.

Joost.
-- 
My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog

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

Re: [fpc-devel] building fpc / fpmake and multicore cpu ?

2011-10-03 Thread Joost van der Sluis

On Sat, 2011-10-01 at 09:24 +0100, Martin wrote:
 I noticed, when I build fpc, then I get cpu usage between 70% and 100%. 
 So it appears that both cores of my pentium are used.
 
 But when a package is compiled using fpmake, then it drops to 50%, so 
 apparently only one core is used?
 
 Is that correct? Does the old Makefile driven compilation use both/all 
 cores, while packages done via fpmake, are using one core only?

Not completely, when you use 'make -Jx' with x1 then the old makefiles
can use multiple threads to actually compile. But it could be that some
overhead is done in a second thread?

As fpmake is now used in trunk the biggest disadvantage is that for each
unit that is compiled a instance of the compiler is invoked. If you add
'-bu' to the fpmake commandline, it outperforms the 'older' makefiles.

There's also a multi-threaded version of fpmake, but that's not comitted
yet.

Joost

-- 
My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog

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

Re: [fpc-devel] New Windows gdb-binary

2011-10-03 Thread Joost van der Sluis

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.

Joost.

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

RE: [fpc-devel] New Windows gdb-binary

2011-10-03 Thread Joost van der Sluis

On Sat, 2011-10-01 at 11:00 +0200, Pierre Free Pascal wrote:
  Did you use the mingw 7.3 patch that handles
 the windows style path containing ':'?

No.
 
   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...

Thanks. That was one of the issues I still had, without a clue how to
fix it.

Can you also think about this problem:
http://www.cygwin.com/ml/gdb/2011-10/msg3.html

Because I've got this problem now at two places (two different warnings)
already. The second warning is also in stock-fsf-gdb. I can't imagine
that the official GDB 7.3 also has this problem with nul-parameters and
fprintf.

Joost

-- 
My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog

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

RE: [fpc-devel] New Windows gdb-binary

2011-10-03 Thread Joost van der Sluis

On Mon, 2011-10-03 at 16:40 +0200, 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 Joost van der Sluis
  Envoyé : lundi 3 octobre 2011 16:29
  À : FPC developers' list
  Objet : RE: [fpc-devel] New Windows gdb-binary
  
  On Sat, 2011-10-01 at 11:00 +0200, Pierre Free Pascal wrote:
Did you use the mingw 7.3 patch that handles
   the windows style path containing ':'?
  
  No.
  
 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...
  
  Thanks. That was one of the issues I still had, without a clue how to
  fix it.
  
  Can you also think about this problem:
  http://www.cygwin.com/ml/gdb/2011-10/msg3.html
  
  Because I've got this problem now at two places (two different warnings)
  already. The second warning is also in stock-fsf-gdb. I can't imagine
  that the official GDB 7.3 also has this problem with nul-parameters and
  fprintf.
 
 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... 

I'll use TYPE_ERROR_NAME. Thanks for the hint. ;)

Joost.

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

Re: [fpc-devel] New Windows gdb-binary

2011-10-03 Thread Joost van der Sluis

On Mon, 2011-10-03 at 19:27 +0200, Florian Klämpfl wrote:
 Am 03.10.2011 16:23, schrieb Joost van der Sluis:
  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.
 
 Afaik it is generated by default.

You are right. I included it in this new version:
http://www.lazarussupport.com/gdb_lazarussupport_20111003b.zip
The libgdb.a file is not tested whatsoever, so I can't tell if it works.

The zipfile also contains some instructions how to build it, and all the
changes compared to the Archer branch on which is it was based.
This version includes some fixes for the several crashes that Martin
encountered and the changes for the Windows-paths that Pierre mailed.

Joost.



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

Re: [fpc-devel] New Windows gdb-binary

2011-10-02 Thread Joost van der Sluis

On Sat, 2011-10-01 at 09:08 +0200, Joost van der Sluis wrote:
 On Sat, 2011-10-01 at 01:05 +0100, Martin wrote:
  On 30/09/2011 23:23, Martin wrote:
   On 30/09/2011 14:02, Joost van der Sluis wrote:
   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
  
  
  
   It crashes when -Xe (external linker) was used. Also crashes with 
   stabs...
  
   I am not 100% sure, but it appears to choke on
   -data-evaluate-expression FPC_THREADVAR_RELOCATE_PROC
  
  Ok, seems to have big issues with strings in fields.
 
 Ow, man.. That's probably difficult again. While evaluating values, it
 does not 'recurse' into the structure, but uses all kinds of
 work-arounds. (For example: an array of strings wasn't working either)

It was easier then I thought. The recursive calls were ok, but you did a
'ptype class.stringprop'. But when evaluating the type, there was
object-address set (which is logical)

New version:
http://www.lazarussupport.com/gdb_lazarssupport_20111002.zip

There are more things that we need to discuss, though. 

For example, when I want to evaluate 'object.stringprop', Lazarus issues
a '-data-evaluate-expression object.stringprop^', which obviously won't
work with that '^' in the end.

Something similar when a method is called (from within the evaluation
window). Lazarus does 'ptype object.method()'. That doesn't work (could
be fixable, though) while calling '-data-evaluate-expression
object.stringprop()' directly will work.

Joost.



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

Re: [fpc-devel] New Windows gdb-binary

2011-10-02 Thread Joost van der Sluis

On Sun, 2011-10-02 at 14:29 +0100, Martin wrote:
 On 02/10/2011 14:05, Joost van der Sluis wrote:
  On Sat, 2011-10-01 at 09:08 +0200, Joost van der Sluis wrote:
  On Sat, 2011-10-01 at 01:05 +0100, Martin wrote:
  Ok, seems to have big issues with strings in fields. 
  Ow, man.. That's probably difficult again. While evaluating values, it
  does not 'recurse' into the structure, but uses all kinds of
  work-arounds. (For example: an array of strings wasn't working either)
  It was easier then I thought. The recursive calls were ok, but you did a
  'ptype class.stringprop'. But when evaluating the type, there was
  object-address set (which is logical)
 
  New version:
  http://www.lazarussupport.com/gdb_lazarssupport_20111002.zip
 
 Thanks, I will test.

(To test the function-calls you have to do 'set cp-abi gnu-v3' I forgot
to set that as the default. Will place a new version which does that
later)

  There are more things that we need to discuss, though.
 
  For example, when I want to evaluate 'object.stringprop', Lazarus issues
  a '-data-evaluate-expression object.stringprop^', which obviously won't
  work with that '^' in the end.
 
 Afaik it should fallback to omit it.
 
 Anyway, those gdb workarounds that Lazarus does, will be updated, as 
 soon as the major gdb crashes are gone.

btw: I could not reproduce the external-linker and stabs crashes. Can
you give me some more info?

 IIRC, Lazarus uses the ptype result, to detect if the 
 variable/expression, is of an internal pointer type (object, 
 dyn-array, string). If so, it will attempt the ^ postfix.
 
 This is important for:
 - objects, without the ^ gdb only reports the address, but with it, 
 all the values of all the fields are listed. (afaik this still aplies 
 iin dwarf 3)

Yes, when I changed that people started to complain. I don't know
anymore what the exact reason for those complaints was. Maybe because a
object really is a pointer, or that with this change it got impossible
to obtain the address.

And (also afaik) this behaviour is important, as it allows for 
 expressions like Obj1=Obj2 to work the way it is pascal-expectation. 

Maybe that this was the reason...

 Such expression are used in breakpoint-conditions.
 - dyn array: to be tested under dwarf 3, probably no longer needing the 
 ^. with dwarf2 dyn array do need the ^
 - strings: little tested, they are treated as dyn array of chars.
 
 Obviously, with dwarf3 strings may be improved, and the IDE will get 
 better detection.
 
 In dwarf2/stabs they are reported as ^(array of char) which could also 
 be dyn-array.
 It is possible to get the type-name, but:
 - the user may have aliased it: type MyAnsi = type Ansistring;
 - the user may have a local type type Ansistring = array of char; 
 (0-based)

We should find a way to detect if -gw3 is used. Then you don't need
those adaptations for strings anymore. Just do 'p variable', it will
always give the right result.

Joost.

-- 
My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog

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

1 2 3 4 5 >

1 - 100 of 457 matches

Mail list logo