Re: [fpc-pascal] Re: 2.6.0 for Solaris?

[Mark Morgan Lloyd]

microc...@zoho.com wrote:

On Wed, 09 May 2012 18:18:59 + Mark Morgan Lloyd wrote:


My main role is being a thorn in the side of the core developers when
something stops working :-) However I've previously offered to host a
(not very fast) system here for compilation etc., and the offer stands.


What SPARC box(es) do you have? I may be able to host Solaris development
systems if needed although the SPARC stuff would have to be scheduled since
I cannot leave them on all the time because of the huge noise and heat
factor. The Intel box is on most of the time.


I've got a range here: mostly U60 running "in anger", a U80, E4500, 
U10s, a U1, plus some museum pieces I can't find an OS for. I'm also one 
of very few people who've got an SS1000E running Linux SMP, but that's 
not a recent distro and because of library versions (**) I'm not sure 
what if any version of FPC I could get running on it.


** When a program is built, the (Linux) linker puts the actual filenames 
of the .so files it expects to find in the binary- not the names of any 
symlinks. That means that once you've built a binary using standard 
parameters, that binary /requires/ the same collection of .so versions 
that was on the development system... I managed to get around that to 
backport FPC from Solaris 10 to 8 but in general I think it's better to 
start off with a version that runs and work forwards.


I wholeheartedly agree that power, and in the Summer heat, is a massive 
problem. There's only so much we can afford, and even with substantial 
air conditioning things can get pretty unpleasant in my workroom and the 
adjacent machineroom. That's why I'm only able to offer U10s as 
always-up systems, Vincent used one of those for Lazarus two or three 
years ago and I've tried to test both FPC and Lazarus on Linux and 
Solaris fairly regularly since.



His point was that Slackware has a far more limited range of binaries and
libraries than do more popular distreaux such as Debian/Ubuntu, but it
has its uses.


Right you are.


Anyway, the particular glibc version was probably selected by the ld
linker when compiling the binaries on the builder's machine.



I'll check 2.7.1 on SPARC Solaris 8, 10 and Slackware 12 over the next
few days. I don't anticipate any problems, and in the interest of getting
the OP (who hasn't provided us with a more genteel handle) going I could
mail or FTP him tarballs as appropriate. 


If 2.6.0 is ok for Linux that is good enough for me as far as Slackware
goes. I may try to rebuild against my glibc or just forget about it on
Linux and concentrate on Solaris since I prefer to work on Solaris anyway.

I appreciate your offer for packages but since you or somebody else has
already pointed me to the buildfaq, I'll try this on my own and when I get
stuck I'll email the list again. Thanks again for all the help.


You might find it useful to go to the Mantis bug tracker and look at the 
SPARC-related bugs I've reported- use "View Issues", expand "Search", 
select "Mark Morgan Lloyd" from "Reporter" then "Use Filter". You might 
in particular need http://mantis.freepascal.org/view.php?id=18271 when 
getting your initial FPC binary installed on Solaris 10.


When you get to compiling, you might find it necessary to use a command 
line like this:


make NOGDB=1 OPT='-O- -gl'

What that does is tell it to not try to use the optional libgdb in the 
fp text-mode IDE, and it disables optimisation in the compiler binary 
(/not/ the compiler's ability to apply optimisation) so that if 
something goes wrong you can get a useful backtrace.


On Debian, you'll need [checks] build-essential, gdb, libgpmg1-dev, and 
some combination of libncurses5-dev and libncursesw5-dev. If you get as 
far as building Lazarus use trunk (on SPARC) and treat libgtk2.0-dev and 
possibly libqt4pas-dev as prerequisites, if those aren't available (e.g. 
on Slackware) I suggest we continue on the Lazarus mailing list.


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

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: 2.6.0 for Solaris? And other questions

[Mark Morgan Lloyd]

microc...@zoho.com wrote:

I screwed up the quoting here, sorry. Jeff didn't write all below, I think
some of it was Mark.

On Wed, 09 May 2012 18:01:43 -0400 Jeff Wormsley wrote:


And what, pray, is wrong with Slackware? :-)


Nothing :-) Once you Slack you never go back!

Most of the SPARC systems around here are Debian (plus one each of 
Solaris 8 and 10), but I've got Slackware 12 IIRC on an E4500 since 
the Debian installer wouldn't work. Good machine for testing 
multithreaded stuff on account of the number of CPUs.


