[fpc-devel] New -Xg option in the last 9778 revision

Jonas Maebe jonas.maebe at elis.ugent.be
Sat Jan 19 13:22:08 CET 2008

On 19 Jan 2008, at 12:43, Tomas Hajny wrote:

> On 18 Jan 08, at 22:29, Michael Van Canneyt wrote:
>> On Fri, 18 Jan 2008, Flávio Etrusco wrote:
>>>>> But why doesn't FPC spit a warning when these (seemingly  
>>>>> conflicting)
>>>>> options are used?
>>>> It silently switches off -Xs when debug info is selected.
>>> Don't you think it should display a warning?
>> I can imagine some people do :-)
> This requirement would bring additional complexity to processing of
> compiler options. As of now, there are at least four ways to set
> compiler behaviour:

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 - 

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


More information about the fpc-devel mailing list