Hi to all,

I have some questions about the last 9778 revision (related to the new -Xg option).

The help tell: "-Xg now produces a .dbg file with debuginfo that can be used by gdb."

My questions are:

1)...when this patch will be apply to the current 2.2.x version (I think currently it works only on the last 2.3.x version)?

2)...when will be added the full "lineinfo" and "lnfodwrf" units supports to read the debuginfo from the external .dbg file?

Thank you to all for your attention! ;)

The patch is not even 24 hours old and needs to stabilize first. Maybe in a couple of months it will be considered for inclusion.

2)...when will be added the full "lineinfo" and "lnfodwrf" units supports to read the debuginfo from the external .dbg file? Thank you to all for your attention! ;)

When time permits or we receive a patch.

Peter

Hi,

2008/1/17, Peter Vreman :

Do you think it will be included in the next 2.2.2 stable release?

Normally not.

Michael.

Hi,

2008/1/17, Michael Van Canneyt :

Why?

I think is really most important can use it ASAP.

If we can use it on the next 2.2.2 (with the full "lineinfo" and "lnfodwrf" units supports) then is probably that the next lazarus 0.9.26 will be ready to use external .dbg files, solving the big issue of the compiled file size.

Michael.

Because 2.2.2 is a bugfix only release, no new features are allowed.

Michael.

Hi,

2008/1/17, Michael Van Canneyt :

I understand and agree with this position, add a new features in a "bugfix only" release is dangerous!

Any opinion about the 2.4 release date?

No.

Because of the FPC server crash and the copyright issue, 2.2.2 is already one month behind of schedule. I don't even know when we'll get that back on track. Let alone that I would know when 2.4 will be out.

Michael.

On the other hand we can treat -Xg option as bug so then there will be no rule breaking.

Also think of fpc_resources merge since old resource support (=current for fixes_2_2, and trunk) can be treated as bugged too :)

Best regards,
Paul Ishenin.

I think is really most important can use it ASAP.

Right ! See the latest posts in the Borland Kylix Newsgroup (that indeed still exists :) ).

-Michael

Hi,

2008/1/18, Michael Schnell :

What do you mean? :|

I suggested using Lazarus and the OP said he had great doubts because the size of the exe of his test program is 10 times the size of that compiled by Borland.

-Michael

Hi,

2008/1/18, Michael Schnell :

I have found the original thread.
See it here:
http://groups.google.com/group/borland.public.kylix.ide/browse_thread/thread/e6beff158e36b0b8

Michael Schnell wrote

I suggested using Lazarus and the OP said he had great doubts because the size of the exe of his test program is 10 times the size of that compiled by Borland.

So, he couldn't read the FAQ:

http://wiki.lazarus.freepascal.org/Lazarus_Faq#Why_are_the_generated_binaries_so_big.3F

Hi,

2008/1/18, Felipe Monteiro de Carvalho :

Or we can apply this patch to the 2.2.2 branch! ;)

Op Fri, 18 Jan 2008, schreef Michael Schnell:

I suggested using Lazarus and the OP said he had great doubts because the size of the exe of his test program is 10 times the size of that compiled by Borland.

Anyone who writes such texts doesn't look further than his nose. Experience shows they will just hit the next thing which makes Lazarus "unusable". Don't expect such idiots to become Lazarus users.

Daniël

That is partly true. The problem is that setting -Xs doesn't help if there is also -g in the command line. So people think that the compiler strips the executable, but in fact the binary is unstripped.

The easiest way to solve this is with a check in Lazarus. When the strip checkbox is checked a note shall be shown and asked to disable the debuginfo to make the option work.

The real solution is what a lot of people already asked for. Multiple build modes like Visual C++ also has.

Peter

I think this is indeed the best, and should be not so hard to implement;
At least the check would be already a hint to users.

Michael.

So, he couldn't read the FAQ:

Of course not. Nearly nobody reads an FAQ before deciding if a program is usable for him or not. They are only read when working with the program and encountering problems.

-Michael

:)

We thought about this some years ago. It is not as trivial as it seems. Initial problem was to present all possible options to the user. The tree based optiondialogs might help with this.

Marc

I may be naive, of course, but:

I think that the build mode should only (un)set a couple of options, and should leave the rest of the options intact. What is so difficult about this ?

Michael.

Op Fri, 18 Jan 2008, schreef Marc Weustink:

The FPC IDE has had it for years. All user interface support you need is the Options->Mode menu. For the rest the handling all internal; the IDE uses an array of options, one for each build mode, each with its own defaults.

Daniël

Yeah... and we want something less static and more configurable, default options, release/debug/whatever build, target dependent etc.etc.etc.

Marc

Op Fri, 18 Jan 2008, schreef Marc Weustink:

It would be nice that you can set certain compiler options only on certain targets, but, that is not what people are asking for. Don't make it more complicated than it is. All users want is an easy to access "debug build/release build" switch. The FPC IDE's fixed number 3 profiles already provide more than that. You can code it in an afternoon, which could be well spent, even if you want to code a more complex system later on.

Daniël

It silently switches off -Xs when debug info is selected.

Michael.

But why doesn't FPC spit a warning when these (seemingly conflicting) options are used?

-Flávio

Don't you think it should display a warning?

-Flávio

I can imagine some people do :-)

Michael.

This requirement would bring additional complexity to processing of compiler options. As of now, there are at least four ways to set compiler behaviour:

1) Internal compiler defaults.
2) Configuration files (note that these may be fairly complex with IFDEFs and include files)
3) Command-line options
4) Compiler directives within source files - e.g. {$MODE xxx} (not applicable to all kinds of command line options, of course)

It's quite common to have some default set at some of these levels and override this default on a different level, and you probably wouldn't want to emit warnings in this case. Moreover, more complex configuration files may intentionally include "conflicting" options (because of overriding) too - imagine a configuration file like this:

-Xs
#IFDEF DEBUG
-gl
#ENDIF DEBUG

In this case, adding -dDEBUG on command line intentionally overrides the previous part of the configuration file - again, probably no reason to emit any warning.

Now, what all this means for FPC - as of now, we process the options in linear way. Internal compiler defaults are during initialization of the compiler. Then we configuration files are searched and if found, read in linear way - if some option is found, it turns particular behaviour on or off. If the next option switches the behaviour back, FPC doesn't know it (and it doesn't care), because that request was already processed before. In order to change that, FPC would probably need to maintain two parallel structures for setting the behaviour - one temporary used while processing certain level of configuration as listed above, another where the results for the particular level would be copied after that level is completely processed (that one would need to include reference to the particular option turning the feature on in order to show proper warning message
- some of the features may be turned on in different ways). Although this is certainly doable, it's certainly much more complex than the current implementation...

Tomas

The main source of confusion is that if you currently have "-g -Xs", then -Xs will be ignored (even though it comes after -g). There are different ways to handle this situation:
a) the current way. Reason: if you compile with debug information, stripping will undo that work that may cause confusion. b) Have -Xs turn off -g
c) Have -Xs not turn off -g (so the object files still contain debug information) but still strip (so the final executable doesn't)

The question in case c) (which would seem the most intuitively correct to me) is what you then do with -Xs -g. If -Xs doesn't disable -g, then for consistency -g shouldn't disable -Xs either. But in that case debugging won't work if you simply use -g on the command line and there is -Xs somewhere in a config file (you'd have to add -Xs- as well, support for which was only recently added).

I guess this last part is the reason for the current behaviour. This also allows the default fpc.cfg to contain an unconditional -Xs.

It's of course also possible to make -g -Xs and -Xs -g operate asymmetrically (-g -Xs -> debug info + strip; -Xs -g -> debug info and no stripping). And all situations have their downsides:
1) current situation: -g -Xs does not strip, even though you'd expect it
2) asymmetrical (-Xs -g, b: requires extra explanations and can be unintuitive because the switches are sometimes orthogonal and sometimes not
3) symmetrical (-Xs -g disables stripping, -g -Xs disables debug info): different from how other command line compilers work (the above two are different as well, obviously), and can be limiting (e.g., for optimal smart linking results, the Mac OS X linker requires debug information in the object files)
4) orthogonal (-Xs and -g do not influence each other, and disabling them requires respectively -Xs- and -g-): requires (at the very least) removing the default -Xs from fpc.cfg (which in turn may cause 10 more "why does FPC generate such bug executables" threads), and may cause problems for people having their own .fpc.cfg in their home directory based on an older template ("help, I can't compile programs with debug info anymore after upgrading", because the config file still contains - Xs).

In the end, 3) will probably cause the least problems in practice due to the current behaviour. 4) is however the cleanest and most consistent in my opinion (and also the most flexible one).

Jonas

Jonas Maebe wrote

2) asymmetrical (-Xs -g, b: requires extra explanations and can be unintuitive because the switches are sometimes orthogonal and sometimes not

Something got left out here, that should have read:

2) asymmetrical (-Xs -g turns off stripping, but -g -Xs does not turn off debug information although it still strips): requires extra explanations and can be unintuitive because the switches are sometimes orthogonal and sometimes not

Jonas

2) Configuration files (note that these may be fairly complex with IFDEFs and include files.

So in Lazarus such an option could be just selecting a configuration file.

Seems rather easy.

-Michael

2) asymmetrical (-Xs -g turns off stripping, but -g -Xs does not turn off debug information ...

Do / should the order the options are given in matter ? IMHO this can be the source of major confusion.

The Lazarus GUI uses check boxes to select compiler options. This no order is selectable here. And this seems like a good idea to me.

-Michael

The order of -Xs and -g does not matter. The stripping is disabled after all parameters are parsed.

Peter