Hah! I didn't even think of that. I've been thinking it would be nice to
have a SPARC port of Slackware but it hasn't been maintained.

How many sockets do you have on your E4500?


12, i.e. space for an I/O card and internal discs for booting. I prefer 
the SS1000 architecture, where each of the eight cards is identical so 
you can have 16x CPUs plus full I/O... in addition being a Xerox PARC 
design it has a certain pedigree ;-)


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

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: 2.6.0 for Solaris? And other questions

[Mark Morgan Lloyd]

Sven Barth wrote:

Am 09.05.2012 20:19, schrieb microc...@zoho.com:

There are no binaries provided by my distribution. It's Slackware! But
the question was, was it really necessary to use such a recent glibc?



It's a matter of what the libc version happens to be on the system that
was used to build libgdb, which is simply someone's personal machine.


Ok, but if that is what happened I would expect a lot of people not to be
able to run fp except maybe Fedora 16 or Gentoo users who always have the
latest stuff. I guess I am wrong though or you would already know 
about it.

Maybe it would be better to build on a non-bleeding edge system so people
with older distros and pieces could still run everything? I very seldom
upgrade but maybe everybody else does. I try to find a good working setup
and then don't change it much. That's kind of why I was asking about 
2.6.0
since it is the current release. I was planning on staying on that 
until I

had a really good reason not to.


The text mode IDE "fp" is not used that much on Unix based systems thus 
such problems regarding to recent/old libraries are not detected that 
easily. On other systems like OS/2 (where "fp" is used more often) and 
Windows there aren't such dependency problems.


Most users use a graphical IDE like Lazarus: 
http://www.lazarus.freepascal.org/


I agree. I harboured illusions at one point about being able to work out 
how fp was put together and tracking down some of the issues (mostly 
related to debugging, i.e. libgdb) but in practice I've gone with the 
flow and started using Lazarus.


Having said which, I think I've got fp running on all the systems here 
(with the possible exception of Solaris 8), and I've got libgdb running 
with all of those (with the exception of ARM Linux).


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

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: 2.6.0 for Solaris? And other questions

[microcode]

Thu, 10 May 2012 08:45:14 +0200 Sven Barth wrote

> The text mode IDE "fp" is not used that much on Unix based systems thus
> such problems regarding to recent/old libraries are not detected that
> easily.

That would explain it! But I saw fp once and I loved it, very Borland Turbo!

> Most users use a graphical IDE like Lazarus:
> http://www.lazarus.freepascal.org/ 

Thanks, I'll look. But I will probably be just as happy or happier with fp.


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

Re: [fpc-pascal] Re: 2.6.0 for Solaris? And other questions

[Tomas Hajny]

On Thu, May 10, 2012 08:45, Sven Barth wrote:
> Am 09.05.2012 20:19, schrieb microc...@zoho.com:
 There are no binaries provided by my distribution. It's Slackware! But
 the question was, was it really necessary to use such a recent glibc?
>>
>>> It's a matter of what the libc version happens to be on the system that
>>> was used to build libgdb, which is simply someone's personal machine.
>>
>> Ok, but if that is what happened I would expect a lot of people not to
>> be
>> able to run fp except maybe Fedora 16 or Gentoo users who always have
>> the
>> latest stuff. I guess I am wrong though or you would already know about
>> it.
>> Maybe it would be better to build on a non-bleeding edge system so
>> people
>> with older distros and pieces could still run everything? I very seldom
>> upgrade but maybe everybody else does. I try to find a good working
>> setup
>> and then don't change it much. That's kind of why I was asking about
>> 2.6.0
>> since it is the current release. I was planning on staying on that until
>> I
>> had a really good reason not to.
>
> The text mode IDE "fp" is not used that much on Unix based systems thus
> such problems regarding to recent/old libraries are not detected that
> easily. On other systems like OS/2 (where "fp" is used more often) and
> Windows there aren't such dependency problems.
 .
 .

Also, e.g. people using Debian would probably use fp from the .deb
packages rather than the .tar.gz distribution. The .deb packages are
created elsewhere and their dependencies are compatible with the
appropriate Debian version.

Tomas


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

Re: [fpc-pascal] SIGFPE with SameValue()

[t . wieckowski]

it seams that MaxFloat get MaxDouble (FPC_HAS_TYPE_DOUBLE is defined)
but SameValue uses as Single when overload.
Works with SameValue(double(a),double(b),double(0)).

