Now: I have downloaded evaluation version of intel VTune 8.0 and tried to debug/optimize an application with it. It does not recognize symbols in FPC module (function names etc., source is not supported too). Still, it does work with Delphi, for example.

History: Long ago someone complained about some other problems with vtune-FPC and was answered, that they have supported languages and compilers (that day Delphi was not among them), and that they will answer something only on premier support intel site. It concerned old versions of both FPC and vtune.

My question: does anyone know, whether vtune can be tuned to work with FPC (at list on function names level) or not?

Remark: of course I don't ask here for vtune support, I ask about FPC tools. As far as I know, FPC does not have any profiler under win32 without cygwin.

Пётр Косаревский wrote

My question: does anyone know, whether vtune can be tuned to work with FPC (at list on function names level) or not?

Afaik not because vtune for windows supports no open debugging information format on windows.

Remark: of course I don't ask here for vtune support, I ask about FPC tools. As far as I know, FPC does not have any profiler under win32 without cygwin.

Last time I used gprof on win32, it worked fine?

Sorry, eight questions ahead (first two are important to me).

đŁÔŇ ëĎÓÁŇĹ×ÓËÉĘ wrote

Sorry, eight questions ahead (first two are important to me).

.
.

Just guessing here: Most probably libc.dll? Better to be answered by someone else.

Is it supposed, that I integrate cygwin with FPC or something?

No, except that you have to provide its runtime libraries.

Is it normal, that FPC from almost fresh base_w32... and fpc-2.0.3.i386-win32... required "as.exe" and "ld.exe" (I copied them from slightly older ones)?

I'd say so - if you're talking about snapshots, these tools are not included in them (as opposed to releases).

Is it OK, that after recent FPC update I have to add "-Sg" for my pretty GOTO (It is objfpc mode, no extra option is required under Delphi)?

Use -Mdelphi (or {MODE DELPHI}) if you want compatibility to Delphi. Use of GOTO (and some other constructs supported by Delphi) isn't considered a good programming practice, so it isn't supported by default in native FPC modes. If you want to use GOTO in these modes, you need to supply -Sg explicitely.

Is it normal, that with e.g. "-va" switch I see verbosely what was processed before "-va" switch?

I'm not sure if I understand what you meant here?

Should I bump the "fixed" bug about uncommented compiler option "-Op4" (it is uncommented in both 2.0.3 and 2.1.x versions)?

I guess it would help to be more specific here - what exactly is wrong, please?

