Mailing List Archive

> Anyways, this email is getting way too long. Patch is attached, let me
> know what you think.
Answering to myself here... this patch is against the 0.20-fixes branch,
but it should be easily portable to trunk. It's against -fixes because
it's intended to be shipped with the Ubuntu packages.


Regards,

Michael

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

On Sat, 2007-08-25 at 00:14 +0200, Michael Haas wrote:
> Hi,
>
> most ready-made MythTV packages are compiled with
> --compile-type=release. While this is great for the vast majority of
> users, it's impossible to debug segfaults properly with these packages
> because debug symbols are stripped. Even if dbg symbols were present,
> gcc optimizations would render backtraces generated from them useless.
>
> On the other hand, packages created using --compile-type=debug are
> slower which makes them unsuitable for environment which lack CPU
> ressources or where HDTV is to be displayed.
<snip>

Have you seen ticket #3589? Would that be compatible with apport?
If so, would it fill your needs. You can already compile with
compile type profile and get an optimized build with debugging
symbols. A profile build stack trace isn't as good as a debug
build one for debugging, but it is often sufficient. It also has
the benefit of having symbols for libavcodec, libavutil, which in
my experience generate most of the difficult segfaults. The downside
of the profile builds is that they still take up a lot of memory,
the release-dbg patch should mostly address that issue (but there
is still a 7% bloat penalty.)

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Daniel Kristjansson wrote:
> Have you seen ticket #3589? Would that be compatible with apport?
>
I'm not sure, I'll have to ask an apport wizard.
> If so, would it fill your needs. You can already compile with
> compile type profile and get an optimized build with debugging
> symbols.
#3589 looks interesting. I'm not sure if I understand what it does,
though. It strips the debugging symbols and puts them into a separate
file, right? For the Ubuntu packages, we're already doing that
ourselves. The build script has some clever magic which automatically
strips dbg symbols and puts them in separate packages. Atrpms seems to
have separate packages with debug symbols, too.
> A profile build stack trace isn't as good as a debug
> build one for debugging, but it is often sufficient.
I was told that "proper" debug builds are preferred over profile builds,
that's why I actually wrote that patch. Of course, I can't find relevant
IRC logs so I can't prove anything :) Consensus seemed to be that
optimized builds are too hard to debug.

> It also has
> the benefit of having symbols for libavcodec, libavutil, which in
> my experience generate most of the difficult segfaults.
In my patch, the debugging symbols are kept as well. It's essential a
debug build which uses -O3 for certain parts of MythTV.

Regards,

Michael


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

On Sat, 2007-08-25 at 01:35 +0200, Michael Haas wrote:
> Daniel Kristjansson wrote:
> > Have you seen ticket #3589? Would that be compatible with apport?
> >
> I'm not sure, I'll have to ask an apport wizard.
> > If so, would it fill your needs. You can already compile with
> > compile type profile and get an optimized build with debugging
> > symbols.
> #3589 looks interesting. I'm not sure if I understand what it does,
> though. It strips the debugging symbols and puts them into a separate
> file, right? For the Ubuntu packages, we're already doing that
> ourselves. The build script has some clever magic which automatically
> strips dbg symbols and puts them in separate packages. Atrpms seems to
> have separate packages with debug symbols, too.

Yes, it strips the debug symbols and places them in external files.
The Ubuntu packages may be doing the same magic as this patch, or
it may be doing something non-standard. If you could consult with
your apport wizard it might be a vote in favor of #3389. if Ubuntu
is already doing this.

> > A profile build stack trace isn't as good as a debug
> > build one for debugging, but it is often sufficient.
> I was told that "proper" debug builds are preferred over profile builds,
> that's why I actually wrote that patch. Of course, I can't find relevant
> IRC logs so I can't prove anything :) Consensus seemed to be that
> optimized builds are too hard to debug.

Yes, proper debug builds are preferred.