best regards
Tomek
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] SIGFPE with SameValue()

[Torsten Bonde Christiansen]

On 2012-05-10 10:45, t.wieckow...@gmail.com wrote:

it seams that MaxFloat get MaxDouble (FPC_HAS_TYPE_DOUBLE is defined)
but SameValue uses as Single when overload.
Works with SameValue(double(a),double(b),double(0)).

best regards
Tomek
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

How can that be, since I use Extended as type?

Regards,
Torsten.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] SIGFPE with SameValue()

[Jonas Maebe]

Torsten Bonde Christiansen wrote on Thu, 10 May 2012:


On 2012-05-10 10:45, t.wieckow...@gmail.com wrote:

it seams that MaxFloat get MaxDouble (FPC_HAS_TYPE_DOUBLE is defined)
but SameValue uses as Single when overload.
Works with SameValue(double(a),double(b),double(0)).


How can that be, since I use Extended as type?


http://bugs.freepascal.org/view.php?id=21199


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

Re: [fpc-pascal] SIGFPE with SameValue()

[Torsten Bonde Christiansen]

On 2012-05-10 11:16, Jonas Maebe wrote:


Torsten Bonde Christiansen wrote on Thu, 10 May 2012:


On 2012-05-10 10:45, t.wieckow...@gmail.com wrote:

it seams that MaxFloat get MaxDouble (FPC_HAS_TYPE_DOUBLE is defined)
but SameValue uses as Single when overload.
Works with SameValue(double(a),double(b),double(0)).


How can that be, since I use Extended as type?


http://bugs.freepascal.org/view.php?id=21199

Thanks. I can see that addid 0.0 to SameValue solves the problem. :)

Regards,
Torsten.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: 2.6.0 for Solaris?

[microcode]

On Thu, 10 May 2012 07:27:22 + Mark Morgan Lloyd wrote:

> microcode wrote:

> > What SPARC box(es) do you have? I may be able to host Solaris
> > development systems if needed although the SPARC stuff would have to be
> > scheduled since I cannot leave them on all the time because of the huge
> > noise and heat factor. The Intel box is on most of the time.

> I've got a range here: mostly U60 running "in anger", a U80, E4500, U10s,
> a U1, plus some museum pieces I can't find an OS for. I'm also one of
> very few people who've got an SS1000E running Linux SMP, but that's not a
> recent distro and because of library versions (**) I'm not sure what if
> any version of FPC I could get running on it.

The E4500s are monsters, aren't they? I'd like to have one but I'm out of
space. I'd like an Ultra 80 as well. I could find a spot for one of those.

I've got a stack of Sun Fire 210s and 440s. They're very nice but they're
in various states of needing odds and ends and I don't have much disk
capacity but plenty for development machines. The 210s are two bangers and
are fast enough for building large apps in a reasonable timeframe. The 440s
are slow but they're unstoppable, they run like a freight train, nothing
bothers them. I'm hoping to get a pile of RAM but so far all the promises
haven't panned out. I have a bad UPS and when I get that fixed I'll have
more machines available to come online whenever needed.

> ** When a program is built, the (Linux) linker puts the actual filenames
> of the .so files it expects to find in the binary- not the names of any
> symlinks. That means that once you've built a binary using standard
> parameters, that binary /requires/ the same collection of .so versions
> that was on the development system 

Right you are. Before reading your post I built glibc-2.14 and tried fp
again but no joy..

>. ... I managed to get around that to backport FPC from Solaris 10 to 8
>but in general I think it's better to start off with a version that runs
>and work forwards. 

Agreed.

> I wholeheartedly agree that power, and in the Summer heat, is a massive
> problem. There's only so much we can afford, and even with substantial
> air conditioning things can get pretty unpleasant in my workroom and the
> adjacent machineroom. That's why I'm only able to offer U10s as always-up
> systems, Vincent used one of those for Lazarus two or three years ago and
> I've tried to test both FPC and Lazarus on Linux and Solaris fairly
> regularly since. 

Sun makes awfully nice boxes and Solaris is a very nice development
platform. I hope the guys will keep FPC going on Solaris. There are many
Solaris 10 on Sun fans.

> > I appreciate your offer for packages but since you or somebody else has
> > already pointed me to the buildfaq, I'll try this on my own and when I
> > get stuck I'll email the list again. Thanks again for all the help.

