Steve, In answer to your question:
On Wed, Apr 28, 2010 at 3:19 PM, Stephen Henson via RT <[email protected]>wrote: > Note that it is also possible to add -Zi on the command line to > Configure for non-debug builds to avoid needing to modify OpenSSL of the > generated Makefile. > > Is anyone aware of any side effects or incompatibilities caused by > always using -Zi? At present there is no option to remove a default > option so that would require manual changes to the generated makefile > under Win32. > I would advise not to have -Zi in /all/ builds for the following reasons: - The /Zi option has modest to severe impact on the way the linker works. See below for references; this is about the /OPT implied by the use of /Zi, which disables a few .exe/.dll space optimizations in the linker unless specific action is taken (i.e. explicit /OPT overrides on the command line. When not spending that extra effort, the final result is /at least/ a (slightly?) different memory footprint of the generated .dll/.exe (.exe in case of a static lib linked into app code). (And for those that like this to be triviality galore, there's the /LTCG bits as well. See also the /LTCG bit below.) - AFAICT the generated PE files will have at least a marker in their header to make debuggers aware that a separate .PDB debug database exists. In commercial settings it is often frowned upon to deliver binaries which have [the risk of] carrying any sort of debug info in them. (Sure, the debug info ain't /in/ there, but you have a high risk more symbols end up in your DLL/EXE than you might like. For those not yet in the know, there's a /very/ nice disassembler called IDA which can do very nice things for you when you need it. Any little bit of debuggy data bits help, there.) Bottom line: IMHO it's easier to *add* a /Zi (or -Zi) for an explicit developer-targetting 'debug build' than to go the several extra miles (and run the risk of a screwup some time later on in the maintenance cycle of the software lifetime) in trying to *remove* any undesirable 'side effect' of /Zi in any production-targetting 'release build'. Enough bla bla. References. Here they are: http://msdn.microsoft.com/en-us/library/958x11bc%28VS.80%29.aspx The official word of Microsoft on this one. :-) No ill effect on the code optimizer here. Note the mention of 'implied /DEBUG', so that one's next: http://msdn.microsoft.com/en-us/library/xe4t6fc1%28v=VS.80%29.aspx which happens to 'imply' non-default /OPT behaviour (read: non-default for 'release builds'!), so that's next: (Oh, and please do notice /INCREMENTAL being mentioned! You'll see the relevance when we get to /LTCG...) http://msdn.microsoft.com/en-us/library/bxwfs976%28v=VS.80%29.aspx which describes what the two effected options /OPT:REF|NOREF and /OPT:ICF|NOICF do exactly. They both impact the generated binary at link time. /OPT:REF: "LINK removes unreferenced packaged functions" i.e. different footprint and 'hence' link-time whole-program optimizations will have to produce different results. Also note that sneaky single line where it says you can do whatever you like but you won't EVER get your 'default' == regular linker behaviour back again: "Note that there is a difference in linker behavior when *ICF* is in effect by default [...]". See more at the /OPT:ICF section about this. Re 'whole program optimization' (what it's called in the MSVC IDE's): that's the /LTCG (Link-time Code Generation) linker option: http://msdn.microsoft.com/en-US/library/xbf3tbeh%28v=VS.80%29.aspx which can do grrrrreat things for your binary :-) ... unless you hit the snag mentioned in just one itty bitty line in the man page right there: "/LTCG is not valid for use with /INCREMENTAL<http://msdn.microsoft.com/en-US/library/4khtbfyf%28v=VS.80%29.aspx>." ... Oops. Bye bye, /LTCG. Twas knowing you. Re .PDB format and related materials, there's the mentioned (in the /DEBUG manpage) KnowledgeBase article Q121366: http://support.microsoft.com/kb/121366 which (my interpretation) is a lot of text with little relevance to this item, except maybe the note about "It is possible to strip debug information from a PE file [...]". And in closing, since I can't vouch for the makefiles any which way as I haven't used them for at least a decade (always used our in-house dedicated Visual Studio project files instead), here's two bits of discussion where people talk about Windows debug vs. release builds compared to Unix, pardon, Linux practices with respect to 'stripping debug info' like operations. FYI: http://priyeshwadhwa.blogspot.com/ http://www.eggheadcafe.com/software/aspnet/30629196/strip-debugging-informati.aspx Bottom line (my paraphrasing): Microsofties don't /strip/ debug info from binaries; they have a more explicit debug versus release build approach. It probably explains why I always like to have a ./configure --debug-build similar and then get to find that I haven't, most of the time. (This is generally speaking, not about OpenSSL) 'export CFLAGS' and the like can be a nuisance too; 'good golly, can't you write a shell script' (yes, I can, certainly!) is the highly anticipated response there. :-) Different workflows, same results. In the end. And yet... we do have /PDBSTRIPPED, but that's only going half-way: http://msdn.microsoft.com/en-US/library/y87kw2fd%28v=VS.80%29.aspx Moral of the story? +Zi is better than /Zi + !Zi if you value simple production results over simple development results. That's all, folks. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [email protected] mobile: +31-6-11 120 978 --------------------------------------------------Steve,
In answer to your question:
On Wed, Apr 28, 2010 at 3:19 PM, Stephen Henson via RT <[email protected]> wrote:
I would advise not to have -Zi in /all/ builds for the following reasons:
- The /Zi option has modest to severe impact on the way the linker works. See below for references; this is about the /OPT implied by the use of /Zi, which disables a few .exe/.dll space optimizations in the linker unless specific action is taken (i.e. explicit /OPT overrides on the command line. When not spending that extra effort, the final result is /at least/ a (slightly?) different memory footprint of the generated .dll/.exe (.exe in case of a static lib linked into app code). (And for those that like this to be triviality galore, there's the /LTCG bits as well. See also the /LTCG bit below.)
- AFAICT the generated PE files will have at least a marker in their header to make debuggers aware that a separate .PDB debug database exists. In commercial settings it is often frowned upon to deliver binaries which have [the risk of] carrying any sort of debug info in them. (Sure, the debug info ain't /in/ there, but you have a high risk more symbols end up in your DLL/EXE than you might like. For those not yet in the know, there's a /very/ nice disassembler called IDA which can do very nice things for you when you need it. Any little bit of debuggy data bits help, there.)
Bottom line:
IMHO it's easier to *add* a /Zi (or -Zi) for an explicit developer-targetting 'debug build' than to go the several extra miles (and run the risk of a screwup some time later on in the maintenance cycle of the software lifetime) in trying to *remove* any undesirable 'side effect' of /Zi in any production-targetting 'release build'.
Enough bla bla. References.
Here they are:
http://msdn.microsoft.com/en-us/library/958x11bc%28VS.80%29.aspx
The official word of Microsoft on this one. :-)
No ill effect on the code optimizer here.
Note the mention of 'implied /DEBUG', so that one's next:
http://msdn.microsoft.com/en-us/library/xe4t6fc1%28v=VS.80%29.aspx
which happens to 'imply' non-default /OPT behaviour (read: non-default for 'release builds'!), so that's next:
(Oh, and please do notice /INCREMENTAL being mentioned! You'll see the relevance when we get to /LTCG...)
http://msdn.microsoft.com/en-us/library/bxwfs976%28v=VS.80%29.aspx
which describes what the two effected options /OPT:REF|NOREF and /OPT:ICF|NOICF do exactly.
They both impact the generated binary at link time. /OPT:REF: "LINK removes unreferenced packaged functions" i.e. different footprint and 'hence' link-time whole-program optimizations will have to produce different results.
Also note that sneaky single line where it says you can do whatever you like but you won't EVER get your 'default' == regular linker behaviour back again: "Note that there is a difference in linker behavior when ICF is in effect by default [...]". See more at the /OPT:ICF section about this.
Re 'whole program optimization' (what it's called in the MSVC IDE's): that's the /LTCG (Link-time Code Generation) linker option:
http://msdn.microsoft.com/en-US/library/xbf3tbeh%28v=VS.80%29.aspx
which can do grrrrreat things for your binary :-) ... unless you hit the snag mentioned in just one itty bitty line in the man page right there: "/LTCG is not valid for use with /INCREMENTAL."
...
Oops.
Bye bye, /LTCG. Twas knowing you.
Re .PDB format and related materials, there's the mentioned (in the /DEBUG manpage) KnowledgeBase article Q121366:
http://support.microsoft.com/kb/121366
which (my interpretation) is a lot of text with little relevance to this item, except maybe the note about "It is possible to strip debug information from a PE file [...]".
And in closing, since I can't vouch for the makefiles any which way as I haven't used them for at least a decade (always used our in-house dedicated Visual Studio project files instead), here's two bits of discussion where people talk about Windows debug vs. release builds compared to Unix, pardon, Linux practices with respect to 'stripping debug info' like operations. FYI:
http://priyeshwadhwa.blogspot.com/
http://www.eggheadcafe.com/software/aspnet/30629196/strip-debugging-informati.aspx
Bottom line (my paraphrasing): Microsofties don't /strip/ debug info from binaries; they have a more explicit debug versus release build approach.
It probably explains why I always like to have a
./configure --debug-build
similar and then get to find that I haven't, most of the time. (This is generally speaking, not about OpenSSL)
'export CFLAGS' and the like can be a nuisance too; 'good golly, can't you write a shell script' (yes, I can, certainly!) is the highly anticipated response there. :-)
Different workflows, same results. In the end.
And yet... we do have /PDBSTRIPPED, but that's only going half-way:
http://msdn.microsoft.com/en-US/library/y87kw2fd%28v=VS.80%29.aspx
Moral of the story?
+Zi is better than /Zi + !Zi if you value simple production results over simple development results.
That's all, folks.
Note that it is also possible to add -Zi on the command line to
Configure for non-debug builds to avoid needing to modify OpenSSL of the
generated Makefile.
Is anyone aware of any side effects or incompatibilities caused by
always using -Zi? At present there is no option to remove a default
option so that would require manual changes to the generated makefile
under Win32.
I would advise not to have -Zi in /all/ builds for the following reasons:
- The /Zi option has modest to severe impact on the way the linker works. See below for references; this is about the /OPT implied by the use of /Zi, which disables a few .exe/.dll space optimizations in the linker unless specific action is taken (i.e. explicit /OPT overrides on the command line. When not spending that extra effort, the final result is /at least/ a (slightly?) different memory footprint of the generated .dll/.exe (.exe in case of a static lib linked into app code). (And for those that like this to be triviality galore, there's the /LTCG bits as well. See also the /LTCG bit below.)
- AFAICT the generated PE files will have at least a marker in their header to make debuggers aware that a separate .PDB debug database exists. In commercial settings it is often frowned upon to deliver binaries which have [the risk of] carrying any sort of debug info in them. (Sure, the debug info ain't /in/ there, but you have a high risk more symbols end up in your DLL/EXE than you might like. For those not yet in the know, there's a /very/ nice disassembler called IDA which can do very nice things for you when you need it. Any little bit of debuggy data bits help, there.)
Bottom line:
IMHO it's easier to *add* a /Zi (or -Zi) for an explicit developer-targetting 'debug build' than to go the several extra miles (and run the risk of a screwup some time later on in the maintenance cycle of the software lifetime) in trying to *remove* any undesirable 'side effect' of /Zi in any production-targetting 'release build'.
Enough bla bla. References.
Here they are:
http://msdn.microsoft.com/en-us/library/958x11bc%28VS.80%29.aspx
The official word of Microsoft on this one. :-)
No ill effect on the code optimizer here.
Note the mention of 'implied /DEBUG', so that one's next:
http://msdn.microsoft.com/en-us/library/xe4t6fc1%28v=VS.80%29.aspx
which happens to 'imply' non-default /OPT behaviour (read: non-default for 'release builds'!), so that's next:
(Oh, and please do notice /INCREMENTAL being mentioned! You'll see the relevance when we get to /LTCG...)
http://msdn.microsoft.com/en-us/library/bxwfs976%28v=VS.80%29.aspx
which describes what the two effected options /OPT:REF|NOREF and /OPT:ICF|NOICF do exactly.
They both impact the generated binary at link time. /OPT:REF: "LINK removes unreferenced packaged functions" i.e. different footprint and 'hence' link-time whole-program optimizations will have to produce different results.
Also note that sneaky single line where it says you can do whatever you like but you won't EVER get your 'default' == regular linker behaviour back again: "Note that there is a difference in linker behavior when ICF is in effect by default [...]". See more at the /OPT:ICF section about this.
Re 'whole program optimization' (what it's called in the MSVC IDE's): that's the /LTCG (Link-time Code Generation) linker option:
http://msdn.microsoft.com/en-US/library/xbf3tbeh%28v=VS.80%29.aspx
which can do grrrrreat things for your binary :-) ... unless you hit the snag mentioned in just one itty bitty line in the man page right there: "/LTCG is not valid for use with /INCREMENTAL."
...
Oops.
Bye bye, /LTCG. Twas knowing you.
Re .PDB format and related materials, there's the mentioned (in the /DEBUG manpage) KnowledgeBase article Q121366:
http://support.microsoft.com/kb/121366
which (my interpretation) is a lot of text with little relevance to this item, except maybe the note about "It is possible to strip debug information from a PE file [...]".
And in closing, since I can't vouch for the makefiles any which way as I haven't used them for at least a decade (always used our in-house dedicated Visual Studio project files instead), here's two bits of discussion where people talk about Windows debug vs. release builds compared to Unix, pardon, Linux practices with respect to 'stripping debug info' like operations. FYI:
http://priyeshwadhwa.blogspot.com/
http://www.eggheadcafe.com/software/aspnet/30629196/strip-debugging-informati.aspx
Bottom line (my paraphrasing): Microsofties don't /strip/ debug info from binaries; they have a more explicit debug versus release build approach.
It probably explains why I always like to have a
./configure --debug-build
similar and then get to find that I haven't, most of the time. (This is generally speaking, not about OpenSSL)
'export CFLAGS' and the like can be a nuisance too; 'good golly, can't you write a shell script' (yes, I can, certainly!) is the highly anticipated response there. :-)
Different workflows, same results. In the end.
And yet... we do have /PDBSTRIPPED, but that's only going half-way:
http://msdn.microsoft.com/en-US/library/y87kw2fd%28v=VS.80%29.aspx
Moral of the story?
+Zi is better than /Zi + !Zi if you value simple production results over simple development results.
That's all, folks.
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------
