Mandatory -dbg packages

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Mandatory -dbg packages

Vincent Bernat-3
Hi!

Libraries with `-dbg` package are a pain to deal with when debugging
some problem. The solution to ask each user to rebuild the library
without stripping debug symbols[1] seem suboptimal. Asking each
maintainer to ship a `-dbg` package may be a solution[2] but couldn't we
generate those packages automatically by the builders, like this is done
with Ubuntu[3]?

I remember we had a discussion about this a few years ago. An automatic
service has been setup for this[4] by myon but it does not seem to be
updated anymore.

Why does this experiment have been stopped? Could we mainstream it?

[1]: http://wiki.debian.org/HowToGetABacktrace
[2]: http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/18-Mandatory-dbg-packages-for-libraries.html
[3]: https://wiki.ubuntu.com/DebuggingProgramCrash
[4]: http://debug.debian.net/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/m3ip9w8b50.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Andrey Rahmatullin
On Sat, Oct 27, 2012 at 12:25:31PM +0200, Vincent Bernat wrote:
> Libraries with `-dbg` package are a pain to deal with when debugging
> some problem.
You probably mean "without".

--
WBR, wRAR

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Vincent Bernat-3
 ❦ 27 octobre 2012 12:42 CEST, Andrey Rahmatullin <[hidden email]> :

>> Libraries with `-dbg` package are a pain to deal with when debugging
>> some problem.
> You probably mean "without".

Yes.
--
printk(KERN_WARNING "Multi-volume CD somehow got mounted.\n");
        2.2.16 /usr/src/linux/fs/isofs/inode.c

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Игорь Пашев
Do not kick me, but in Solaris, there are :

1) special ELF section .SUNW_ldynsym extending .dynsym [1]
2) .SUNW_ctf with CTF data [2]
3) Function args are saved in stack for amd64

But from my point all it exists because Solaris lacks robust
package manager :-)

[2] http://hub.opensolaris.org/bin/view/Project+ppc-dev/ctf

2012/10/27 Vincent Bernat <[hidden email]>
 ❦ 27 octobre 2012 12:42 CEST, Andrey Rahmatullin <[hidden email]> :

>> Libraries with `-dbg` package are a pain to deal with when debugging
>> some problem.
> You probably mean "without".

Yes.
--
printk(KERN_WARNING "Multi-volume CD somehow got mounted.\n");
        2.2.16 /usr/src/linux/fs/isofs/inode.c

Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Michael Biebl-3
In reply to this post by Vincent Bernat-3
On 27.10.2012 12:25, Vincent Bernat wrote:

> Hi!
>
> Libraries with `-dbg` package are a pain to deal with when debugging
> some problem. The solution to ask each user to rebuild the library
> without stripping debug symbols[1] seem suboptimal. Asking each
> maintainer to ship a `-dbg` package may be a solution[2] but couldn't we
> generate those packages automatically by the builders, like this is done
> with Ubuntu[3]?
>
> I remember we had a discussion about this a few years ago. An automatic
> service has been setup for this[4] by myon but it does not seem to be
> updated anymore.
>
> Why does this experiment have been stopped? Could we mainstream it?
>
Afaik the work was started by pochu as port of GSoC [1][2]. According to
[3], Marc was his mentor. I've CCed both, maybe they can comment on
what's still missing.
I'd love to see that happen.

Michael


[1] http://wiki.debian.org/EmilioPozueloMonfort/GSoC2009Ddebs
[2] http://wiki.debian.org/AutomaticDebugPackages
[3]
http://wiki.debian.org/SummerOfCode2009#Automatic_Debug_Packages_Creation_and_Handling

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


