Hi,
what's the correct way to handle debugging information in MinGW packages?
Currently, mingw32-nsis builds everything with debugging information (due to the debian-debug-opt patch), even the MinGW parts, but the MinGW debugging information is not extracted, so it's included within the binaries. This is particularly annoying for NSIS installers as it bloats the installer stubs. For example, the lzma_solid stub is 210185 bytes, running a MinGW strip on it reduces it to 55296 bytes.
Do we really want debugging information in the MinGW stuff even if it can't be extracted into separate -debuginfo? Or should the MinGW portions of NSIS be built without -g instead? Should the same policy apply to everything or should NSIS be special? (I can see why a developer would want to have debugging information for a library, but for an installer?)
Kevin Kofler
On Wed, Feb 25, 2009 at 02:46:39PM +0100, Kevin Kofler wrote:
Hi,
what's the correct way to handle debugging information in MinGW packages?
Currently, mingw32-nsis builds everything with debugging information (due to the debian-debug-opt patch), even the MinGW parts, but the MinGW debugging information is not extracted, so it's included within the binaries. This is particularly annoying for NSIS installers as it bloats the installer stubs. For example, the lzma_solid stub is 210185 bytes, running a MinGW strip on it reduces it to 55296 bytes.
Do we really want debugging information in the MinGW stuff even if it can't be extracted into separate -debuginfo? Or should the MinGW portions of NSIS be built without -g instead? Should the same policy apply to everything or should NSIS be special? (I can see why a developer would want to have debugging information for a library, but for an installer?)
Last time we tried, a cross compiled GDB crashed & burned. So unless someone can demonstrate a usuable WINE/Win32 debugger that can use the gcc generated debugging info, then we should not build with -g, nor create -debuginfo sub-RPMs.
The exception being the base toolchain that is natively compiled should of course have debuginfo as normal.
Daniel
Daniel P. Berrange wrote:
On Wed, Feb 25, 2009 at 02:46:39PM +0100, Kevin Kofler wrote:
Hi,
what's the correct way to handle debugging information in MinGW packages?
Currently, mingw32-nsis builds everything with debugging information (due to the debian-debug-opt patch), even the MinGW parts, but the MinGW debugging information is not extracted, so it's included within the binaries. This is particularly annoying for NSIS installers as it bloats the installer stubs. For example, the lzma_solid stub is 210185 bytes, running a MinGW strip on it reduces it to 55296 bytes.
Do we really want debugging information in the MinGW stuff even if it can't be extracted into separate -debuginfo? Or should the MinGW portions of NSIS be built without -g instead? Should the same policy apply to everything or should NSIS be special? (I can see why a developer would want to have debugging information for a library, but for an installer?)
Last time we tried, a cross compiled GDB crashed & burned. So unless someone can demonstrate a usuable WINE/Win32 debugger that can use the gcc generated debugging info, then we should not build with -g, nor create -debuginfo sub-RPMs.
This build of GDB https://sourceforge.net/project/showfiles.php?group_id=202880&package_id... works with executables compiled with Mingw-w64.
The exception being the base toolchain that is natively compiled should of course have debuginfo as normal.
Daniel
Daniel P. Berrange wrote:
On Wed, Feb 25, 2009 at 02:46:39PM +0100, Kevin Kofler wrote:
Hi,
what's the correct way to handle debugging information in MinGW packages?
Currently, mingw32-nsis builds everything with debugging information (due to the debian-debug-opt patch), even the MinGW parts, but the MinGW debugging information is not extracted, so it's included within the binaries. This is particularly annoying for NSIS installers as it bloats the installer stubs. For example, the lzma_solid stub is 210185 bytes, running a MinGW strip on it reduces it to 55296 bytes.
Do we really want debugging information in the MinGW stuff even if it can't be extracted into separate -debuginfo? Or should the MinGW portions of NSIS be built without -g instead? Should the same policy apply to everything or should NSIS be special? (I can see why a developer would want to have debugging information for a library, but for an installer?)
Last time we tried, a cross compiled GDB crashed & burned. So unless someone can demonstrate a usuable WINE/Win32 debugger that can use the gcc generated debugging info, then we should not build with -g, nor create -debuginfo sub-RPMs.
the question still apply (i gdb will work) do we want to provide debuginfo for crosscompiled binaries? i don't know what's the good answer:-(
On Wed, Feb 25, 2009 at 01:53:23PM +0000, Daniel P. Berrange wrote:
Last time we tried, a cross compiled GDB crashed & burned. So unless someone can demonstrate a usuable WINE/Win32 debugger that can use the gcc generated debugging info, then we should not build with -g, nor create -debuginfo sub-RPMs.
The exception being the base toolchain that is natively compiled should of course have debuginfo as normal.
According to this:
http://sourceforge.net/mailarchive/message.php?msg_name=8278b1b0902240411i58...
Windows has its own native debugging format (*.PDB) that GCC/GDB (or perhaps MinGW) doesn't support anyway.
Rich.
Richard W.M. Jones wrote:
On Wed, Feb 25, 2009 at 01:53:23PM +0000, Daniel P. Berrange wrote:
Last time we tried, a cross compiled GDB crashed & burned. So unless someone can demonstrate a usuable WINE/Win32 debugger that can use the gcc generated debugging info, then we should not build with -g, nor create -debuginfo sub-RPMs.
The exception being the base toolchain that is natively compiled should of course have debuginfo as normal.
According to this:
http://sourceforge.net/mailarchive/message.php?msg_name=8278b1b0902240411i58...
Windows has its own native debugging format (*.PDB) that GCC/GDB (or perhaps MinGW) doesn't support anyway.
Right, neither you can make .PDB files with GCC nor you can read them with anything other than MS debugger.
Additionally:
* -gcoff option produces debugging information that is understood by MS debugger (in a quite limited way though)
* -ggdb produces debugging information that is understood by Windows ports of GDB.
Rich.
On Wed, Feb 25, 2009 at 05:10:45PM +0000, Richard W.M. Jones wrote:
On Wed, Feb 25, 2009 at 01:53:23PM +0000, Daniel P. Berrange wrote:
Last time we tried, a cross compiled GDB crashed & burned. So unless someone can demonstrate a usuable WINE/Win32 debugger that can use the gcc generated debugging info, then we should not build with -g, nor create -debuginfo sub-RPMs.
The exception being the base toolchain that is natively compiled should of course have debuginfo as normal.
According to this:
http://sourceforge.net/mailarchive/message.php?msg_name=8278b1b0902240411i58...
Windows has its own native debugging format (*.PDB) that GCC/GDB (or perhaps MinGW) doesn't support anyway.
So not useful in the general case for debugging under Windows / using the MicroSoft debugger, but I guess the question is whether there is none-the-less a more limited case in which GCC debuginfo is useful ?
eg if cross-compiling and then debugging the app under Wine using GDB, would minggw-XXX-debuginfo RPMs still be useful to have ?
If so, then that could be justification for providing them [1].
Daniel
[1] Assuming we could also produce a working GDB build for use in Wine :-)
On Wed, Feb 25, 2009 at 05:31:35PM +0000, Daniel P. Berrange wrote:
eg if cross-compiling and then debugging the app under Wine using GDB, would minggw-XXX-debuginfo RPMs still be useful to have ?
I don't really know a lot about this, but I did try to use the in-built Wine debugger, without any success.
Rich.
Daniel P. Berrange wrote:
On Wed, Feb 25, 2009 at 05:10:45PM +0000, Richard W.M. Jones wrote:
On Wed, Feb 25, 2009 at 01:53:23PM +0000, Daniel P. Berrange wrote:
Last time we tried, a cross compiled GDB crashed & burned. So unless someone can demonstrate a usuable WINE/Win32 debugger that can use the gcc generated debugging info, then we should not build with -g, nor create -debuginfo sub-RPMs.
The exception being the base toolchain that is natively compiled should of course have debuginfo as normal.
According to this:
http://sourceforge.net/mailarchive/message.php?msg_name=8278b1b0902240411i58...
Windows has its own native debugging format (*.PDB) that GCC/GDB (or perhaps MinGW) doesn't support anyway.
So not useful in the general case for debugging under Windows / using the MicroSoft debugger, but I guess the question is whether there is none-the-less a more limited case in which GCC debuginfo is useful ?
eg if cross-compiling and then debugging the app under Wine using GDB, would minggw-XXX-debuginfo RPMs still be useful to have ?
*Personally* I haven't seen GDB working under Wine. On the other hand GDB works fine under real Windows.
gdb4win32: https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=2... gdb4win64: https://sourceforge.net/project/showfiles.php?group_id=202880&package_id...
However I don't know whether it's possible/easy to cross-compile GDB from Linux.
On Wed, Feb 25, 2009 at 12:44 PM, Alexey Pushkin alexey.pushkin@mererand.com wrote:
However I don't know whether it's possible/easy to cross-compile GDB from Linux.
Trivial
NightStrike wrote:
On Wed, Feb 25, 2009 at 12:44 PM, Alexey Pushkin alexey.pushkin@mererand.com wrote:
However I don't know whether it's possible/easy to cross-compile GDB from Linux.
Trivial
Then ... perhaps Rich is interested in mingw-gdb.src.rpm ?
fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
On Wed, Feb 25, 2009 at 09:15:01PM +0300, Alexey Pushkin wrote:
NightStrike wrote:
On Wed, Feb 25, 2009 at 12:44 PM, Alexey Pushkin alexey.pushkin@mererand.com wrote:
However I don't know whether it's possible/easy to cross-compile GDB from Linux.
Trivial
Then ... perhaps Rich is interested in mingw-gdb.src.rpm ?
Sure! You got a working specfile?
Rich.
Richard W.M. Jones wrote:
On Wed, Feb 25, 2009 at 09:15:01PM +0300, Alexey Pushkin wrote:
NightStrike wrote:
On Wed, Feb 25, 2009 at 12:44 PM, Alexey Pushkin alexey.pushkin@mererand.com wrote:
However I don't know whether it's possible/easy to cross-compile GDB from Linux.
Trivial
Then ... perhaps Rich is interested in mingw-gdb.src.rpm ?
Sure! You got a working specfile?
I suppose the question is to NightStrike — he definitely knows better how to cross-compile gdb than me.
On Wed, Feb 25, 2009 at 3:47 PM, Alexey Pushkin alexey.pushkin@mererand.com wrote:
Richard W.M. Jones wrote:
On Wed, Feb 25, 2009 at 09:15:01PM +0300, Alexey Pushkin wrote:
NightStrike wrote:
On Wed, Feb 25, 2009 at 12:44 PM, Alexey Pushkin alexey.pushkin@mererand.com wrote:
However I don't know whether it's possible/easy to cross-compile GDB from Linux.
Trivial
Then ... perhaps Rich is interested in mingw-gdb.src.rpm ?
Sure! You got a working specfile?
I suppose the question is to NightStrike — he definitely knows better how to cross-compile gdb than me.
I know how to build gdb. I have no idea what a spec file is.
Op woensdag 25-02-2009 om 13:53 uur [tijdzone +0000], schreef Daniel P. Berrange:
Last time we tried, a cross compiled GDB crashed & burned. So unless someone can demonstrate a usuable WINE/Win32 debugger that can use the gcc generated debugging info, then we should not build with -g, nor create -debuginfo sub-RPMs.
Hi,
Instead of gdb, I'm using Dr. MinGW [1]. To be exactly, I'm bundling the file exchndl.dll along with my applications and LoadLibrary it on startup.
Whenever a crash occurs, an error report is automatically created containing the complete backtrace. This backtrace is based on the debug information which is currently in the MinGW compiled packages.
Using such errors reports, users don't have to worry about using gdb, all they have to do is send these error reports to the developers.
When running my application under Wine, these error reports also get created.
Regards,
Erik van Pienbroek
I wrote:
Currently, mingw32-nsis builds everything with debugging information (due to the debian-debug-opt patch), even the MinGW parts, but the MinGW debugging information is not extracted, so it's included within the binaries. This is particularly annoying for NSIS installers as it bloats the installer stubs. For example, the lzma_solid stub is 210185 bytes, running a MinGW strip on it reduces it to 55296 bytes.
An additional issue with NSIS in particular is that when debugging information is present in the stubs, NSIS corrupts their symbol table, which also affects the names of the debugging sections in the section table because they are long section names and thus stored in the symbol table, and thus !packhdr doesn't work: if I use: !packhdr tmpexe.tmp "upx --best -q tmpexe.tmp" UPX complains about "superfluous data between sections". If I try: !packhdr tmpexe.tmp "i686-pc-mingw32-strip tmpexe.tmp; upx --best -q tmpexe.tmp" I even get a crash in i686-pc-mingw32-strip. (Note that this is on x86_64, I haven't tested what happens with the 32-bit version, but I suspect that it'll be the same thing.)
I think the "resource editor" in NSIS (CResourceEditor::AddExtraVirtualSize2PESection, which is what is used on the stubs, in particular) somehow does not support symbol tables.
If I strip the stub I use (/usr/share/nsis/Stubs/lzma_solid) beforehand, UPX works on the generated tmpexe.tmp just fine.
I think that we'll want to build at least the NSIS stubs without debugging information as upstream does. Actually, I'd like to drop the debian-debug-opt patch entirely. That patch does 5 things: * adds -g for the cross-platform executables - this is redundant with our rpm-opt patch, we already inherit -g from RPM_OPT_FLAGS. * adds -g for the MinGW executables - this is what is causing the packhdr problem above and wastes space in the installers with little benefit (you rarely need to debug an installer), as I previously mentioned in this thread. * makes optimization optional - useless, we set OPT=1 in the specfile anyway. * replaces -Os with -O2 for the MinGW portions - why? Upstream intentionally uses -Os to keep the installers as small as possible. An installer is something you execute once and there's nothing in them which needs a high performance. * disables stripping if DEBUG_SYMBOLS is true - we can simply pass STRIP=false or STRIP_CP=false (the latter only disabling stripping for the native binaries and not the MinGW ones - that said, I'm not sure whether stripping makes any difference for the MinGW binaries if they're already built without debugging information) to get that same effect.
The details of what I want to do: * remove nsis-2.43-debian-debug-opt.patch * rediff nsis-2.43-rpm-opt.patch so it applies without that patch being applied first * change the SCons options to remove DEBUG_SYMBOLS=1 OPTS=1 (options added by the patch) and use STRIP_CP=false instead (the upstream way to disable stripping).
Any objections?
Kevin Kofler
On Tue, Mar 03, 2009 at 07:49:15PM +0100, Kevin Kofler wrote:
The details of what I want to do:
- remove nsis-2.43-debian-debug-opt.patch
- rediff nsis-2.43-rpm-opt.patch so it applies without that patch being
applied first
- change the SCons options to remove DEBUG_SYMBOLS=1 OPTS=1 (options added
by the patch) and use STRIP_CP=false instead (the upstream way to disable stripping).
Makes sense, as far as I can tell.
Rich.
-
Alexey Pushkin -
Daniel P. Berrange -
Erik van Pienbroek -
Farkas Levente -
Kevin Kofler -
NightStrike -
Richard W.M. Jones