Is it sufficient to build 2.1.x and rename one of "fpc.exe" to operate both release and development versions (I didn't try, but it seems that the one ppc386 would be run)?

That depends. It could work if you provide proper fpc.cfg in the compiler directory (and no other fpc.cfg exists in other directories) and if you make sure to use different output directories for compilation of your own units.

Should I split this message?

Not necessarily if you don't mind receiving answers in many pieces (different people responding to different parts). ;-)

Regards

Tomas

Пётр Косаревский wrote: > Sorry, eight questions ahead (first two are important to me).

Well, only "WHAT I NEED TO RUN GPROF UNDER WIN32?" and "WHY "cannot find -lc" WHEN COMPILING WITH GPROF SUPPORT?" are real questions. Others were like minor info/bug reporting (not important to me).

Well (guess), if you mean, that libc.dll is a part of cygwin, it's not a bad idea, but "-lc" thing doesn't look like a rebus or a charade, it's like an enigma:)

> fpc-2.0.3.i386-win32... required "as.exe" and "ld.exe" (I copied them from I'd say so - if you're talking about snapshots, these tools are not included in them (as opposed to releases).

You are probably right!
But releases and snapshots don't differ much in their size, so I didn't expect that about 3% (as.exe and ld.exe) would be dropped intentionally (because they are needed for functionality). On the other hand, these utilities are not made by FPC folk. It seems to be the reason for me...

Well, IT CHANGED, I didn't need to use this option before, it contradicts at least my expectations of objfpc mode. If you have a little arithmetical procedure you don't want to write in assembler (by the way, assembler is not interoperable), GOTO is a good thing. GOTO do exists in PASCAL syntax, and I use it on my own risk. I even saw this hint in compiler output, but don't understand the reason for this change (except trying to complicate compilating to user). I find overcomplicating source with {$IFDEF}-s more confusing, than labels.

> Is it normal, that with e.g. "-va" switch I see verbosely what was > processed before "-va" switch? I'm not sure if I understand what you meant here?

It's nonsense: if it is process in time, there should be no extra (verbose) messages before processing "-va" switch, because compiler is not yet in verbose mode. I believe, some developers do find that remark hackneyed.

> Should I bump the "fixed" bug about uncommented compiler option "-Op4" (it > is uncommented in both 2.0.3 and 2.1.x versions)? I guess it would help to be more specific here - what exactly is wrong, please?

See bug #.

I just wanted to avoid experiments and asked for solution:)

Well, you are the first to answer and the only important question is (now about gprof) :(

-lc means "link the library with the name 'c'", and this library will most likely be called either libc.a or libc.dll, and be part of the cygwin distribution. But you don't have to install an entire cygwin environment and/or use the compiler in it. Just put its libc.a/.dll somewhere and make sure the compiler can find it by passing its directory via -Fl

The reason is that snapshots are only intended to install over releases, and that it doesn't make sense to include those same utilities every time.

The only thing that changed was that -Sg is now on by default in Delphi and TP modes. It was previously always off by default in all modes, so nothing changed for the other modes. It is however turned on by the default fpc.cfg file.

So if somethign changed, it's probably because your fpc.cfg configuration files was changed or is not found by your current compiler (maybe you installed the snapshot in a separate directory, and I don't think there is a global location under Windows where we put an fpc.cfg -- releases put the fpc.cfg file in the same directory as the compiler under Windows).

The command line options are processed twice, and the first time some general/global options which influence the parsing of the rest of the options are picked out. -va is one of those.

Jonas

Sorry, I got it (from bug reports 2888, 4342). I don't have to install cygwin, I only need runtime libraries: libc.dll and may be something more.

as,ld question: the answer is in bug report 4462. However, searching bugs or even browsing them is not a good option.

Bug number is 4929.

Jonas

Thank you, it was very clear (except bug 4929, and I can kinda answer that question myself: probably if -CpPENTIUM4 is specified, optimizations are automatically for Pentium4).

đŁÔŇ ëĎÓÁŇĹ×ÓËÉĘ wrote

> đŁÔŇ ëĎÓÁŇĹ×ÓËÉĘ wrote:

.
.

The error message is an output of ld.exe, not FPC. ld.exe shouldn't be hopefully needed any more with the internal linker.

.
.

If you want to stay on the safe side, change your PATH setting to only refer to one version at a time (e.g. by calling fpc.exe from a script). You still need to fulfill the conditions mentioned above. Is there still something which should be clarified in more detail?

Regards

Tomas

đŁÔŇ ëĎÓÁŇĹ×ÓËÉĘ wrote:
.
.

as,ld question: the answer is in bug report 4462. However, searching bugs or even browsing them is not a good option.

No - first of all, the answer is on the top of the snapshot download page (http://www.freepascal.org/develop.html): "Note: There is no support for the development versions.". In other words: don't use snapshots (and only stick to official releases) if you don't know what you are doing.

Thanks for the reference, but it is still not clear what is your issue at the moment. As far as I can see, the current code gives a warning if you supply "-Op4", this value is ignored and the help pages don't list this as a valid option. So my statement is still the same - could you be more specific what is wrong, please?

Tomas

ON TOPIC:
maybe shipping with FPC cygwin runtime libraries for gprof wouldn't harm? Because:
1. Some are shipped (for FP --- IDE)
2. If I am right, libc, libgcc, libgmon and libkernel32 are needed, they shouldn't be weightier than some rarely used binary utils
3. Full CYGWIN is not required (as I guess, MINGW is more appropriate [its rtl], isn't it?)
4. -pg is a compiler option, not some external feature implying installation of something

BRANCH:

> Bug number is 4929. a valid option. So my statement is still the same - could you be more specific what is wrong, please? Tomas

Well, it is not a bug.

I even submitted it as compatibility or something. I do call it a bug, because it was marked "Fixed", not "Not a bug".

BUT:
2.0.3 2006.4.20 does not emit warning, nor do I see one in compiler messages file. (Maybe you mean "still BUGGY maximum optimize", Ox? [don't mix with older comments about "still BUGGY!!!" register optimizations])

Sorry for inconveniences.

These are pretty big when taken together.

3. Full CYGWIN is not required (as I guess, MINGW is more appropriate [its rtl], isn't it?) 4. -pg is a compiler option, not some external feature implying installation of something

There is no other way than to have it as a compiler option, since the compiler must generate special code for it. Similarly, -gv implies that you will use Valgrind, but that does not mean we're going to ship Valgrind with the compiler.

That said, it may make sense to ship those libraries on Windows, since most people won't have them. An optional downloadable package would probably make more sense though.

Jonas

These are pretty big when taken together. ... ... An optional downloadable package would probably make more sense though.

Yes. Hint, link and package/link to smallest possible set of libraries would be better. I am not experienced with many things, so this was pretty confusing ("can't find -lc" --- maybe I'd decipher libc, but "-"...).

No way! I can compile with "-gv", I don't have valgrind, compiler/linker do not complain.

PS.
1. Well, I don't know whether it's really ".exe" with valgrind support, because I had issues [and reported them], for example, with external assemblers: compile successful, application [otherwise working] immediately fails.)

2. I have already reported: "-gd" causes access violation by compiler (still in 2.0.3 2006.4.20).

As already mentioned by Jonas - yes, we should probably make it available somehow, at least as a standalone package. Note that we don't ship other static libraries either (sorry for a previous confusion - it's libc.a as correctly pointed out by Jonas, not libc.dll) - the main reason being that we can't keep in sync with their development (note that this is the case for libgdb.a needed for our IDE as well). OTOH, if we ship gprof.exe, we should probably ship the needed libraries and vice versa, it doesn't make too much sense as it is now...

OK, _now_ I see what is wrong. The bug is closed as fixed in 2.0.3, whereas in reality it was only fixed in 2.1.1. So either the fixed version should be changed in the bug report, or we should add another line to errore.msg in the fixes branch. Doing the latter is really a cosmetic change and should have no side effects, hopefully, so it might be probably the better solution. The only thing I'm not sure about is whether it might not have impacts to the possibility of merging from trunk - anybody?

Tomas

for libgdb.a needed for our IDE as well). OTOH, if we ship gprof.exe, we should probably ship the needed libraries and vice versa, it doesn't make too much sense as it is now...

By the way: I don't use IDE (it is not handy due to many issues that are not bugs), but when I tried, it completely freezes (it worked before upgrade to 2.0.3 2006.4.20) after pressing mouse button (winxpsp2, both fullscreen and window modes). If someone can acknowledge, please submit it as a bug.

Why did I write it? Because I don't have libgdb.a (neither did I with 2.0.2).

In my school days compilers had something like "filelist.txt" in "bin" directory. (Neither Delphi7, nor VC7 [which I don't use, but checked for this feature] do have such a file.)

I believe, that something like this is not very useless. For example, if you use command line "zip" and "unzip", older versions shipped with FPC can do harm (like many other utilities, assembler included).

It would be great to know what utility is needed and what for (and a little hint for not shipped ones, like libc.a discussed). Nothing lengthy, just like "cygwin1.dll part of CYGWIN ver. 1.5.12, ___for FP (IDE), GDB, GPROF and ...___ dlltool.exe part of GNU binary utilities, ver. 2.15.91, 20040904, __for PPC386 (Compiler) on linking stage___"

Of course, such a thing can slightly help even developers.

Some hints for older versions that are required would be great (when newer version has incompatible command line parameters, for example). The reason: user (I) can already use newer version and it can be in search path...

PS: compiler mentions dlltool bug with short var names (1 character?). isn't this bug corrected in newer version of dlltool?

As Tomas said, this error is emitted by the linker, not by our compiler. The compiler, unless with an internal linker, is completely oblivious to which libraries you have or don't have. And with good reason: it shouldn't have to know anything about that, since those are the linker's domain. Separation of concerns.

But the result is useless without Valgrind (no more useful than a regularly compiled binary at least), just like compiling with -gd is useless without the gprof. It's just a cosmetic difference; in principle it's exactly the same thing.

Jonas

But the result is useless without Valgrind (no more useful than a regularly compiled binary at least), just like compiling with -gd is Jonas

Just as compiler without a linker.

What about user friendly filelist I mentioned?

(Now that I know why and how cygwin is needed, I'll install it and look at the files to save and files to delete... I didn't find easy to install cygwin libraries pack.)

Пётр Косаревский wrote

> But the result is useless without Valgrind (no more useful than a > regularly compiled binary at least), just like compiling with -gd is Just as compiler without a linker.

I hope you can see the difference between a linker, which is needed no matte how you want to use the compiler, and a tool like Valgrind or gprof.

What about user friendly filelist I mentioned?

You're free to make it and we'll happily include it.

Jonas

With this difference, compiling -gv succeeds, even if Valgrind is not installed. Compiling -pg fails, if gprof/cygwin is not installed.

One might argue, that this is a good thing, compiling with -pg without having gprof is useless anyway.

Vincent.

> I hope you can see the difference between a linker, which is needed no > matte how you want to use the compiler, and a tool like Valgrind or gprof.

VS> With this difference, compiling -gv succeeds, even if Valgrind is not VS> installed. Compiling -pg fails, if gprof/cygwin is not installed.

VS> One might argue, that this is a good thing, compiling with -pg without VS> having gprof is useless anyway.

What is better?
1. immediate access violation crash with "-gd"
-- well, I wouldn't use dbx in win32 anyway
2. confusing linker error "cannot find -lc" with "-pg" -- well, I can't use gprof without cygwin anyhow
(while gprof.exe itself does not use extras except shipped cygwin1.dll)
3. successful build with "-gv"
-- well, I can say that my file is bigger!
(but valgrind is not going to support win32)

(As I think, intentional rejecting an option should obviously depend on target system rather than the current one and keep in mind, that if it is theoretically possible, that debugger [or something] will support that system, such a ban would seem really strange)

> What about user friendly filelist I mentioned?

JM> You're free to make it and we'll happily include it. JM> Jonas
Probably I will try to write it for win32-i386-fpc2.0.3 next week, but I can only depend on searching binaries (only unpacked ones) or sources for text occurances. So, I will normally (without some web surfing or something) not know, whether this or that packed ???.exe from third party (i.e. without sources in FPC package) uses this or that third party library file. Also, there are obsolete hints in sources to be filtered out...

The compiler can also generate code for e.g. FreeBSD,Darwin and Linux. Should we also deliver all FreeBSD,Darwin and Linux libs?

But debugging your application with gdb doesn't work very well

Fixed.

Already fixed in 2.1.1 and now also in 2.03 so this is a non-issue.

2. confusing linker error "cannot find -lc" with "-pg" -- well, I can't use gprof without cygwin anyhow (while gprof.exe itself does not use extras except shipped cygwin1.dll)

It is not confusing. It is expected that you know what you are doing when using low-level tools like gprof for profiling.

3. successful build with "-gv" -- well, I can say that my file is bigger! (but valgrind is not going to support win32)

It is clear the -g already generates debuginfo only. The 'v' adapts it for valgrind. So it is obvious that the .exe is bigger.

You do it: I can download from FPC site sources and binaries for needed libraries.

Yes. I have already read that "The -pg option also links in versions of the library routines that are compiled for profiling" (gprof man page). I really didn't think these versions are so external to FPC.

But:
1. when cygwin (with binutils) is installed, e.g. libgcc.a may be not installed.
2. when cygwin is installed, you have to copy/make accessible libraries to FPC ld.exe (and cygwin itself has newer version of ld.exe).
3. the packages of cygwin to install for gprof functionality are not obvious
4. archived (libc.a, libgcc.a, libgmon.a, libkernel32.a, libmsvcrt.a and libmoldname.a) use only 200 Kb of space (and I am not sure that all of them are needed).

(to the contrast, the single cygwin1.dll uses more than 400 Kb and is shipped with FPC.)