All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pascal Hürst" <pascal.huerst@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] Adding google-breakpad to buildroot
Date: Wed, 23 Apr 2014 18:12:32 +0200	[thread overview]
Message-ID: <1398269552.30640.13.camel@mbpro.localhost> (raw)
In-Reply-To: <CAHXCMMKSGHSvYLr9JALDr0YzD4uTshQrNZYm46-0kgGpUP4Ptw@mail.gmail.com>

On Mit, 2014-04-23 at 17:52 +0200, Samuel Martin wrote:
> Hi Pascal, Arnout, all,
> 
> On Wed, Apr 23, 2014 at 5:29 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> > On 23/04/14 16:21, Pascal H?rst wrote:
> >> Hi everyone,
> >>
> >> we are planing to add google-breakpad to buildroot.
> >>
> >> From the project description at
> >> http://code.google.com/p/google-breakpad/:
> >>
> >> [...] "Breakpad is a library and tool suite that allows you to
> >> distribute an application to users with compiler-provided debugging
> >> information removed, record crashes in compact "minidump" files, send
> >> them back to your server, and produce C and C++ stack traces from these
> >> minidumps." [...]
> >>
> >> Adding a package to buildroot is easy, but in this case we will have to
> >> find a way to extract all symbols from the target binaries, before they
> >> get stripped.
> 
> Here, you mean adding the host-breakpad package, right?

I acutally mean both sides. Right now it (*.mk) looks something like
that:

GOOGLE_BREAKPAD_VERSION = 1276
GOOGLE_BREAKPAD_SITE = http://google-breakpad.googlecode.com/svn/trunk
GOOGLE_BREAKPAD_SITE_METHOD = svn
 
GOOGLE_BREAKPAD_CONF_OPT = --disable-processor --disable-tools 
$(eval $(host-autotools-package))
$(eval $(autotools-package))

> IIRC, the handler in integrated at the source code level in the
> projects. Do you plan to provide something for the target?

exactly, host and target are needed

> >> My idea was to add a new target to the Makefile, just
> >> before "target-finalize:" and check against an option in the config
> >> like:
> >>
> >> ifeq ($(BR2_ENABLE_BREAKPAD),y)
> >>         TARGETS+=target-generate-breakpad-symbols
> >> endif
> >>
> >> and then:
> >>
> >> target-generate-breakpad-symbols:
> >>         extract symbols and deploy result to output/images
> >>
> >> Is this basically the way to go, or is there a better way to achieve
> >> this?
> >
> >  It is easier to add it to the target-finalize target. Then you can be
> > sure that the ordering is correct (target-finalize already has all the
> > needed dependencies). You can also easily use conditions there (it's not
> > inside a define).
> >
> >  However, I think it will be more appropriate to implement breakpad as an
> > additional strip alternative. You probably don't want to combine strip
> > with breakpad...
> 
> I think breakpad is more like a pre-strip hook, that one can enable or
> not. But in the end, the target image will be stripped most of the
> time (at least, this is the way I would use such a feature).

I agree, since the extraction of the symbols should always happen, when
breakpad is used, no mater what strip alternative is selected

> > Currently we have none, strip or sstrip, it should be
> > relatively easy to add breakpad as an additional option. Note, however,
> > that the strip code is very old, it doesn't satisfy our coding style so
> > we'll probably want you to do some cleanup first. Also, it is currently
> > untested in the autobuilders AFAIK.
> >
> 
> Regards,
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140423/a29df25c/attachment.asc>

  reply	other threads:[~2014-04-23 16:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-23 14:21 [Buildroot] Adding google-breakpad to buildroot Pascal Hürst
2014-04-23 15:29 ` Arnout Vandecappelle
2014-04-23 15:52   ` Samuel Martin
2014-04-23 16:12     ` Pascal Hürst [this message]
2014-04-23 21:13       ` Arnout Vandecappelle
2014-04-24  7:52         ` Pascal Hürst

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1398269552.30640.13.camel@mbpro.localhost \
    --to=pascal.huerst@gmail.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.