signature.asc (918 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Philip Ashmore
On 27/10/12 19:30, Michael Biebl wrote:

> On 27.10.2012 12:25, Vincent Bernat wrote:
>> Hi!
>>
>> Libraries with `-dbg` package are a pain to deal with when debugging
>> some problem. The solution to ask each user to rebuild the library
>> without stripping debug symbols[1] seem suboptimal. Asking each
>> maintainer to ship a `-dbg` package may be a solution[2] but couldn't we
>> generate those packages automatically by the builders, like this is done
>> with Ubuntu[3]?
>>
>> I remember we had a discussion about this a few years ago. An automatic
>> service has been setup for this[4] by myon but it does not seem to be
>> updated anymore.
>>
>> Why does this experiment have been stopped? Could we mainstream it?
>>
>
> Afaik the work was started by pochu as port of GSoC [1][2]. According to
> [3], Marc was his mentor. I've CCed both, maybe they can comment on
> what's still missing.
> I'd love to see that happen.
Yeah, in (cough)Fedora, kdbg even offers to download and install debug
packages for you.
Debug packages also make back-traces more than useless, and
(cough)Ubuntu offers to download debug packages which it installs and
re-examines the back-trace to see if more are needed.
Having the sources installed in /usr/src and referenced there rather
than /buildd would be an improvement too.

If there's a way to re-path debug information from /home/user/x or
/buildd to /usr/src then that would be great.

One less reason for Debians build process to need a fake root.
> Michael
>
>
> [1] http://wiki.debian.org/EmilioPozueloMonfort/GSoC2009Ddebs
> [2] http://wiki.debian.org/AutomaticDebugPackages
> [3]
> http://wiki.debian.org/SummerOfCode2009#Automatic_Debug_Packages_Creation_and_Handling
Philip


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/508CE6CD.4000606@...

Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Timo Lindfors-2
Philip Ashmore <[hidden email]> writes:
> Debug packages also make back-traces more than useless, and

They also allow systemtap to probe userland binaries once
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691167 is fixed.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/84ehkjt2vm.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Bernhard R. Link-2
In reply to this post by Philip Ashmore
* Philip Ashmore <[hidden email]> [121028 09:12]:
> Yeah, in (cough)Fedora, kdbg even offers to download and install
> debug packages for you.
> Debug packages also make back-traces more than useless, and
> (cough)Ubuntu offers to download debug packages which it installs
> and re-examines the back-trace to see if more are needed.

While having some way to get the stripped debug info from the installed
packages is nice to more easily get some debug information or to
retroactively make a backtrace a bit more verbose, it is still not
enough for all cases of debugging. Ideal debugging information you get
by locally rebuilding the needed libraries with
DEB_BUILD_OPTIONS="noopt nostrip" and installing those.
(Sadly not all libraries support noopt, but it's getting much better as a
side effect of the current hardening effords).

        Bernhard R. Link


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20121028103552.GA3132@...

Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Ben Hutchings-3
On Sun, 2012-10-28 at 11:35 +0100, Bernhard R. Link wrote:

> * Philip Ashmore <[hidden email]> [121028 09:12]:
> > Yeah, in (cough)Fedora, kdbg even offers to download and install
> > debug packages for you.
> > Debug packages also make back-traces more than useless, and
> > (cough)Ubuntu offers to download debug packages which it installs
> > and re-examines the back-trace to see if more are needed.
>
> While having some way to get the stripped debug info from the installed
> packages is nice to more easily get some debug information or to
> retroactively make a backtrace a bit more verbose, it is still not
> enough for all cases of debugging. Ideal debugging information you get
> by locally rebuilding the needed libraries with
> DEB_BUILD_OPTIONS="noopt nostrip" and installing those.
> (Sadly not all libraries support noopt, but it's getting much better as a
> side effect of the current hardening effords).
There are plenty of bugs that involve 'undefined behaviour' that in
practice depends on whether optimisation is enabled.  Unless you have a
good idea what's going wrong, how do you know that 'noopt' won't hide
the bug?  Also, gdb and the GNU toolchain have recently got a lot better
at handling highly optimised code (tracking variables in registers,
treating inlined functions as logically separate functions, etc.).

Ben.

--
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Wouter Verhelst
In reply to this post by Philip Ashmore
On Sun, Oct 28, 2012 at 08:03:25AM +0000, Philip Ashmore wrote:
> Having the sources installed in /usr/src and referenced there rather
> than /buildd would be an improvement too.

That's why there is the 'substitute-path' feature in gdb to fix that. Also see
http://grep.be/blog/en/computer/code/gdb_substitute_path

--
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20121028160936.GF23376@...

Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Bernhard R. Link-2
In reply to this post by Ben Hutchings-3
* Ben Hutchings <[hidden email]> [121028 17:02]:
> There are plenty of bugs that involve 'undefined behaviour' that in
> practice depends on whether optimisation is enabled.  Unless you have a
> good idea what's going wrong, how do you know that 'noopt' won't hide
> the bug?

If the bug still shows up with the library recompiled with 'noopt', then
no harm done. If it is a bug in the library, you want to look there
anyway (and you will most likely want to compile different parts of it
with or without optimisation or any other technique; in any case you
will want more of the library than just the binary and some debugging
symbols of it). The only case where a noopt library variant is a
disadvantage is a very ugly case of heisenbug, that is hidden by the
slightly changed library.

> Also, gdb and the GNU toolchain have recently got a lot better
> at handling highly optimised code (tracking variables in registers,
> treating inlined functions as logically separate functions, etc.).

Yeah, they got a lot better. But even if gdb got perfect in that regard
it can still not show what isn't there (like the value of a variable
(or function argument passed as register) no longer stored anywhere.

        Bernhard R. Link


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20121028163707.GA19001@...

Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Philip Ashmore
In reply to this post by Wouter Verhelst
On 28/10/12 16:09, Wouter Verhelst wrote:
> On Sun, Oct 28, 2012 at 08:03:25AM +0000, Philip Ashmore wrote:
>> Having the sources installed in /usr/src and referenced there rather
>> than /buildd would be an improvement too.
>
> That's why there is the 'substitute-path' feature in gdb to fix that. Also see
> http://grep.be/blog/en/computer/code/gdb_substitute_path
While this feature allows gdb to know the correct source locations,
using it implies that packages requiring the feature contain incorrect
source paths - wouldn't it be better for these packages to contain
correct source paths in the first place?

Regards,
Philip


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/508DD2C3.9090006@...

Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Paul Wise via nm
On Mon, Oct 29, 2012 at 8:50 AM, Philip Ashmore wrote:

> While this feature allows gdb to know the correct source locations, using it
> implies that packages requiring the feature contain incorrect source paths -
> wouldn't it be better for these packages to contain correct source paths in
> the first place?

There is no such thing as a "correct source path", I unpack source
tarballs to ~/tmp/ when debugging, you seem to use /usr/src/ and John
Doe uses ~/src/debian/pool/f/foo/foo-0.1/.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/CAKTje6FyXaEmW2uPvzyn2=3Qhn_AVReGh8w0BKn89zogiOtR-g@...

Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Neil Williams-4
On Mon, 29 Oct 2012 08:53:05 +0800
Paul Wise <[hidden email]> wrote:

> On Mon, Oct 29, 2012 at 8:50 AM, Philip Ashmore wrote:
>
> > While this feature allows gdb to know the correct source locations, using it
> > implies that packages requiring the feature contain incorrect source paths -
> > wouldn't it be better for these packages to contain correct source paths in
> > the first place?
>
> There is no such thing as a "correct source path", I unpack source
> tarballs to ~/tmp/ when debugging, you seem to use /usr/src/ and John
> Doe uses ~/src/debian/pool/f/foo/foo-0.1/.
The "correct source path" for gdb is whatever the user has put into
~/.gdbinit - the paths inside the package don't matter.

dir /path/one/
dir /path/another/

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/


attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Marc Brockschmidt-4
In reply to this post by Michael Biebl-3


Michael Biebl <[hidden email]> wrote:
>Afaik the work was started by pochu as port of GSoC [1][2]. According
>to
>[3], Marc was his mentor. I've CCed both, maybe they can comment on
>what's still missing.
>I'd love to see that happen.

Joss ended up being the mentor (melange lists this correctly). I don't remember at all how this worked out...

Marc

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/574f2c09-8cbc-483a-8ec2-3155c1a860d3@...

Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Philip Ashmore
In reply to this post by Neil Williams-4
On 29/10/12 07:25, Neil Williams wrote:

> On Mon, 29 Oct 2012 08:53:05 +0800
> Paul Wise<[hidden email]>  wrote:
>
>> On Mon, Oct 29, 2012 at 8:50 AM, Philip Ashmore wrote:
>>
>>> While this feature allows gdb to know the correct source locations, using it
>>> implies that packages requiring the feature contain incorrect source paths -
>>> wouldn't it be better for these packages to contain correct source paths in
>>> the first place?
>>
>> There is no such thing as a "correct source path", I unpack source
>> tarballs to ~/tmp/ when debugging, you seem to use /usr/src/ and John
>> Doe uses ~/src/debian/pool/f/foo/foo-0.1/.
>
> The "correct source path" for gdb is whatever the user has put into
> ~/.gdbinit - the paths inside the package don't matter.
>
> dir /path/one/
> dir /path/another/
In Fedora, the dbg package includes the source code for the package, and
the debug information points to it.
In Fedora, by convention, such source code goes under /usr/src.

If you prefer your users mess with .gdbinit so they can create a useful
stack trace then that's up to you.

Philip


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/508E5EF8.6010301@...

Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Tzafrir Cohen
In reply to this post by Philip Ashmore
On Sun, Oct 28, 2012 at 08:03:25AM +0000, Philip Ashmore wrote:

> Yeah, in (cough)Fedora, kdbg even offers to download and install debug  
> packages for you.
> Debug packages also make back-traces more than useless, and  
> (cough)Ubuntu offers to download debug packages which it installs and  
> re-examines the back-trace to see if more are needed.

While clearing your throat, mind telling us how this works in Ubuntu
with PPAs? What happens if you installed a package from a PPA and you
want to generate a backtrace of a program that happens to use that
package?

1. You'll get debug information for the package.
2. You won't get debug information for the package.
3. You may accidentally get debug information for a diffent version of
   the package.

--
Tzafrir Cohen         | [hidden email] | VIM is
http://tzafrir.org.il |                    | a Mutt's
[hidden email] |                    |  best
[hidden email]    |                    | friend


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20121029142905.GX12721@...

Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Stefano Rivera-15
Hi Tzafrir (2012.10.29_16:29:06_+0200)
> While clearing your throat, mind telling us how this works in Ubuntu
> with PPAs? What happens if you installed a package from a PPA and you
> want to generate a backtrace of a program that happens to use that
> package?
>
> 1. You'll get debug information for the package.
> 2. You won't get debug information for the package.
> 3. You may accidentally get debug information for a diffent version of
>    the package.

2. It'll tell you that there aren't any debug symbols available. (IIRC)

The -dbgsym packages are only generated in primary archive builds.

SR

--
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 461 1230 C: +27 72 419 8559


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20121029145730.GD1621@...

Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Andriy Grytsenko
    Hello!

Stefano Rivera has written on Monday, 29 October, at 16:57:
>Hi Tzafrir (2012.10.29_16:29:06_+0200)
>> While clearing your throat, mind telling us how this works in Ubuntu
>> with PPAs? What happens if you installed a package from a PPA and you
>> want to generate a backtrace of a program that happens to use that
>> package?

>> 1. You'll get debug information for the package.
>> 2. You won't get debug information for the package.
>> 3. You may accidentally get debug information for a diffent version of
>>    the package.

>2. It'll tell you that there aren't any debug symbols available. (IIRC)

>The -dbgsym packages are only generated in primary archive builds.

    I'm sorry to disappoint you about the Ubuntu PPAs but look into my
PPA - https://launchpad.net/~andrej-rep/+archive/ppa/+packages - to see
all those dbg packages. And users were used them to give me feedback to
bugs with full backtrace.

    Cheers!
    Andriy.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20121029151841.GB9298@...

Reply | Threaded
Open this post in threaded view
|

Re: Mandatory -dbg packages

Wouter Verhelst
In reply to this post by Philip Ashmore
On Mon, Oct 29, 2012 at 10:48:24AM +0000, Philip Ashmore wrote:
> >>On Mon, Oct 29, 2012 at 8:50 AM, Philip Ashmore wrote:
> >>>While this feature allows gdb to know the correct source locations, using it
> >>>implies that packages requiring the feature contain incorrect source paths -
> >>>wouldn't it be better for these packages to contain correct source paths in
> >>>the first place?
[...]
> In Fedora, the dbg package includes the source code for the package,
> and the debug information points to it.

In Debian, they do not, and that's a feature; first, there are many
valid use cases of using debug packages that do not require the source
code. Second, having the source in the debug package implies duplication
of said source, which is a waste of space.

> In Fedora, by convention, such source code goes under /usr/src.

Actually, on RPM-based systems, installing a source package implies the
source goes in to /usr/src somewhere; even if you built an RPM source
package with source living in $HOME, installing it will still make the
source go into /usr/src. In that light, it makes sense that they have
their debug packages point towards that directory.

In Debian, installing a source package is just not possible technically;
you can only unpack them. When you do that, by default they get unpacked
in your current working directory. In other words, the location of the
actual source in a source package on a Debian system is utterly
unpredictable, and so there is no such concept as a "correct source
location" on Debian-based systems.

> If you prefer your users mess with .gdbinit so they can create a
> useful stack trace then that's up to you.

There is no need for source to be able to produce a useful stack trace;
the file and function names are part of the debugging symbols. In other
words, once you install the debugging symbols -- regardless of where
they think the source lives -- you will be able to produce a useful
stack trace.

The only reason why you'd want to connect the source to the debugging
symbold is because you need to connect the original source lines to the
object code that you're inspecting -- e.g., because you're
single-stepping through a library. While doing that can be useful in
some corner cases, it's not something I expect a random user would ever
need to do.

--
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.

signature.asc (853 bytes) Download Attachment
12