From: asmwarrior <asm...@gm...> - 2013-10-01 15:23:37
|
Hi, I download the mingw-get-setup.exe, and install three packages: 1, mingw32-base bin 2, mingw32-c++ bin 4.8.1-3 3, mingw32-c++ dev 4.8.1-3 (this is automatically select after I select the previous package) I found that the gdb.exe is 27.878KB, do you forget to strip the debug information after building the GDB? There are some other exe files which is quite large, e.g. size.exe is 7.2M, I think their size is also not correct, it should be less than 2 or 3M. Yuanhui Zhang |
From: asmwarrior <asm...@gm...> - 2013-10-06 13:55:40
|
On 2013-10-1 23:30, asmwarrior wrote: > Hi, I download the mingw-get-setup.exe, and install three packages: > 1, mingw32-base bin > 2, mingw32-c++ bin 4.8.1-3 > 3, mingw32-c++ dev 4.8.1-3 (this is automatically select after I select the previous package) > > I found that the gdb.exe is 27.878KB, do you forget to strip the debug information after building the GDB? > There are some other exe files which is quite large, e.g. size.exe is 7.2M, I think their size is also not correct, it should be less than 2 or 3M. > > Yuanhui Zhang Ping, all you guys do not have this issue? |
From: Earnie B. <ea...@us...> - 2013-10-06 14:53:57
|
On Sun, Oct 6, 2013 at 10:02 AM, asmwarrior wrote: > On 2013-10-1 23:30, asmwarrior wrote: >> Hi, I download the mingw-get-setup.exe, and install three packages: >> 1, mingw32-base bin >> 2, mingw32-c++ bin 4.8.1-3 >> 3, mingw32-c++ dev 4.8.1-3 (this is automatically select after I select the previous package) >> >> I found that the gdb.exe is 27.878KB, do you forget to strip the debug information after building the GDB? >> There are some other exe files which is quite large, e.g. size.exe is 7.2M, I think their size is also not correct, it should be less than 2 or 3M. >> >> Yuanhui Zhang > Ping, all you guys do not have this issue? Yes, it was an oversight on my packaging. I will add a LDFLAGS=-s during the configuration to overcome it in the future. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2013-10-06 17:54:17
|
On 06/10/13 15:02, asmwarrior wrote: > On 2013-10-1 23:30, asmwarrior wrote: >> Hi, I download the mingw-get-setup.exe, and install three packages: >> 1, mingw32-base bin >> 2, mingw32-c++ bin 4.8.1-3 >> 3, mingw32-c++ dev 4.8.1-3 (this is automatically select after I >> select the previous package) >> >> I found that the gdb.exe is 27.878KB, do you forget to strip the >> debug information after building the GDB? There are some other exe >> files which is quite large, e.g. size.exe is 7.2M, I think their >> size is also not correct, it should be less than 2 or 3M. > > Ping, all you guys do not have this issue? Why is it an issue? Sure, the binaries may be burdened with debug information, but some users might argue that this is a *good* feature. If you don't like it, you can always strip it out of your own copy; if we strip it up front, then like it or not, it's gone for everyone. Agreed, if you're challenged by poor internet bandwidth, you may prefer to not have to download the larger binaries. In case you may not have guessed, I'm playing devil's advocate here; we cannot please all of the people all of the time. -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2013-10-06 20:37:21
|
On Sun, Oct 6, 2013 at 1:54 PM, Keith Marshall wrote: > On 06/10/13 15:02, asmwarrior wrote: >> On 2013-10-1 23:30, asmwarrior wrote: >>> Hi, I download the mingw-get-setup.exe, and install three packages: >>> 1, mingw32-base bin >>> 2, mingw32-c++ bin 4.8.1-3 >>> 3, mingw32-c++ dev 4.8.1-3 (this is automatically select after I >>> select the previous package) >>> >>> I found that the gdb.exe is 27.878KB, do you forget to strip the >>> debug information after building the GDB? There are some other exe >>> files which is quite large, e.g. size.exe is 7.2M, I think their >>> size is also not correct, it should be less than 2 or 3M. >> >> Ping, all you guys do not have this issue? > > Why is it an issue? Sure, the binaries may be burdened with debug > information, but some users might argue that this is a *good* feature. > If you don't like it, you can always strip it out of your own copy; if > we strip it up front, then like it or not, it's gone for everyone. > > Agreed, if you're challenged by poor internet bandwidth, you may prefer > to not have to download the larger binaries. In case you may not have > guessed, I'm playing devil's advocate here; we cannot please all of the > people all of the time. This was the answer I started to give but it was stripped before so I will remove the debug info from the executables and libraries before shipping it with LDFLAGS=-s. If the package doesn't honor that configuration argument, I'm not going out of my way to strip them. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2013-10-06 21:33:03
|
On 06/10/13 21:37, Earnie Boyd wrote: > it was stripped before so I will remove the debug info That's fair enough; some may disagree, but it is at least consistent with previous practice. > from the executables and libraries before shipping it with > LDFLAGS=-s. For any package which follows GNU conventions, that would work, but it isn't my preferred approach. I prefer to build with debug information included, then I use 'make prefix=`pwd`/staged install-strip' to stage a stripped version for distribution. Doing it this way, I don't need to rebuild, if I want to stage a debug enabled release. -- Regards, Keith. |
From: Eli Z. <el...@gn...> - 2013-10-07 02:56:46
|
> Date: Sun, 06 Oct 2013 22:32:56 +0100 > From: Keith Marshall <kei...@us...> > > For any package which follows GNU conventions, that would work, but it > isn't my preferred approach. I prefer to build with debug information > included, then I use 'make prefix=`pwd`/staged install-strip' to stage a > stripped version for distribution. Doing it this way, I don't need to > rebuild, if I want to stage a debug enabled release. GDB doesn't support "make install-strip", alas. I reported that to the upstream maintainers long ago; patches are welcome. What I do to install GDB is this: make -C gdb install prefix=/where/ever cd /where/ever/bin && strip gdb.exe |
From: asmwarrior <asm...@gm...> - 2013-10-07 03:11:09
|
On 2013-10-7 10:56, Eli Zaretskii wrote: >> Date: Sun, 06 Oct 2013 22:32:56 +0100 >> > From: Keith Marshall <kei...@pu...> >> > >> > For any package which follows GNU conventions, that would work, but it >> > isn't my preferred approach. I prefer to build with debug information >> > included, then I use 'make prefix=`pwd`/staged install-strip' to stage a >> > stripped version for distribution. Doing it this way, I don't need to >> > rebuild, if I want to stage a debug enabled release. > GDB doesn't support "make install-strip", alas. I reported that to > the upstream maintainers long ago; patches are welcome. > > What I do to install GDB is this: > > make -C gdb install prefix=/where/ever > cd /where/ever/bin && strip gdb.exe I use the way suggest by some GDB devs (maybe Tom, I can't remember correctly) several months ago, this has some advantages compared to manually strip on some exe files, especially if you also install other libraries from GDB build folder: make make install INSTALL_PROGRAM='install -s' -C gdb DESTDIR=/where/ever BTW: I recently found that currently GDB can not simulate a inferior call in __thiscall, so it is hard to debug a c++ program build from MinGW GCC 4.7.0 and later. GCC 4.7.0 has changed its c++ class member function calling conversion to __thiscall under Windows x86, thus I'm still using GCC 4.6.x for better debugging experience. See bug report here: https://sourceware.org/bugzilla/show_bug.cgi?id=15559 |
From: asmwarrior <asm...@gm...> - 2013-10-18 05:42:36
|
On 2013-10-7 11:18, asmwarrior wrote: > I recently found that currently GDB can not simulate a inferior call in __thiscall, so it is hard to debug a c++ program build from MinGW GCC 4.7.0 and later. GCC 4.7.0 has changed its c++ class member function calling conversion to __thiscall under Windows x86, thus I'm still using GCC 4.6.x for better debugging experience. See bug report here: https://sourceware.org/bugzilla/show_bug.cgi?id=15559 For those who want to have a good GDB debugging experience for targets build from MinGW GCC 4.7.0+, I have a patch to workaround this issue. See patch and details in: https://sourceware.org/bugzilla/show_bug.cgi?id=15559 Note: The patch just changes the inferior calling convention for non-static C++ class member functions to __thiscall on targets build from MinGW GCC 4.7.0+. GDB normally use cdecl calling conventions for all kinds of function(SYSTEM V ABI for i386). I'm curious that not much discussions about this can be found, but I think it is very useful feature when debugging. A self build GDB (against python 2.7.5) can be download from this page: http://forums.codeblocks.org/index.php/topic,11301.0.html Yuanhui Zhang |