> > It also has
> > the benefit of having symbols for libavcodec, libavutil, which in
> > my experience generate most of the difficult segfaults.
> In my patch, the debugging symbols are kept as well. It's essential a
> debug build which uses -O3 for certain parts of MythTV.

Ah! That's really great then.

Ideally "release" would just build with the changes in #3589 and your
changes by default, if the toolchain supports external debugging
symbols. And only build a completely stripped release with some new
type such as "naked-release" or if an old toolchain was being used.
We might even be able to get rid of the "profile" compile flag if we
drop support for profiling with old toolchains.

The only real problem I can see with this is that avlib often breaks
when you combine gcc optimization with "-g", not a big deal to fix
once in a while for a profile build, but we might need to fix after
every other ffmpeg resync if debugging and optimization were enabled
for the avlib libraries under the "release" complile-type.

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Daniel Kristjansson wrote:
>
>
> Yes, it strips the debug symbols and places them in external files.
> The Ubuntu packages may be doing the same magic as this patch, or
> it may be doing something non-standard.

I haven't talked to a "wizard" ;) but I decided to take a look at apport
myself. I found a description of what it does at
<https://wiki.ubuntu.com/AptElfDebugSymbols> (scroll down to
"Implementation"); here's a quote:

> 2. Find all ELF files and call objcopy --only-keep-debug on them, and
put the symbols into /usr/lib/debug/original path into the -dbgsym
package. [..]
> 3. Create a gnu_debuglink to the place of debug symbols

That's about the same as #3589.

> If you could consult with
> your apport wizard it might be a vote in favor of #3389. if Ubuntu
> is already doing this.
>
>

Ubuntu is already doing this - in the package build script, dh_strip is
called which normally would strip the binaries. If you install a package
called "pkg-create-dbgsym", dh_strip is modified to automatically create
.ddeb packages which contain the symbols. As you see, there is no need
for a release-dbg build type for Ubuntu since it's already handled very
conveniently. Apport also uses the .ddebs to create backtraces.
(However, I'm not saying that release-dbg is not a great idea)

Our packages are built with "--compile-type=debug --tune=i486
--enable-proc-opt" (please don't ask me why we --tune=i486, I never
understood that myself). Our backtraces were rejected (eg
<http://svn.mythtv.org/trac/ticket/3561#comment:1>) and I was told that
the optimizations were breaking them. However, it just dawned on me that
"--enable-proc-opt" enables "-fomit-frame-pointer". Gah! That was
probably the cause for bad backtraces... anyways, -O3 was also lined out
to be a bad thing.

That's the whole point - the Ubuntu packages *could* already be profile
builds with the debug symbols stripped and put in separate .ddebs.
However, you're the first one to tell me that such backtraces would be
accepted. If that's true, I'm not sure if my patch is still needed.




_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

On Sat, 2007-08-25 at 13:05 +0200, Michael Haas wrote:
> Daniel Kristjansson wrote:
<snip>
I'll take this as a vote in favor of #3589, with the recognition
that it may require changes in how the packages are built.

> Our packages are built with "--compile-type=debug --tune=i486
> --enable-proc-opt" (please don't ask me why we --tune=i486, I never
> understood that myself).
Tune i486 is probably based on wanting the 10% speedup of cmov that
i486 has over i386, but still wanting to work on most Intel/AMD CPUs.
MMX and SSE can give a significant boost as well, but I'm not sure
how these options will be handled by configure, tune and enable-proc-opt
are not meant to be used together.