> You might find it useful to go to the Mantis bug tracker and look at the
> SPARC-related bugs I've reported- use "View Issues", expand "Search",
> select "Mark Morgan Lloyd" from "Reporter" then "Use Filter". You might
> in particular need http://mantis.freepascal.org/view.php?id=18271 when
> getting your initial FPC binary installed on Solaris 10. 

Thanks for the info.


> When you get to compiling, you might find it necessary to use a command
> line like this: 
>
> make NOGDB=1 OPT='-O- -gl'
>
> What that does is tell it to not try to use the optional libgdb in the fp
> text-mode IDE, and it disables optimisation in the compiler binary (/not/
> the compiler's ability to apply optimisation) so that if something goes
> wrong you can get a useful backtrace.

Thanks.


> On Debian, you'll need [checks] build-essential, gdb, libgpmg1-dev, and
> some combination of libncurses5-dev and libncursesw5-dev. If you get as
> far as building Lazarus use trunk (on SPARC) and treat libgtk2.0-dev and
> possibly libqt4pas-dev as prerequisites, if those aren't available (e.g.
> on Slackware) I suggest we continue on the Lazarus mailing list. 

I don't think I'll spend any further time looking at Linux, as the
Slackware copy of 2.6.0 seems to work for a few small samples. If I can't
get fp built on Solaris SPARC or if it doesn't work on Solaris Intel (will
check that next week) then I'll think about what to do next, probably just
live with Emacs. If I get bored and my list of things to do ever gets small
enough I'll look at rebuilding 2.6.0 Linux under 2.6.0 with my glibc.

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

[fpc-pascal] Re: 2.6.0 for Solaris?

[microcode]

On Thu, 10 May 2012 07:32:47 + Mark Morgan Lloyd wrote:

> > How many sockets do you have on your E4500?
>
> 12, i.e. space for an I/O card and internal discs for booting.

Woohoo! That's a lot of CPUs. I'll bet you can heat your home with that in
the winter.

> I prefer the SS1000 architecture, where each of the eight cards is
> identical so you can have 16x CPUs plus full I/O... in addition being a
> Xerox PARC design it has a certain pedigree ;-) 

I'm not familiar with that one.

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

[fpc-pascal] fpc & arm-embedded interrupts

[Koenraad Lelong]

Hi,

I'm working on an embedded-arm application. I do want to use interrupts 
but I don't find how to easily setup the interrupt-handlers.
In the startup code in C, I see default handlers defined with the 
keyword WEAK. Looking around, I found that this means that if one 
defines a function with the same name, that will be used instead of the 
default-handler. The start-address of that new function will be entered 
in the interrupt-vector table in flash.
Is something similar possible with fpc ? Looking in the 
fpc-startup-code, the rtl, I don't see that, but that could be me.
Or do I have to modify the rtl for every project I will be making ? What 
I did see I think, in some rtl-units for arm-embedded, is that there 
seems to be a contruction to put the start-address of the main 
error-handlers in RAM. Would that be the only way to have interrupts ?


Thanks for any help,

Regards,

Koenraad Lelong.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: 2.6.0 for Solaris?

[Tomas Hajny]

On Thu, May 10, 2012 13:22, microc...@zoho.com wrote:
 .
 .
> Sun makes awfully nice boxes and Solaris is a very nice development
> platform. I hope the guys will keep FPC going on Solaris. There are many
> Solaris 10 on Sun fans.
 .
 .

FPC support of individual platforms depends on availability of volunteers
interested and capable of supporting these platforms. FPC can target
really many platforms nowadays, but this increasing number cannot be
supported with constant number of developers. Someone from the Sun fans
has to step in, otherwise the support cannot be guaranteed in the long
term.

Tomas


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

Re: [fpc-pascal] fpc & arm-embedded interrupts

[Jeppe Græsdal Johansen]

The easiest way to do interrupt processing in Cortex-M3 processors(which 
I assume you are using), is to create an interrupt vector table in SRAM 
and then change the NVIC to use that. That way you can point to the 
interrupt handlers at runtime.


It's true that the normal way of doing it is with weak linking as you 
write, but there's no support for that directly in FPC currently, so 
it'll have to be done with external assembly. It is doable, but noone 
has made it entirely yet.


Den 10-05-2012 13:56, Koenraad Lelong skrev:

Hi,

I'm working on an embedded-arm application. I do want to use 
interrupts but I don't find how to easily setup the interrupt-handlers.
In the startup code in C, I see default handlers defined with the 
keyword WEAK. Looking around, I found that this means that if one 
defines a function with the same name, that will be used instead of 
the default-handler. The start-address of that new function will be 
entered in the interrupt-vector table in flash.
Is something similar possible with fpc ? Looking in the 
fpc-startup-code, the rtl, I don't see that, but that could be me.
Or do I have to modify the rtl for every project I will be making ? 
What I did see I think, in some rtl-units for arm-embedded, is that 
there seems to be a contruction to put the start-address of the main 
error-handlers in RAM. Would that be the only way to have interrupts ?


Thanks for any help,

Regards,

Koenraad Lelong.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


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

[fpc-pascal] Re: Runs correctly when debugging.

[Guillermo Martínez Jiménez]

> No, you have to use pchar.  I would also define ALLEGRO_BITMAP as an
> empty record, to be clear that it's an opaque type:
>
> {$packrecords c}
>  TAllegroBitmap = record
>  end;
>  PAllegroBitmap = ^TAllegroBitmap;
>
> Thus:
>
> function al_load_bitmap(const filename: pchar): PAllegroBitmap; cdecl;
> external ALLEGRO_LIB_NAME;
>
> Make sure you use {$packrecords c}.  Use the types in unit "ctypes",
> e.g. cint, cfloat, cdouble.  This will ensure the variables are the same
> size and work on all architectures.
>
> Henry

Ok, then I should revise all the "STRING" parameters, as well as all
pointer types and "ctypes".

Thanks for the advices.
Guillermo.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: 2.6.0 for Solaris?

[microcode]

On Thu, 10 May 2012 14:07:47 +0200 (CEST) "Tomas Hajny" wrote:

> On Thu, May 10, 2012 13:22, microcode wrote:

> > Sun makes awfully nice boxes and Solaris is a very nice development
> > platform. I hope the guys will keep FPC going on Solaris. There are
> > many Solaris 10 on Sun fans.

>
> FPC support of individual platforms depends on availability of volunteers
> interested and capable of supporting these platforms. FPC can target
> really many platforms nowadays, but this increasing number cannot be
> supported with constant number of developers. Someone from the Sun fans
> has to step in, otherwise the support cannot be guaranteed in the long
> term. 

Yeah, that's obvious. I'm sure anybody who was capable would help. All I
can offer at this point is development systems but that doesn't seem to be
the problem. How much platform dependent code is there? I would think if
the main product works on i386 or AMD64 for example then there isn't much
to do except build on the other targets? 

Is it a matter of not having developers for the specific platform or not
having anybody to build it for a specific platform?



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

Re: [fpc-pascal] Re: 2.6.0 for Solaris?

[Tomas Hajny]

On Thu, May 10, 2012 15:20, microc...@zoho.com wrote:
> On Thu, 10 May 2012 14:07:47 +0200 (CEST) "Tomas Hajny" wrote:
>> On Thu, May 10, 2012 13:22, microcode wrote:
>
>> > Sun makes awfully nice boxes and Solaris is a very nice development
>> > platform. I hope the guys will keep FPC going on Solaris. There are
>> > many Solaris 10 on Sun fans.
>
>>
>> FPC support of individual platforms depends on availability of
>> volunteers
>> interested and capable of supporting these platforms. FPC can target
>> really many platforms nowadays, but this increasing number cannot be
>> supported with constant number of developers. Someone from the Sun fans
>> has to step in, otherwise the support cannot be guaranteed in the long
>> term.
>
> Yeah, that's obvious. I'm sure anybody who was capable would help. All I
> can offer at this point is development systems but that doesn't seem to be
> the problem. How much platform dependent code is there? I would think if
> the main product works on i386 or AMD64 for example then there isn't much
> to do except build on the other targets?
>
> Is it a matter of not having developers for the specific platform or not
> having anybody to build it for a specific platform?

There are operating system specific parts in both the compiler
(i_sunos.pas and t_sunos.pas being the most visible ones but not
necessarily the only ones) and the RTL. Moreover, talking about Solaris on
Sun, there are also parts of the compiler and RTL specific for the SPARC
platform. There are also packages which may occasionally need some
platform specific adaptations too (not even mentioning the examples,
etc.).

