[arch-dev-public] Default DEBUG_CFLAGS/CXXFLAGS provided with pacman 4.1
With pacman 4.1 just around the corner, we'll be getting support for split debug information soon. I would like to recommend "-gdwarf-4 -fvar-tracking-assignments" as our default debug flags in makepkg.conf. These flags should allow for better debug information in the presence of optimization (less <value optimized out>; see man gcc). Thoughts?
On 27/03/13 12:22, Jan Alexander Steffens wrote:
With pacman 4.1 just around the corner, we'll be getting support for split debug information soon.
I would like to recommend "-gdwarf-4 -fvar-tracking-assignments" as our default debug flags in makepkg.conf. These flags should allow for better debug information in the presence of optimization (less <value optimized out>; see man gcc).
This is probably a better reference than the man page: http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
Thoughts?
Note with gcc-4.8: DWARF4 is now the default when generating DWARF debug information. When -g is used on a platform that uses DWARF debugging information, GCC will now default to -gdwarf-4 -fno-debug-types-section.
On 27/03/13 12:49, Allan McRae wrote:
On 27/03/13 12:22, Jan Alexander Steffens wrote:
With pacman 4.1 just around the corner, we'll be getting support for split debug information soon.
I would like to recommend "-gdwarf-4 -fvar-tracking-assignments" as our default debug flags in makepkg.conf. These flags should allow for better debug information in the presence of optimization (less <value optimized out>; see man gcc).
This is probably a better reference than the man page: http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
Thoughts?
Note with gcc-4.8:
DWARF4 is now the default when generating DWARF debug information. When -g is used on a platform that uses DWARF debugging information, GCC will now default to -gdwarf-4 -fno-debug-types-section.
Any comments? You have ~12 hours... I will use "-g -fvar-tracking-assignments" if no-one comments otherwise. Allan
On 03/31/2013 05:08 PM, Allan McRae wrote:
On 27/03/13 12:49, Allan McRae wrote:
On 27/03/13 12:22, Jan Alexander Steffens wrote:
With pacman 4.1 just around the corner, we'll be getting support for split debug information soon.
I would like to recommend "-gdwarf-4 -fvar-tracking-assignments" as our default debug flags in makepkg.conf. These flags should allow for better debug information in the presence of optimization (less <value optimized out>; see man gcc).
This is probably a better reference than the man page: http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
Thoughts?
Note with gcc-4.8:
DWARF4 is now the default when generating DWARF debug information. When -g is used on a platform that uses DWARF debugging information, GCC will now default to -gdwarf-4 -fno-debug-types-section.
Any comments? You have ~12 hours...
I will use "-g -fvar-tracking-assignments" if no-one comments otherwise.
Allan
+1 Maybe this is a good opportunity to talk about debug packages in general. Do we enable for all our packages? Are we adding them into extra directly or are we creating a special repository like [debug] ? -- Ionuț
On 01/04/13 00:13, Ionut Biru wrote:
On 03/31/2013 05:08 PM, Allan McRae wrote:
On 27/03/13 12:49, Allan McRae wrote:
On 27/03/13 12:22, Jan Alexander Steffens wrote:
With pacman 4.1 just around the corner, we'll be getting support for split debug information soon.
I would like to recommend "-gdwarf-4 -fvar-tracking-assignments" as our default debug flags in makepkg.conf. These flags should allow for better debug information in the presence of optimization (less <value optimized out>; see man gcc).
This is probably a better reference than the man page: http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
Thoughts?
Note with gcc-4.8:
DWARF4 is now the default when generating DWARF debug information. When -g is used on a platform that uses DWARF debugging information, GCC will now default to -gdwarf-4 -fno-debug-types-section.
Any comments? You have ~12 hours...
I will use "-g -fvar-tracking-assignments" if no-one comments otherwise.
Allan
+1
Maybe this is a good opportunity to talk about debug packages in general. Do we enable for all our packages? Are we adding them into extra directly or are we creating a special repository like [debug] ?
I will add a glibc-debug package so I can get rid of all the custom stripping and just have that as a dep for gcc/valgrind. I have no intention of adding debug packages for anything else (unless it becomes a distro policy to include them). Allan
On Sunday 31 March 2013 17:13:21 Ionut Biru wrote:
Maybe this is a good opportunity to talk about debug packages in general. Do we enable for all our packages? Are we adding them into extra directly or are we creating a special repository like [debug] ?
I guess we should add them to all packages. No need to have a mass rebuild, just add them on rebuild/version bump or on request. -1 for a [debug] repo. -- Andrea Arch Linux Developer
Le lundi 1 avril 2013 00:27:11 Allan McRae a écrit :
On 01/04/13 00:13, Ionut Biru wrote:
On 03/31/2013 05:08 PM, Allan McRae wrote:
On 27/03/13 12:49, Allan McRae wrote:
On 27/03/13 12:22, Jan Alexander Steffens wrote:
With pacman 4.1 just around the corner, we'll be getting support for split debug information soon.
I would like to recommend "-gdwarf-4 -fvar-tracking-assignments" as our default debug flags in makepkg.conf. These flags should allow for better debug information in the presence of optimization (less <value optimized out>; see man gcc).
This is probably a better reference than the man page: http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
Thoughts?
Note with gcc-4.8:
DWARF4 is now the default when generating DWARF debug information. When -g is used on a platform that uses DWARF debugging information, GCC will now default to -gdwarf-4 -fno-debug-types-section.
Any comments? You have ~12 hours...
I will use "-g -fvar-tracking-assignments" if no-one comments otherwise.
Allan
+1
Maybe this is a good opportunity to talk about debug packages in general. Do we enable for all our packages? Are we adding them into extra directly or are we creating a special repository like [debug] ?
I will add a glibc-debug package so I can get rid of all the custom stripping and just have that as a dep for gcc/valgrind. I have no intention of adding debug packages for anything else (unless it becomes a distro policy to include them).
Allan
glibc is mandatory. I have a valgrind-multilib package in aur for the multilib one -- Laurent Carlier ArchLinux Trusted User http://www.archlinux.org
Am 31.03.2013 16:08, schrieb Allan McRae:
On 27/03/13 12:49, Allan McRae wrote:
Note with gcc-4.8:
DWARF4 is now the default when generating DWARF debug information. When -g is used on a platform that uses DWARF debugging information, GCC will now default to -gdwarf-4 -fno-debug-types-section.
Any comments? You have ~12 hours...
I will use "-g -fvar-tracking-assignments" if no-one comments otherwise.
What are the consequences here for packages? Does this increase package size by a large margin and will it slow down programs a lot? (Maybe break it down for people who are not that familiar with gcc and its new features; maybe you'll get more feedback then) Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
On 01/04/13 07:53, Pierre Schmitz wrote:
Am 31.03.2013 16:08, schrieb Allan McRae:
On 27/03/13 12:49, Allan McRae wrote:
Note with gcc-4.8:
DWARF4 is now the default when generating DWARF debug information. When -g is used on a platform that uses DWARF debugging information, GCC will now default to -gdwarf-4 -fno-debug-types-section.
Any comments? You have ~12 hours...
I will use "-g -fvar-tracking-assignments" if no-one comments otherwise.
What are the consequences here for packages? Does this increase package size by a large margin and will it slow down programs a lot? (Maybe break it down for people who are not that familiar with gcc and its new features; maybe you'll get more feedback then)
I will re-post this link then: http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html It theoretically should do nothing to the package. These options just ensure somewhat useful debugging symbols are generated during compile (which would slow down), but there are all removed during stripping... Allan
participants (6)
-
Allan McRae
-
Andrea Scarpino
-
Ionut Biru
-
Jan Alexander Steffens
-
Laurent Carlier
-
Pierre Schmitz