> Our backtraces were rejected (eg
> <http://svn.mythtv.org/trac/ticket/3561#comment:1>) and I was told that
> the optimizations were breaking them. However, it just dawned on me that
> "--enable-proc-opt" enables "-fomit-frame-pointer". Gah! That was
> probably the cause for bad backtraces... anyways, -O3 was also lined out
> to be a bad thing.
>
> That's the whole point - the Ubuntu packages *could* already be profile
> builds with the debug symbols stripped and put in separate .ddebs.
> However, you're the first one to tell me that such backtraces would be
> accepted. If that's true, I'm not sure if my patch is still needed.

This depends, while an optimized build can be debugged, it results in
non useful backtraces more often than non-optimized builds. This means
we need the users help to diagnose the problem. Tickets in our trac
are generated by users so we assume we will be able to get that help.
With automatically generated reports we don't have that help so they
should really go in a separate trac, where we just close tickets
without the overhead of describing why the backtrace is not useful.

Having full debugging on all the portions of MythTV that don't need to
be super optimized would make the backtraces more useful so I think this
change may be important. Can you add the patch to the #3589 ticket and
explain what it does (you can copy your initial e-mail)?

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Daniel Kristjansson wrote:
> <snip>
> I'll take this as a vote in favor of #3589, with the recognition
> that it may require changes in how the packages are built.
>

Let's hope it won't require changes - the current Ubuntu setup (with
separate debug packages created automagically etc) is already simple and
elegant enough to be kept around for a while, IMHO. Maybe there could be
two release-dbg targets: one with my changes and one with #3589, eg
partially optimized and symbols put in a different file.

Axel Thimm has separate .rpm files for symbols, too - I wonder how he
makes them and if he'd benefit from #3589. Still, #3589 seems to make a
lot of sense for people building at home or for distributions which
currently don't provide dbg symbols.

> Tune i486 is probably based on wanting the 10% speedup of cmov that
> i486 has over i386, but still wanting to work on most Intel/AMD CPUs.
>
Google tells me that cmov was introduced with the pentium pro.
Unfortunately, some VIA CPUs don't support CMOV.


> MMX and SSE can give a significant boost as well, but I'm not sure
> how these options will be handled by configure, tune and enable-proc-opt
> are not meant to be used together.
>
>
We'll stop using --enable-proc-opt soon, I think. Also, we're already
using --enable-mmx (forgot to mention that).

>> This depends, while an optimized build can be debugged, it results in
>> non useful backtraces more often than non-optimized builds. This means
>> we need the users help to diagnose the problem. Tickets in our trac
>> are generated by users so we assume we will be able to get that help.
>> With automatically generated reports we don't have that help so they
>> should really go in a separate trac, where we just close tickets
>> without the overhead of describing why the backtrace is not useful.
>>
Thanks for clarifying that. We do have our own bug tracker at
<http://launchpad.net>, but I'm not sure if the MythTV developers would
like to use that. The first tickets we submitted were automatically sent
to our bug tracker, BTW, and forwarded manually to trac. If you're just
concerned about closing tickets without giving a lengthy reason - no
worries, we wouldn't be offended. :)

>> Can you add the patch to the #3589 ticket and
>> explain what it does (you can copy your initial e-mail)?
>>
>>
Yes.


Regards,

Michael


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

> Axel Thimm has separate .rpm files for symbols, too - I wonder how he
> makes them and if he'd benefit from #3589. Still, #3589 seems to make a

They are made automatically during the rpm build, you can look at the rpm
macros file to see how (%_enable_debug_packages is on by default, look where
it is used to start).

--
Anduin Withers

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

On Sat, Aug 25, 2007 at 04:20:32PM -0700, Anduin Withers wrote:
> > Axel Thimm has separate .rpm files for symbols, too - I wonder how he
> > makes them
>
> They are made automatically during the rpm build, you can look at the rpm
> macros file to see how (%_enable_debug_packages is on by default, look where
> it is used to start).

As Anduin writes there is no special action I perform, these
subpackages containing the debug infomration are generated
automatically. gdb on Fedora/RHEL is patched to look at the package's
locations for symbols also, so when backtracing all one needs to do is
install the foo-debuginfo subpackage.

If you want to know what the magic behind this is, rpm's mechanism is
in these two files:

http://hg.rpm.org/rpm?f=8f9ea7816e01;file=scripts/find-debuginfo.sh
http://hg.rpm.org/rpm?f=f0f2ff6c8bfc;file=tools/debugedit.c

--
Axel.Thimm at ATrpms.net