All of this requires some testing at least before releases and obviously
also resolution of bugs specific to the particular platform (which may
involve also debugging problems reported for the particular platform to
the point where it is clear that the problem lies in some shared code).

Preferably, the maintainer should also run the testsuite regularly and
watch for possible deviations in order to keep quality under control and
avoid last minute surprises either before or even after new releases.

Tomas


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

Re: [fpc-pascal] Re: 2.6.0 for Solaris?

[Mark Morgan Lloyd]

microc...@zoho.com wrote:

On Thu, 10 May 2012 14:07:47 +0200 (CEST) "Tomas Hajny" wrote:


On Thu, May 10, 2012 13:22, microcode wrote:



Sun makes awfully nice boxes and Solaris is a very nice development
platform. I hope the guys will keep FPC going on Solaris. There are
many Solaris 10 on Sun fans.



FPC support of individual platforms depends on availability of volunteers
interested and capable of supporting these platforms. FPC can target
really many platforms nowadays, but this increasing number cannot be
supported with constant number of developers. Someone from the Sun fans
has to step in, otherwise the support cannot be guaranteed in the long
term. 


Yeah, that's obvious. I'm sure anybody who was capable would help. All I
can offer at this point is development systems but that doesn't seem to be
the problem. How much platform dependent code is there? I would think if
the main product works on i386 or AMD64 for example then there isn't much
to do except build on the other targets? 


Is it a matter of not having developers for the specific platform or not
having anybody to build it for a specific platform?


You might find the fpc-devel mailing list interesting, although I think 
that everybody would admit that there is a shortage of documentation for 
the entrails of the compiler.


You might also find looking at the fpcsrc/compiler and fpcsrc/rtl trees 
in the source interesting, noting in particular the way that the latter 
at least /attempts/ to separate OS- and CPU-specific code.


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

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] FPC + valgrind massif problems

[Michalis Kamburelis]

Hi,

I wanted to debug where my program uses the most memory. (There are no 
memory leaks, but I want to optimize memory usage on some large inputs. 
As the code is quite large, simply guessing which part is responsible 
becomes quite hard :) In the past, I happily used valgrind's massif tool 
for such job, and it worked like a charm. But now, FPC 2.6.0 with 
valgrind 3.7.0, it seems valgrind/massif has problems:


$ fpc -gv trivial_alloc.pas
$ valgrind --tool=massif ./trivial_alloc

--7286-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 
(SIGSEGV) - exiting

--7286-- si_code=1;  Faulting address: 0xFFF7;  sp: 0x6298914c
valgrind: the 'impossible' happened:
   Killed by fatal signal

(Full output and trivial_alloc.pas attached.)

The code is compiled with -gv option. It works very fine with valgrind's 
callgrind tool. So I suspect this is a problem with valgrind, 
specifically massif, not related to FPC. Also, it seems to fail the same 
way with older/newer FPC versions (I tried 2.2.4, 2.4.4, 2.6.0, and 
2.7.1 from today 2012-05-11). Probably, some valgrind version broke 
massif for FPC binaries.


So, questions:

1. I want to report this as massif's bug. Any ideas what more 
information should I provide to valgrind's developers? I don't know if 
they are familiar with FPC. And simple C examples work fine, so it's 
probably something specific in FPC binaries.


- Maybe this problem is already reported?

- Maybe there's a workaround? IOW, can someone successfully use massif 
with FPC programs?


2. Is there any other reliable memory profiler for FPC? As you can swap 
memory manager in Pascal, and FPC can give you a backtrace, I suppose 
it's quite possible to just write a unit that works between your program 
and standard memory manager, and tracks memory usage this way. This will 
only measure memory use of Pascal code (external libs don't go through 
FPC memory manager), but that would be very fine for me --- I know 
(well, I'm 99% sure) that my Pascal code is the main memory eater here.


I didn't find any (good and maintained) memory profiler mentioned on 
http://wiki.lazarus.freepascal.org/Profiling#Memory_Profiling . (I tried 
FpProfiler, but it depends on inserting instrumentation code into Pascal 
sources. That's actually a very nice idea, but it means it's closely 
tied to what fcl-passrc can handle. And current fcl-passrc still lacks a 
couple of features (reported). Also FpProfiler seems to use an older, 
local fcl-passrc version.)


Thanks,
Michalis
==7310== Massif, a heap profiler
==7310== Copyright (C) 2003-2011, and GNU GPL'd, by Nicholas Nethercote
==7310== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==7310== Command: ./trivial_alloc
==7310== 
--7310-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - 
exiting
--7310-- si_code=1;  Faulting address: 0xFFF7;  sp: 0x627fb14c

valgrind: the 'impossible' happened:
   Killed by fatal signal
==7310==at 0x38028524: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==by 0x38060AB6: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==by 0x380635FD: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==by 0x38024CA2: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==by 0x38025542: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==by 0x3807560D: ??? (in /usr/lib/valgrind/massif-x86-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==7310==at 0x402428C: free (in 
/usr/lib/valgrind/vgpreload_massif-x86-linux.so)
==7310==by 0x416D4C4: __libc_freeres (in 
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so)
==7310==by 0x4020466: _vgnU_freeres (in 
/usr/lib/valgrind/vgpreload_core-x86-linux.so)
==7310==by 0x805F113: SYSTEM_SYSTEM_EXIT (in /tmp/trivial_alloc)
==7310==by 0x8058819: SYSTEM_DO_EXIT (in /tmp/trivial_alloc)
==7310==by 0x805FA66: SI_PRC__FPC_PROC_START (in /tmp/trivial_alloc)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.
var
  P: Pointer;
begin
  P := GetMem(1000);
end.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Unicodestrings and Assign(File)

[Noah Silva]

Hi,

According to what I have read (and I always wonder how up to date
documentation is with respect to the state of the compiler and libraries),
all standard library functions (Which would include system.assign) are
still using the "local" encoding.  For Mac OS X, luckily, this means UTF8.

Thus, the only question would be whether you have to manually convert a
UnicodeString to a UTF8String or not.

If you don't trust it, you can build an overload version of assign to
convert the string and call the old one, but note that in Windows the local
encoding will be different than UTF8 in many cases (hence the wide version
of the calls will be better), and in Linux it may be UTF-8 or something
else) - so you can't always convert UTF16 to UTF8, call the old functions,
and expect it to work on all OSs.

Still, fixing Assign/Reset/Rewrite would be better than using Unix calls,
because you could submit a patch to save everyone else trouble in the
future.

This kind of stuff is a real pain all the time, and not even that hard to
fix, I am not sure why the "issues" remain - but perhaps there aren't
enough volunteers with enough time to work on it.

I have done a lot of Unicode work, so if you have other problems let me
know, I may already have written code to handle whatever the issue is, and
would be happy to share it.

Thank you,
 Noah Silva

2012/5/10 Jürgen Hestermann 

> Is it (already) possible to use Unicodestrings for file paths?
> I was able to access long paths (with many hundreds of characters)
> in the windows API functions FindFirstFileW (with Win32_Find_DataW
> data type) but I failed to open such files with Assign(File)/reset.
> Are they converted to (one byte) Ansistring internally?
> Am I forced to use CreateFile or similar function to open such files?
>
> __**_
> fpc-pascal maillist  -  
> fpc-pascal@lists.freepascal.**org
> http://lists.freepascal.org/**mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC + valgrind massif problems

[Sven Barth]

Am 11.05.2012 02:40, schrieb Michalis Kamburelis:

2. Is there any other reliable memory profiler for FPC? As you can swap
memory manager in Pascal, and FPC can give you a backtrace, I suppose
it's quite possible to just write a unit that works between your program
and standard memory manager, and tracks memory usage this way. This will
only measure memory use of Pascal code (external libs don't go through
FPC memory manager), but that would be very fine for me --- I know
(well, I'm 99% sure) that my Pascal code is the main memory eater here.

I didn't find any (good and maintained) memory profiler mentioned on
http://wiki.lazarus.freepascal.org/Profiling#Memory_Profiling . (I tried
FpProfiler, but it depends on inserting instrumentation code into Pascal
sources. That's actually a very nice idea, but it means it's closely
tied to what fcl-passrc can handle. And current fcl-passrc still lacks a
couple of features (reported). Also FpProfiler seems to use an older,
local fcl-passrc version.)


You could try whether heaptrc is of any help for you (see here: 
http://www.freepascal.org/docs-html/rtl/heaptrc/usage.html ). If not it 
might at least provide a starting point if you should decide to write a 
custom memory profiler. Otherwise I don't know of any FPC based memory 
profilers.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal