FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-07-2008, 01:42 PM
Sune Vuorela
 
Default Policy or best practices for debug packages?

On 2008-07-07, Mike Hommey <mh@glandium.org> wrote:
>
> /usr/lib/debug/$pathoforiginalfile
>
> This is where gdb is going to look for these debug info.
>

I thought gdb was looking at the .gnu_debuglink section as created with
objcopy?

Qt4 at least creates debug stuff slightly diferent, but are still picked
up by gdb.

/Sune


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-07-2008, 02:56 PM
Theodore Tso
 
Default Policy or best practices for debug packages?

On Mon, Jul 07, 2008 at 02:41:50PM +0200, Mike Hommey wrote:
> > *) Do we dump everything into /usr/lib/debug, i.e.,
> > /usr/lib/debug/sbin/e2fsck? Or should we put it in
> > /usr/lib/debug/<pkg>, i.e., /usr/lib/debug/e2fsprogs/sbin/e2fsck?
> > Most packages I've seen seem to be doing the former.
>
> /usr/lib/debug/$pathoforiginalfile
>
> This is where gdb is going to look for these debug info.

Yep, that's what everyone else is doing, so that's what I did too with
e2fsprogs.

> > *) Is it OK to include the -dbg information in a library's -dev package?
> > Or should it be separated out? Otherwise as more and more packages
> > start creating -dbg packages, the number of packages we have in the
> > debian archive could grow significantly.
>
> I think the problem is going to be with size way before becoming a problem
> with the number of packages.

I tried putting them in -dev, and lintian complains with a warning.
So I guess while it isn't official policy yet, it seems to be the
general practice. The e2fsprogs source package just grew an extra 7
binary packages as a result for a total of 20 packages, though. :-)

> > *) Red Hat includes source files in their debuginfo files, which means
> > that their support people can take a core file and get instant feedback
> > as to the line in the source where the crash happened. But that also
> > means that their debuginfo packages are so huge they don't get included
> > on any DVD's, but have to be downloaded from somebody's home directory
> > at redhat.com. (which appears not to be published, but which is very
> > easy to google for. :-) What do we want to do?
>
> You don't need source files in the debuginfo files to get line numbers.
> You only need line tracking information, and if you build with -g, that is
> already what you get.

True, although it means there's a bit more work to actually install
the source package, and then running "./debian/rules build" in order
to make sure the sources are unpacked and patches appropriately
applied. With Red Hat all you have to do is unpack the debuginfo
package, and the sources that were used to build the binaries are made
available with no muss and no fuss in
/usr/lib/debug/usr/src/<pkgname>". (And an obvious thing for Red Hat
to have done is to hack gdb to automatically figure out the location
of the source files, possibly by encoding it in the build-id ---
although I don't know if they have done it.0

Is this worth the bloat in packages, especially since the -dbg
packages are architecture specific and thus would be replicated N
times? Probably not, but it's at least worth thinking about the
functionality and deciding whether we want to replicate it.

Speaking of the -g option, does anyone know off-hand whether or not
it's worth it to build with -g3 (to get cpp macro definitions into the
DWARF stubs)?

> Note that it would be better for our users if we could have a debug info
> server instead of having them install dbg packages, it could be nicer.
> Obviously, gdb would need to be able to talk to it.

Yep, agreed. That would be nice.

I will say that having started to build and installing the debug debug
packages, for e2fsprogs, being able to run gdb on installed system
binaries is *definitely* very nice. :-)

- Ted


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-07-2008, 03:24 PM
Mike Hommey
 
Default Policy or best practices for debug packages?

On Mon, Jul 07, 2008 at 10:56:14AM -0400, Theodore Tso <tytso@MIT.EDU> wrote:
> I tried putting them in -dev, and lintian complains with a warning.
> So I guess while it isn't official policy yet, it seems to be the
> general practice. The e2fsprogs source package just grew an extra 7
> binary packages as a result for a total of 20 packages, though. :-)

You don't need to have a strict mapping between binary packages and their dbg
counterpart. For example, xulrunner-1.9-dbg has debugging symbols for all
binary packages xulrunner builds.

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-07-2008, 03:39 PM
Mike Hommey
 
Default Policy or best practices for debug packages?

On Mon, Jul 07, 2008 at 10:56:14AM -0400, Theodore Tso <tytso@MIT.EDU> wrote:
> True, although it means there's a bit more work to actually install
> the source package, and then running "./debian/rules build" in order
> to make sure the sources are unpacked and patches appropriately
> applied. With Red Hat all you have to do is unpack the debuginfo
> package, and the sources that were used to build the binaries are made
> available with no muss and no fuss in
> /usr/lib/debug/usr/src/<pkgname>". (And an obvious thing for Red Hat
> to have done is to hack gdb to automatically figure out the location
> of the source files, possibly by encoding it in the build-id ---
> although I don't know if they have done it.0
>
> Is this worth the bloat in packages, especially since the -dbg
> packages are architecture specific and thus would be replicated N
> times? Probably not, but it's at least worth thinking about the
> functionality and deciding whether we want to replicate it.

Actually, I don't think it is any useful to have source shipped in some
way, by default, at least.

