Patchwork package.bbclass: add debug-without-src PACKAGE_DEBUG_SPLIT_STYLE

login
register
mail settings
Submitter Martin Jansa
Date March 12, 2013, 11:24 a.m.
Message ID <1363087472-32085-1-git-send-email-Martin.Jansa@gmail.com>
Download mbox | patch
Permalink /patch/46045/
State Accepted
Commit 3c8452c3abae74a42989c0fbd5ba303788528750
Headers show

Comments

Martin Jansa - March 12, 2013, 11:24 a.m.
* same as original and default version, but does not package source files in PN-dbg

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/classes/package.bbclass | 6 ++++++
 1 file changed, 6 insertions(+)
Ross Burton - March 12, 2013, 3:28 p.m.
On 12 March 2013 04:24, Martin Jansa <martin.jansa@gmail.com> wrote:
> * same as original and default version, but does not package source files in PN-dbg

You can mark this as closing
https://bugzilla.yoctoproject.org/show_bug.cgi?id=3621, which would be
good for my bug list.  Richard had concerns that he listed in the bug,
so having done tests and demonstrating that the loss of source doesn't
impact the usefulness of the debug files would be good.

Ross
Mark Hatle - March 12, 2013, 3:38 p.m.
On 3/12/13 10:28 AM, Burton, Ross wrote:
> On 12 March 2013 04:24, Martin Jansa <martin.jansa@gmail.com> wrote:
>> * same as original and default version, but does not package source files in PN-dbg
>
> You can mark this as closing
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=3621, which would be
> good for my bug list.  Richard had concerns that he listed in the bug,
> so having done tests and demonstrating that the loss of source doesn't
> impact the usefulness of the debug files would be good.

I am curious as to the use of the dbg package (w/o) source on the target system.

In my experience, the dbg binaries are useless without the associated source. 
Most of the people I know either use an on-target debugger or a cross debugger, 
both of which need the associated sources to tell you anything about what is 
going on.

For someone who just wants pure backtrace information, it's usually easier to 
avoid the whole split-and-strip process that generates the dbg files.  But of 
course this can sacrifice the usefulness of being able to do field debugging.

(Note, I'm not against the patch.. it looks fine to me... I just don't 
understand the usefulness..  other then the associated defect says they are "too 
big", which again, I don't doubt.)

--Mark

> Ross
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Martin Jansa - March 13, 2013, 2:08 p.m.
On Tue, Mar 12, 2013 at 10:38:33AM -0500, Mark Hatle wrote:
> On 3/12/13 10:28 AM, Burton, Ross wrote:
> > On 12 March 2013 04:24, Martin Jansa <martin.jansa@gmail.com> wrote:
> >> * same as original and default version, but does not package source files in PN-dbg
> >
> > You can mark this as closing
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=3621, which would be
> > good for my bug list.  Richard had concerns that he listed in the bug,
> > so having done tests and demonstrating that the loss of source doesn't
> > impact the usefulness of the debug files would be good.
> 
> I am curious as to the use of the dbg package (w/o) source on the target system.
> 
> In my experience, the dbg binaries are useless without the associated source. 
> Most of the people I know either use an on-target debugger or a cross debugger, 
> both of which need the associated sources to tell you anything about what is 
> going on.
> 
> For someone who just wants pure backtrace information, it's usually easier to 
> avoid the whole split-and-strip process that generates the dbg files.  But of 
> course this can sacrifice the usefulness of being able to do field debugging.
> 
> (Note, I'm not against the patch.. it looks fine to me... I just don't 
> understand the usefulness..  other then the associated defect says they are "too 
> big", which again, I don't doubt.)

I've added my use-case for this in bug report:

My use case was a bit different: to be able to build proprietary blobs
with OE and exchange resulting .ipk files with partners without
revealing source in PN-dbg.

So better backtrace is all we want from PN-dbg and devs with access to 
sources can download/checkout source on target (while using the same 
PN-dbg package to reproduce reported issue).

Patch

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 1625ebd..f3a6bc7 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -682,6 +682,12 @@  python split_and_strip_files () {
         debugdir = ""
         debuglibdir = "/usr/lib/debug"
         debugsrcdir = "/usr/src/debug"
+    elif d.getVar('PACKAGE_DEBUG_SPLIT_STYLE', True) == 'debug-without-src':
+        # Original OE-core, a.k.a. ".debug", style debug info, but without sources in /usr/src/debug
+        debugappend = ""
+        debugdir = "/.debug"
+        debuglibdir = ""
+        debugsrcdir = ""
     else:
         # Original OE-core, a.k.a. ".debug", style debug info
         debugappend = ""