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

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