There are 3 kind of people who need -dbg packages.
- Users, when they are asked to provide proper backtraces in bug reports
- Developers, when they need to debug stuff
- Maintainers

Obviously, the latter will be able to get the sources themselves, so do
the second, most of the time, though the debian/rules patch thing might be
a problem, especially when you need to install cdbs or some other stuff to
get it working (only to apply dumb patches, d'uh).

Users, on the other hand, don't need the source. They don't even need the
-dbg packages. They just got in a situation where they were asked to install
it to help the maintainers. Which, by the way, may end up useless because
the user may not get the same crash. And she won't have a core for the
previous crash because the default is not to core (and BTW, it's uselessly
made difficult to override this, see #487879).

It would be nice to get bug-buddy and others to actually dump the process
memory to some file...

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-07-2008, 04:03 PM
Theodore Tso
 
Default Policy or best practices for debug packages?

On Mon, Jul 07, 2008 at 05:39:00PM +0200, Mike Hommey wrote:
> There are 3 kind of people who need -dbg packages.
> - Users, when they are asked to provide proper backtraces in bug reports
> - Developers, when they need to debug stuff
> - Maintainers
>
> Obviously, the latter will be able to get the sources themselves, so do
> the second, most of the time, though the debian/rules patch thing might be
> a problem, especially when you need to install cdbs or some other stuff to
> get it working (only to apply dumb patches, d'uh).

Well, maybe the dpkg-source 3.0 package formats will make this easier.
It should would be nice if there was a standardized debian/rules
target which would unpack the source tarballs and apply any necessary
patches, such that the sources were in a state usable by gdb, though.

And there was a way that something like "apt-get source" would
automatically run the rule, perhaps on an appropriate command-line
option, even better.

> And she won't have a core for the
> previous crash because the default is not to core (and BTW, it's uselessly
> made difficult to override this, see #487879).

I just looked at this bug, and are you sure this isn't because you
have this configured in /etc/security/limits.conf?

- Ted


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-07-2008, 06:02 PM
Joerg Jaspert
 
Default Policy or best practices for debug packages?

On 11439 March 1977, Theodore Ts'o wrote:

> *) I assume that the priority of -dbg packages is extra

s/I assume that//
s/$/!/

> *) What section should -dbg packages be placed into? Should it be the
> section that the parent package is in, or something like "devel"?

Currently usually the same as the parent package.

--
bye, Joerg
[...]
While Debian is certainly about beer, and in some cases may even be
about free beer, Debian is mainly about free speech.
 
Old 07-07-2008, 06:30 PM
Mike Hommey
 
Default Policy or best practices for debug packages?

On Mon, Jul 07, 2008 at 12:03:40PM -0400, Theodore Tso wrote:
> > And she won't have a core for the
> > previous crash because the default is not to core (and BTW, it's uselessly
> > made difficult to override this, see #487879).
>
> I just looked at this bug, and are you sure this isn't because you
> have this configured in /etc/security/limits.conf?

Actually, I don't know what I've been smoking... it works as expected.
O_o

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-07-2008, 06:48 PM
Roger Leigh
 
Default Policy or best practices for debug packages?

Theodore Tso <tytso@MIT.EDU> writes:

> Speaking of the -g option, does anyone know off-hand whether or not
> it's worth it to build with -g3 (to get cpp macro definitions into the
> DWARF stubs)?

-g3 is also needed to get sane debugging information for C++ code,
IME. It would be nice if it was the default, unless there's huge
overhead in terms of bloating up the DWARF2 .debug_* sections.


--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 07-07-2008, 06:52 PM
Mike Hommey
 
Default Policy or best practices for debug packages?

On Mon, Jul 07, 2008 at 07:48:27PM +0100, Roger Leigh wrote:
> Theodore Tso <tytso@MIT.EDU> writes:
>
> > Speaking of the -g option, does anyone know off-hand whether or not
> > it's worth it to build with -g3 (to get cpp macro definitions into the
> > DWARF stubs)?
>
> -g3 is also needed to get sane debugging information for C++ code,
> IME. It would be nice if it was the default, unless there's huge
> overhead in terms of bloating up the DWARF2 .debug_* sections.

I've always found -g to be enough with mozilla and webkit c++ code
bases. What would -g3 add ?

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-07-2008, 09:06 PM
Roger Leigh
 
Default Policy or best practices for debug packages?

Mike Hommey <mh@glandium.org> writes:

> On Mon, Jul 07, 2008 at 07:48:27PM +0100, Roger Leigh wrote:
>> Theodore Tso <tytso@MIT.EDU> writes:
>>
>> > Speaking of the -g option, does anyone know off-hand whether or not
>> > it's worth it to build with -g3 (to get cpp macro definitions into the
>> > DWARF stubs)?
>>
>> -g3 is also needed to get sane debugging information for C++ code,
>> IME. It would be nice if it was the default, unless there's huge
>> overhead in terms of bloating up the DWARF2 .debug_* sections.
>
> I've always found -g to be enough with mozilla and webkit c++ code
> bases. What would -g3 add ?

Correct line numbers when dealing with inline templates, for one.
There were some other niceties, but I can't recall what they were off
the top of my head.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 

Thread Tools




All times are GMT. The time now is 03:47 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org