* [Buildroot] Adding google-breakpad to buildroot
@ 2014-04-23 14:21 Pascal Hürst
2014-04-23 15:29 ` Arnout Vandecappelle
0 siblings, 1 reply; 6+ messages in thread
From: Pascal Hürst @ 2014-04-23 14:21 UTC (permalink / raw)
To: buildroot
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. 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?
regards,
pascal
-------------- 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/eebac11d/attachment.asc>
^ permalink raw reply [flat|nested] 6+ messages in thread* [Buildroot] Adding google-breakpad to buildroot 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 0 siblings, 1 reply; 6+ messages in thread From: Arnout Vandecappelle @ 2014-04-23 15:29 UTC (permalink / raw) To: buildroot 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. 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... 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, Arnout Regards, Arnout -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 880 bytes Desc: OpenPGP digital signature URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140423/bbd825f8/attachment.asc> ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Adding google-breakpad to buildroot 2014-04-23 15:29 ` Arnout Vandecappelle @ 2014-04-23 15:52 ` Samuel Martin 2014-04-23 16:12 ` Pascal Hürst 0 siblings, 1 reply; 6+ messages in thread From: Samuel Martin @ 2014-04-23 15:52 UTC (permalink / raw) To: buildroot 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? IIRC, the handler in integrated at the source code level in the projects. Do you plan to provide something for the target? >> 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). > 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, -- Samuel ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Adding google-breakpad to buildroot 2014-04-23 15:52 ` Samuel Martin @ 2014-04-23 16:12 ` Pascal Hürst 2014-04-23 21:13 ` Arnout Vandecappelle 0 siblings, 1 reply; 6+ messages in thread From: Pascal Hürst @ 2014-04-23 16:12 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Adding google-breakpad to buildroot 2014-04-23 16:12 ` Pascal Hürst @ 2014-04-23 21:13 ` Arnout Vandecappelle 2014-04-24 7:52 ` Pascal Hürst 0 siblings, 1 reply; 6+ messages in thread From: Arnout Vandecappelle @ 2014-04-23 21:13 UTC (permalink / raw) To: buildroot On 23/04/14 18:12, Pascal H?rst wrote: > 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: [snip] >>> 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 OK, I thought breakpad did stripping already. In that case, I think it's best to put it in target-finalize just before strip. Regards, Arnout -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 880 bytes Desc: OpenPGP digital signature URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140423/84180dd6/attachment.asc> ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Adding google-breakpad to buildroot 2014-04-23 21:13 ` Arnout Vandecappelle @ 2014-04-24 7:52 ` Pascal Hürst 0 siblings, 0 replies; 6+ messages in thread From: Pascal Hürst @ 2014-04-24 7:52 UTC (permalink / raw) To: buildroot On Mit, 2014-04-23 at 23:13 +0200, Arnout Vandecappelle wrote: > On 23/04/14 18:12, Pascal H?rst wrote: > > 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: > [snip] > >>> 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 > > OK, I thought breakpad did stripping already. > > In that case, I think it's best to put it in target-finalize just before > strip. Ok, I'll do it that way, then. Thanks! > Regards, > Arnout Regards Pascal -------------- 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/20140424/990dae1f/attachment.asc> ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-04-24 7:52 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2014-04-23 21:13 ` Arnout Vandecappelle 2014-04-24 7:52 ` Pascal Hürst
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox